US 20120095852A1
`
`(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2012/0095852 A1
`Bauer et al.
`(43) Pub. Date: Apr. 19, 2012
`
`
`(54) METHOD AND SYSTEM FOR ELECTRONIC
`WALLET ACCESS
`
`(76)
`
`Inventors:
`
`John Bauer, Downingtown, PA
`(US); Glenn Curtiss McMillen,
`Downingtown, PA (US); Eric
`Crozier, Hockessin, DE (US);
`Christine Ann Schuetz, Chadds
`Ford, PA (US); Garry Lloyd,
`Pitsford (GB)
`
`(21) Appl. No.:
`
`12/905,419
`
`(22)
`
`Filed:
`
`Oct. 15, 2010
`
`Publication Classification
`
`(51)
`
`Int. Cl.
`(2006.01)
`G06Q 20/00
`(52) US. Cl. ............................................. 705/16; 705/41
`(57)
`ABSTRACT
`
`A mobile payment method, system and graphical user inter-
`face are described that facilitate efficient and secured pay-
`ment transactions from an electronic wallet on a user portable
`electronic device with a merchant point of sale terminal over
`a contactless communications link. In one aspect, the elec-
`tronic wallet includes a flag indicating whether input of the
`passcode is required to access the electronic wallet, which
`flag can be set by a remote device. In another aspect, a short-
`cut is provided to directly execute the payment features ofthe
`electronic wallet application software.
`
`
`
`
`Account Management System
`
`Cellular
`Communications
`Payment
`
`
`
`
`Sewer
`Acco unt
`Telephone
`
`
`Network
`Issuer
`Middleware
`
`
`
`
`Cellular
`Server
`Payment
`
`
`
`Telephone
`Processing
`Network
`
`
`System
`Mobile Device
`interface
`
`
`
`
`
`Payment Account
`Data
`
`Payment Account
`Wallet Module
`
`
`
`Trusted
`Trusted
`
`Servtce
`Service
`
`
`
`Manager
`Manager
`
`
`
`(TSM) Unit
`(TSM) Server
`
`
`
`
`
`
`
`
`Point Of Sale
`
`
`Merchant
`
`(POS)
`Bank
`
`Terminal
`
`
`
`
`12
`
`’17
`
` Payment Association
`Network
`
`
`Apple Ex. 1028, p. 1
`Apple Ex. 1028, p. 1
` Apple v. Fintiv
`Apple v. Fintiv
`|PR2020-00019
` IPR2020-00019
`
`

`

`Patent Application Publication
`
`Apr. 19, 2012 Sheet 1 0f9
`
`US 2012/0095852 A1
`
`
`
`
`
`Emuw>mEmEmmmcmEEzooo<
`
`
`
`
`
`EmE>mmmcozmoEsEEoo83:00
`
`
`
`
`
`E38915&memcocamfifi
`
`
`
`
`
`53mm.23562.2£9,302
`
`
`
`EmE>mn_Eiwm(.3260
`
`@538596:36?
`
`
`
`
`{9562
`
`momw699$tE_
`
`838.2322
`
`
`
`co:m_oowm<EwE>mn_
`
`x5502
`
`_\.®_n_Ia
`
`E2822
`
`xcmm
`
`2mm.6Eon.
`
`Amen;
`
`BEEEH
`
`62%gm:ES95:
`
`
`Lommcms.memcmz
`
`.853SamMm.83me0E280
`
`cmE>m_o“me....0225.I<Hn.v
`
`
`
`E3891EmE>mm
`
`
`
`23.85.E=m>>
`
`Apple Ex. 1028, p. 2
`Apple Ex. 1028, p. 2
` Apple v. Fintiv
`Apple v. Fintiv
`|PR2020-00019
` IPR2020-00019
`
`
`
`
`
`
`
`
`

`

`Patent Application Publication
`
`Apr. 19, 2012 Sheet 2 0f9
`
`US 2012/0095852 A1
`
`
`
`Mobile Device
`
`25
`
`19
`
`
`
`‘
`
`Handset Operating System and Hardware
`User Interface
`‘: Dismj(
`I
`i23
`122
`Wallet Application
`
`MobilePayment Wallet Application1
`
`(PaymentShortcut Module
`
`
`”;—LMOdUIe Main Menu
`
`_Ial|et_creen
`I
`
`
`\lWallet
`26
`Non-payment Application2/
`
`
`Modules
` 29
`
`
`Secure Memory
`
` Issuer Security Domain
`
`
`Payment Security Domain
`
`
`
`rf“:
`\ I
`/
`.
`I
`Wallet
`Optionai
`I
`OptIonal
`
`Other
` 36
`Other Service
`
`Service
`i AppIIcation
`Provider SD
`Provider SD
`Secure Data
`1
`
`
`
`PP SE
`
`ll—_
`Package
`
`
`
`Payment
`Package
`
`
`PPSE
`
`4 2N ControIler
`
`Instance
`
`
`Issuer Security
`Domain
`Issuer Applet
`Pac<age
`
`Hef—I
`AuthertIoatIon
`Applet
`Instance
`
`38
`
`—4 46
`
`‘
`
`
`I
`I
`
`#40
`Other 3rd Party Apps 37/UICC Applet (Network Key
`
`
`and GSM PIN)
`
`
`45
`
`
`
`
`
`
`Data
`Contactless Link
`Cellular Network \
`Communication
`
`
`
`
`
`Interface
`‘
`Interface
`
`Link Interface
`
`
`
`
`
`
` 9
`
`To/From
`Merchant’s POS
`Terminal (5)
`
`
` ti
`
`To/F rom
`Cellular Telephone
`Network (1 1)
`
`,1
`
`33
`
`FIG. 2a
`
`Apple Ex. 1028, p. 3
`Apple Ex. 1028, p. 3
` Apple v. Fintiv
`Apple v. Fintiv
`lPR2020-00019
` IPR2020-00019
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`I I I I
`
`,,,,,,,,,,,,,,,
`I Payment
`I
`Applet
`
`Instance
`
`
`
`I
`
`
`
`
`
`24"”
`
`31
`
`32
`
`44
`
`
`
`

`

`Patent Application Publication
`
`Apr. 19, 2012 Sheet 3 0f9
`
`US 2012/0095852 A1
`
` /
`Mobile Device
`
`
`Wallet Appl ication
`Payment Shortcut Module
`
`
`Mobile Payment Wallet Application Module
`
`
`
`gecure Element
`
`,%
`
`Authentication Applet
`
`L’\
`Get
`Check PlN
`
`
`
`
`
`
`
`
`I
`Ugfite
`j Lock PIN ‘
`:
`Security
`Currently
`
`
`‘
`l Word
`Writeable
`k 46—3
`1 46-4
`
`
`1
`
`
`
`
`I46-9¢
`146-8
`146-10
`k48-12
`
`
`1
`1 46—1
`
`146-2
`
`‘
`Verify PIN l
`
`Sel PIN-
`Verified
`Flag
`
`3
`‘
`
`Clear PIN— ‘
`Verified
`Flag
`
`.
`RefigR'SK
`9
`
`l
`
`46-5
`
`146-6
`
`E 46-7
`
`C 48-11
`
`I
`
`‘
`Retrieve
`U d t
`Update
`; Reset PIN
`PIN-Verified
`R. F; file
`Security
`l
`Word
`'5
`ag
`Flag
`‘
`
`
`x
`
`Gecure Data
`PIN Locked
`Security” ‘
`PIN Entry
`Flag
`Word
`i1
`1 01
`7
`Flag
`1 107
`fig W6 105
`el'l le
`V
`‘
`PIN Risk Flag ‘1 103
`1
`Flag
`
`\ ——
`109
`i
`‘6
`
`(Payment Applet
`
`l
`l
`‘
`.
`‘
`
`
`
`
`
`i
`ransaction
`l
`I TAulhoriae
`I
`‘
`
`Generate
`authorization
`request
`
`Transmil
`authorization
`request
`
`1
`
`Display
`.
`.
`lransaction
`confinnation
`
`1 40-3 1 40-4
`x 40-2
`1 40-1
`
`
`
`
`
`
`
`
`
`‘
`
`‘
`
`l
`
`46
`
`Calls from
`middleware
`server of
`account
`management
`syslem
`
`Apple Ex. 1028, p. 4
`Apple Ex. 1028, p. 4
` Apple v. Fintiv
`Apple v. Fintiv
`|PR2020-00019
` IPR2020-00019
`
`

`

`Patent Application Publication
`
`Apr. 19, 2012 Sheet 4 0f 9
`
`US 2012/0095852 A1
`
`Mobile Payment Process
`
`Receive user input to unlock phone (if locked)
`
`83-1
`
`Receive user input selection of QuickPay icon
`.
`.
`.
`.
`Via handset touch sensmve display screen
`
`83-3
`
`Launch shortcut application to payment feature activation process
`
`83-5
`
`I
`
`Processing user inputsto activate payment feature on the handset
`
`I
`
`83-7
`
`Effect payment transaction from selected mobile payment account
`and output confirmation of payment
`
`83-9
`
`END
`
`FIG. 3
`
`Apple Ex. 1028, p. 5
`Apple Ex. 1028, p. 5
` Apple v. Fintiv
`Apple v. Fintiv
`|PR2020-00019
` IPR2020-00019
`
`

`

`Patent Application Publication
`
`Apr. 19, 2012 Sheet 5 0f9
`
`US 2012/0095852 A1
`
`.Emmwmomcmm2:0:$25chm>m>>_<:
`
`mUoE2Exomco
`
`
`
`
`
`diam
`
`
`
`mmEww._:cmk_->:cw.z_a
`
`2305
`
`mea8H395;
`
`“I“8.3%25
`2ELeEEOE
`
`2505vcmmOnm.
`
`
`
`:mExmzmuSNE83%
`
`
`
`Ea:mvoo.otmmamomm
`
`83%250E
`
`_‘va
`
`
`
`
`
`mm:xmiZ_n_fimwmm
`
`EV.OE
`
`
`
`mm:32%25“mm
`
`Zn.3E28Ema:
`
`
`
`wEEmtmiEm
`
`Apple Ex. 1028, p. 6
`Apple Ex. 1028, p. 6
` Apple v. Fintiv
`Apple v. Fintiv
`|PR2020-00019
` IPR2020-00019
`
`
`
`8382522mon_255%
`
`
`
`
`
`
`
`
`

`

`Patent Application Publication
`
`L
`
`pA
`
`1
`
`hS
`
`6
`
`S
`
`/
`
`1A2500
`
`9wo>M54%
`
`2oz
`
`amemBUmmUCmcEmmwfmm;
`
`
`mmwémmméw
`
`toz“59252E%025980wm>>mm;
`
`8382522
`
`quv
`
`mméw
`
`“.9622?.Em
`
`REcozmoEE3.35
`
`9862m_Z_n_
`
`
`
`:mcgmfivcmg.83%
`
`
`
` 259:ucmmOmm
`
`mOn_oEobomm—
`
`
`
`5532223B9256:025N_.6£:m055:me
`
`
`
`
`
`
`
`2E505:3“mm—692EfitsHmong.
`
`
`
`
`
`02m.coamofigueficmSame—9E©9820
`
`5IwavGE0.Bém
`
`Hwoam2:oszcoszm25>:EmcmF
`
`
`
`U84%.mméw
`
`mmém
`
`
`
`:o:m~:o£:mwzwowm
`
`83%230EEoc
`
`Apple Ex. 1028, p. 7
`Apple Ex. 1028, p. 7
` Apple v. Fintiv
`Apple v. Fintiv
`|PR2020-00019
` IPR2020-00019
`
`
`
`
`
`

`

`Patent Application Publication
`
`Apr. 19, 2012 Sheet 7 0f9
`
`US 2012/0095852 A1
`
`Eluw
`
`$.me
`
`0.1%
`
`cosomwcg@283.
`
`
`
`mOnEE0::26:sz
`
`
`
`mcEEmeucozmwzozs<
`
`5cmmam:2?.so893
`
`
`
`EzoEm.commcm:
`
`
`
`mmcfimmBig2amtxm:2EEmQEoo
`
`:éw
`
`mvéw
`
`
`
`musev653%.:53200
`
`cozommcm:E258.é
`
`
`
`hocozmctccooEggs;
`
`monm.2cozommcm:
`
`
`
`0v..®_n_
`
`mm‘vw
`
`vméw
`
`
`
`U5cozmczccoo:Emcmc.
`
`239:2cozumwcmz
`
`83%
`
`
`
`coszécoU968m
`
`
`
`cozommcmbuQmEEouv5
`
`EmE>mn_
`
`mEmmwooi
`
`E295
`
`Esooo<
`
`EwEmmmcmE
`
`E296
`
`
`
`8382522
`
`344%
`
`mm-.vm
`
`
`
`Bcoszhzzoo$603.
`
`
`
`E0:cofimmcmz
`
`
`
`$23EmeEEE
`
`
`
`accommcm:EcoszFEoo>m_aw_o
`
`Dzm
`
`
`
`Slum
`
`
`
`:ofimmcmztEwcmc.
`
`Easing28:0:me
`
`
`
`E993mcfimmooa
`
`wOnE
`
`$4
`
`mmém
`
`EmExmaEa:cozommcm:Bcoszécoo
`
`mammmm
`
`
`
`E2m>wmEmwmuoa
`
`hocoszécoo>535
`
`wOn_cocozommcm:
`
`02m.
`
`Apple Ex. 1028, p. 8
`Apple Ex. 1028, p. 8
` Apple v. Fintiv
`Apple v. Fintiv
`|PR2020-00019
` IPR2020-00019
`
`
`
`
`
`
`
`
`
`
`
`
`
`

`

`Patent Application Publication
`
`Apr. 19, 2012 Sheet 8 0f9
`
`US 2012/0095852 A1
`
`
`
` wm/DWIWfi
`mm(wigciomco8x:_1_
`
`@9359E55
`3W3W
`
`Emu.mi
`
`
`
`
`
`5 ,
`
`
`EmE>ma2592W»wWW”coamEEcoo\
`,EmE>ma\
`6rms<rm9fl,
`
`0335330
`
`wm
`
`EVE:Wum(Wflchsfime:86
`
`
`mwEma.9n.W@5520
`
`
`
`$4M
`
`”coszEcooWEmExma
`
`AWN mmmmg
`
`
`
`259:£0.90
`
`mwmcuSn
`
`WigRisaigisgw
`
`mm.0_n_
`
`5*10Zn.
`
`mwmsosa
`
`Apple Ex. 1028, p. 9
`Apple Ex. 1028, p. 9
` Apple v. Fintiv
`Apple v. Fintiv
`|PR2020-00019
` IPR2020-00019
`
`
`
`
`
`

`

`Patent Application Publication
`
`Apr. 19, 2012 Sheet 9 0f9
`
`US 2012/0095852 A1
`
`
`
`,_Mg__
`
` gumofimmMW,____
`38»305mm«238%”595__
`vofiofi«cwEmwmasmwwvESP...EggrfiMW»
`
`
`
`__Em_u....mEmmSo>i__,__:Ewnfiisammw
`
`
`
`
`
`
`
`
`
`
`
`
`
`be.mv_n_om.O_n_am.0_n_mm.®_n_
`
`Apple Ex. 1028, p. 10
`Apple Ex. 1028, p. 10
` Apple v. Fintiv
`Apple v. Fintiv
`|PR2020-00019
` IPR2020-00019
`
`

`

`US 2012/0095852 A1
`
`Apr. 19, 2012
`
`METIIOD AND SYSTEM FOR ELECTRONIC
`WALLET ACCESS
`
`FIELD OF THE INVENTION
`
`[0001] This invention relates to a mobile payment account
`system, and more particularly to an improved mobile pay-
`ment application on a mobile device to enable more efficient
`and secured contactless payment at an electronic point of sale.
`BACKGROUND OF THE I \1 \/ ENTION
`
`[0002] Mobile payment account systems are generally
`known, in which portable electronic devices are configured to
`provide payment from an electronic wallet. Typically, these
`portable electronic devices are configured to enable a con-
`tactless communication with a merchant Point Of Sale (POS)
`terminal to carry out a payment transaction, for example
`using near field communication (NFC)
`technology. As
`described in the Applicant’s co-pending application US. Ser.
`No. 12/891,866,
`incorporated herein by reference in its
`entirety, activated mobile payment account data may be
`stored in the secure memory ofthe portable electronic device
`which can then be used to carry out transactions with the
`merchant electronic POS terminal via a NFC link.
`[0003] However, conventional mobile payment systems
`typically involve a complicated process in order for a user to
`effect a secured payment transaction from an electronic wal-
`let. For example, US. Pat. No. 7,707,113 to Sprint Commu-
`nications Company L.P. discusses a method of a portable
`electronic device providing payment from an electronic wal-
`let with different levels of security. In a first level of security,
`the method prompts for input of a personal identification
`number (PIN) after the wallet has been opened and providing
`payment from the wallet after receiving the PIN. However, in
`another level of security, no PIN is required thus enabling
`efficient but unsecured payment transactions to be made from
`the electronic wallet.
`
`[0004] Additionally, when customers use such a payment
`product to conduct low dollar transactions over contactless
`interfaces, a signature may not be required at the point of sale,
`nor a challenge for a numeric passeode (PIN) or a password.
`In the United States for example, customers are able to wave
`their payment device and authorize the payment transaction
`without further interaction. For any theft ofpayment devices,
`the liability for these low dollar swipe transactions is placed
`upon the issuing bank, not the customer and not the merchant.
`[0005]
`For payment accounts residing on mobile devices
`such as contactless payment capable mobile phones, the theft
`of a phone now becomes immediately available for low dollar
`purchases without consumer verification prior to a purchase.
`The perpetrator can make as many low dollar transactions
`without being challenged for authentication and access the
`payment account. All of these low dollar transactions will be
`the responsibility of the issuing bank under current payment
`association dispute rules. Customers may elect to always
`require a numeric passcode challenge for a purchase transac-
`tion regardless of the value, but this is not required.
`[0006] What is desired is a more efficient mobile payment
`system and method which facilitates expedient and secured
`payment
`transactions
`from an electronic wallet, and
`improved prevention of fraudulent use of the electronic wal-
`let.
`
`SUMMARY OF THE INVENTION
`
`In one aspect of the present invention, a method is
`[0007]
`provided of facilitating secured payment from an electronic
`
`wallet on a portable device, comprising storing, on the por-
`table device, an electronic wallet comprising data for com-
`pleting a payment transaction, wherein said data includes a
`passcode for enabling access to the electronic wallet and a
`[lag indicating whether input of the passcode is required to
`access the electronic wallet; receiving a command from a
`device remote from the portable device to set the flag to
`indicate that input of the passcode is required to access the
`electronic wallet; and responsive to a request to conduct a
`payment transaction from the electronic wallet, prompting for
`input of a passcode if the flag indicates that input of the
`passcode is required, verifying the input passcode, and pro-
`viding payment information to authorize the payment trans-
`action.
`
`In another aspect, the present invention provides a
`[0008]
`method is provided offacilitating payment from an electronic
`wallet on a portable device, comprising storing, on the por—
`table device, wallet application software for accessing the
`electronic wallet, including executable code for facilitating
`access to data defining one or more mobile payment accounts
`in the electronic wallet and executable code for facilitating
`activation of a secure payment from a mobile payment
`account; storing, on the portable device, a further payment
`application software associated with the executable code in
`the wallet application software for facilitating activation; and
`receiving a user input selection of the second application
`software and in response, directly executing the associated
`executable code in the first application software to facilitate
`activation of a secure payment from the mobile payment
`account.
`
`In yet another aspect, the present invention provides
`[0009]
`a graphical user interface for facilitating payment from an
`electronic wallet on a portable device, comprising a first icon
`associated with wallet application software for accessing the
`electronic wallet, including executable code for facilitating
`access to data defining one or more mobile payment accounts
`in the electronic wallet and for facilitating activation of a
`secure payment from a mobile payment account, a second
`icon associated with executable code for facilitating direct
`activation of a secure payment from a mobile payment
`account, and receiving user selection of the second icon and
`directly executing the application software for facilitating
`activation of a secure payment from a mobile payment
`account.
`
`In yet a further aspect, there is provided a portable
`[0010]
`device and computer program arranged to carry out the above
`method when executed by a portable device.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`[0011] There now follows, by way of example only, a
`detailed description ofembodiments ofthe present invention,
`with references to the figures identified below.
`[0012]
`FIG. 1 is a block diagram showing the main com—
`ponents of a mobile payment system according to an embodi—
`ment of the invention.
`
`FIG. 2a is a block diagram showing the main hard-
`[0013]
`ware and/or software elements of a mobile device shown in
`FIG. 1 according to an embodiment.
`[0014]
`FIG. 2b is a block diagram showing the main ftmc-
`tional elements ofthe mobile device shown in FIG. 2a accord-
`ing to embodiments of the invention.
`[0015]
`FIG. 3 is a flow diagram illustrating the main pro-
`cessing steps performed by the mobile device of FIGS. 1 and
`2 in a mobile payment process according to an embodiment.
`
`Apple Ex. 1028, p. 11
`Apple Ex. 1028, p. 11
` Apple v. Fintiv
`Apple v. Fintiv
`|PR2020-00019
` IPR2020-00019
`
`

`

`US 2012/0095852 A1
`
`Apr. 19, 2012
`
`FIG. 4, which comprises FIGS. 4a to 4c, is a flow
`[0016]
`diagram illustrating the main processing steps performed by
`the main components of the mobile payment system of FIG.
`1 in the step of processing user inputs to activate a payment
`feature on the mobile device as illustrated in FIG. 3.
`
`FIG. 5, which comprises FIGS. 5a to 5], illustrates a
`[0017]
`sequence of screens displayed by the mobile device to the
`user during a mobile payment process according to embodi-
`ments of the present invention.
`[0018]
`FIG. 6, which comprises FIGS. 6a to 6d, illustrates
`a sequence of screens displayed by the mobile device to the
`user during a process for setting a default mobile payment
`account on the mobile device.
`
`DETAILED DESCRIPTION OF EMBODIMENTS
`OF THE INVENTION
`
`Overview
`
`[0019] A specific embodiment of the invention will now be
`described for a process for conducting a payment transaction
`using a mobile device at a merchant’s electronic point of sale
`terminal. Referring to FIG. 1, a mobile payment system 1
`according to an embodiment comprises a mobile device 3, a
`merchant’s electronic Point Of Sale (POS) terminal 5 as com-
`monly knoan in the field. and a account management system
`7 associated with a payment account issuer 10, which com-
`municate electronically with one another. The account man-
`a gement system 7 may provide for mobile payment account
`creation and activation, transaction authorization, and other
`related functionality, as described in the Applicant’s above-
`referenced eo-pending application US. Ser. No. 12/891,866.
`As will be described below, the account management system
`7 may include a communications server 13 and a Trusted
`Service Manager (TSIVI) server 18 for facilitating communi—
`cation between the middleware server 16 and the mobile
`device 3. The payment account issuer 10 may include a pay—
`ment processing (authorization and fraud monitoring) system
`10a for authorizing and effecting payment transactions from
`payment accounts associated with the payment account issuer
`10, for example in response to payment transaction instruc-
`tions received via a payment association network 17. In this
`embodiment.
`the mobile device 3 and the electronic POS
`terminal 5 communicate with one another via a contactless
`communication link 9. As those skilled in the art will appre-
`ciate, this contactless communication link 9 may be for
`example a near field communication (NFC) link, an infra-red
`link, an ultra-sonic link, an optical link, a radio frequency (eg.
`REID) link, a wireless link such as Bluetooth or Wi-Fi based
`on the IEEE 802.11 standards, or any other communication
`link that does not require direct physical contact. The mobile
`device 3 may also communicate with the account manage-
`ment system 7 via a cellular telephone network 11.
`[0020] As shown in FIG. 1, the mobile device 3 in this
`embodiment includes a secure memory 4 storing payment
`account data 6 for one or more mobile payment accounts that
`have been set up on the mobile device 3. The secure memory
`4 may for example be a Universal Integrated Circuit Card
`(UICC) secure element, any other secure memory configura-
`tions such as embedded secure element chips, or as part of an
`peripheral accessory device to the mobile device such as a
`micro Secure Digital cardiotherwise known as a micro SD
`card, as are known in the art. As those skilled in the art will
`appreciate, other forms of mobile handset software and/or
`hardware may be implemented to provide built-in secure
`
`electronic wallet functionality for accessing the secure
`memory 4, including encryption and decryption of the pay-
`ment account data 6 as necessary. For example, the mobile
`device 3 may be configured with built-in functionality pro-
`viding access to secure memory on the Subscriber Identity
`Module (SIM) card in the mobile device 3. In the present
`embodiment, payment account data 6 for a mobile payment
`account that is securely stored in the mobile device 3 may
`include data defining an amount of pre-paid funds that have
`been transferred from the user’s payment account issuer 10 to
`that mobile payment account. Alternatively or additionally,
`the payment account data 6 may include data identifying a
`user’s account at a payment account issuer 10 from which
`funds can be transferred to the merchant bank to complete a
`transaction, via a payment association network 17 for
`example. In this way, the electronic wallet includes a payment
`account that may be linked to multiple funding sources, such
`as a pre—paid account, deposit account and/or credit account.
`As an alternative, the electronic wallet may include a plurality
`ofmobile payment accounts, eachlinked to a respective fund-
`ing source.
`[0021] The mobile device 3 also includes a payment
`account wallet application module 8 storing processing
`instructions used to control the operation ofthe mobile device
`3 , for example to facilitate creation and management ofone or
`more mobile payment accounts on the mobile device 3 and to
`handle the process of conducting a transaction with a mer-
`chant via the electronic POS terminal 5 using a mobile pay-
`ment account on the mobile device 3, to effectively transfer
`funds from the mobile payment account on the mobile device
`3 or an associated payment account issuer 10 to the merchant.
`As those skilled in the art will appreciate,
`the payment
`account wallet application module 8 may be provided as one
`or more software components of an operating system running
`011 the mobile device 3 or as one or more separate software
`applications installed on the mobile device 3. Such software
`applications may be configured to run as background appli-
`cations on the mobile device 3 that monitor for and activate
`upon receipt of appropriate messages or events, or may be
`launched by the user, so as to carry out the above operations.
`Alternatively, thepayment account wallet application module
`8 may be stored in the secure memory 4, and may for example
`be loaded into a virtual machine of the mobile device 3 to
`
`provide the functionality of the present embodiment.
`[0022] A secure mobile payment account provisioning and
`activation process may be carried out between the mobile
`device 3 and the account management system 7, as described
`in the Applicant’s above referenced co-pending application
`U.S. Ser. No. 12/891,866. The activated mobile payment
`account data stored in the secure memory 4 of the mobile
`device 3 can then be used to carry out transactions with a
`merchant electronic POS terminal 5 via the contactless com-
`munication link 9, whereby a requested amount of funds can
`be transferred from the mobile payment account stored in the
`mobile device 3 to the merchant’s bank 12. Techniques and
`protocols for implementing the authorization and transfer of
`ftmds between the merchant POS terminal 5, the merchant
`bank 12, and the payment account issuer 10, for example via
`the payment association network 17, are commonly known
`and will be apparent to those skilled in the art.
`[0023] Account Management System
`[0024] The account management system 7 in the mobile
`payment system 1 will now be described in more detail with
`reference to FIG. 1, which shows the elements of the account
`
`Apple Ex. 1028, p. 12
`Apple Ex. 1028, p. 12
` Apple v. Fintiv
`Apple v. Fintiv
`|PR2020-00019
` IPR2020-00019
`
`

`

`US 2012/0095852 A1
`
`Apr. 19, 2012
`
`management system 7 used in embodiments of the present
`invention. As shown, the account management system 7 may
`include a communications server 13, a middleware server 16,
`and a Trusted Service Manager (TSM) server 18, which com-
`municate electronically with one another. In this embodi-
`ment, the servers communicate with one another via secure
`network links, for example over a private Local Area Network
`(LAN), a VPN connection, or other dedicated secure comiec-
`tion. As those skilled in the art will appreciate, although the
`components of the account management system 7 in this
`embodiment are provided as separate servers, one or more of
`the servers could be provided as software and/or hardware
`modules in the same server.
`
`[0025] As shown in FIG. 1, data may be communicated
`between the mobile device 3 and the middleware server 16
`over the cellular telephone network 11 via a cellular tele-
`phone network interface 14 ofthe communications server 13.
`The TSM server 18 may perform logical data preparation of
`the data to be communicated to the mobile device, for
`example by forming appropriate commands to be written to
`the secure memory 4 of the mobile device 3. As those skilled
`in the art will appreciate, the precise form of the data may
`depend on the particular implementation of the secure
`memory 4 of the mobile device 3 and/or the payment asso-
`ciation scheme program for facilitating payment. The TSM
`server 18 may also perform encryption of the data, for
`example of the sensitive payment account infomiation in the
`mobile payment account data 6 such as payment keys. The
`TSM server 18 may then pass the encrypted data to the mobile
`device 3 via the communications server 13 and the cellular
`
`telephone network 11.
`[0026] The communications server 13 may also include a
`separate TSM unit 15 for securely routing the data to the
`mobile device 3, as will be known to the skilled person. In the
`above example,
`the TSM unit 15 in the communications
`server 13 would not access any ofthe sensitive portions of the
`encrypted data that is routed to the mobile device 3 via the
`cellular telephone network interface 14.
`[0027] Mobile Device
`[0028]
`FIG. 2, which comprises FIGS. 2a and 2b, shows the
`elements of the mobile device 3 according to an embodiment
`of the present invention. In this embodiment, the mobile
`device 3 is a mobile handset and as shown in FIG. 2a, the
`mobile handset operating system and hardware includes a
`user interface 22 arranged to process inputs from a keypad 23
`and to control output on a display 25. As those skilled in the
`art will appreciate, the keypad 23 and display 25 may be
`provided as separate hardware entities of the mobile device 3
`or may alternatively be provided as an integrated entity, for
`example as a touch sensitive display screen user interface
`element as is known in the art. The mobile device 3 may also
`include components included in commonly known mobile
`handsets, such as a microphone, an earpiece speaker, camera
`and controller, GPS sensors etc, which are not shown for
`clarity. A working memory 27 is provided for use by the
`handset operating system and hardware units 21.
`[0029]
`Software and data may be transferred via the cellu-
`lar network interface 33 or via a different data communication
`link interface 71 for example in the form of signals 72, which
`may be electronic, electromagnetic, optical, or other signals
`capable of being received by the data communication link
`interface 71 via a communication path 73 that carries the
`signals 72 and may be implemented using wire or cable, fiber
`optics, a physical phone line, a wireless link, a radio fre-
`
`quency link, or any other suitable communication channel.
`For instance, communication path 73 may be implemented
`using a combination of charmels. As those skilled in the art
`will appreciate, the communication path 73 may be linked or
`merged with the communication path from the cellular net-
`work interface 33 to the cellular telephone network 11.
`[0030] As mentioned above, the mobile device 3 includes a
`secure memory 4. The mobile device 3 is operable to receive
`the payment account data 6 and activation request messages
`from and send validation messages to the account manage—
`ment system 7 via a cellular telephone network interface 33
`and the cellular telephone network 11, and to store the
`received payment account data 6 in the secure memory 4. The
`mobile device 3 is also operable to receive transaction autho-
`rization request messages from and send authorization mes-
`sages to the merchant’s POS terminal 5 via a contactless
`communications link interface 37 and the contactless com-
`munications link 9. As those skilled in the art will appreciate,
`communication between a POS terminal 5 and the mobile
`device 3 may involve transmission ofdata in a single direction
`from the mobile device 3 to the POS terminal 5, depending on
`an implemented protocol (such as the well known protocol
`used by the Discover Zip cashless payment system).
`[0031] The mobile device 3 also includes a payment
`account wallet application module 8 as mentioned above,
`which stores processing instructions used to control the
`operation of the mobile device 3 to perform the various
`mobile payment account processes, as will be described
`below. As schematically illustrated in FIG. 2a, the payment
`account application wallet module 8 may include an account
`creation sub-module and an account activation sub-module
`which store processing instructions to create a request for a
`new mobile payment account if desired and to carry out a
`secured account validation and activation process,
`in
`response to user input from the keypad 23, as described in the
`above-referenced Applicant’s co-pending application Ser.
`No. 12/891,866. The payment account module 8 also includes
`a transaction authorization sub—module which stores process—
`ing instructions used to control the operation ofthe controller
`21 to carry out and authorize a transaction in response to user
`input from the user interface 22. The mobile payment wallet
`application module 8 may be configured to store a plurality of
`wallet screens 24 and an account access screen 26 which may
`be output on display 23 of the user interface 22 to facilitate
`user interaction with the sub-modules of the mobile payment
`wallet application module 8. One wallet screen is a main
`menu wallet screen 26 which may be displayed initially by the
`wallet application module 8 in response to a user command to
`launch the wallet application. The mobile device 3 may also
`store one or more non-payment application modules 29
`including processing instructions used to control the opera-
`tion of the mobile device 3 to perform other non-payment
`related processes.
`[0032]
`In this embodiment, the mobile device 3 further
`includes a payment shortcut module 19 that provides a short-
`cut to the payment feature within the mobile payment wallet
`application module 8. The shortcut may be implemented as
`processing instructions that link to the processing instructions
`of the transaction authorization sub -module. Altematively,
`the payment shortcut module 19 may comprise separate pro-
`cessing instructions used to control the operation of the con-
`troller 21 to carry out and authorize a transaction in response
`to user input from the user interface 22. Provision of the
`payment shortcut module 19 advantageously enables an
`
`Apple Ex. 1028, p. 13
`Apple Ex. 1028, p. 13
` Apple v. Fintiv
`Apple v. Fintiv
`|PR2020-00019
` IPR2020-00019
`
`

`

`US 2012/0095852 A1
`
`Apr. 19, 2012
`
`improved user interface for the transaction payment process
`that expedites the purchase process at a POS terminal 5 as the
`user avoids having to navigate through multiple wallet
`screens ofthe mobile payment wallet application module 8 to
`authorize a payment transaction from the electronic wallet.
`[0033]
`In an embodiment, the mobile payment wallet appli-
`cation module 8 may facilitate user navigation from any one
`ofthe wallet screens 24 to the main menu wallet screen 26. As
`
`those skilled in the art will appreciate, such navigation to the
`main menu wallet screen 26 may be direct or via one or more
`intermediary wallet screens 24. In this way, even though a
`user may have accessed the payment features of the wallet
`application module directly using the wallet application pay-
`ment shortcut module 19 of the present invention, the user
`may be able to navigate to any other wallet screen 24 of the
`mobile payment wallet application module 8.
`[0034] Also schematically illustrated in the exemplary
`embodiment of FIG. 2a are a plurality of security domains
`which may be implemented in the secure memory 4 of the
`mobile device 3. The security domains serve to segment the
`management and accessibility of various parties’ functional-
`ity and sensitive data as will be apparent to those skilled in the
`art. As shown in FIG. 211, an issuer security domain 31 may
`include a payment security domain 32, a Controlling Author—
`ity (CA) security domain 34, and a Supplementary Security
`Domain (SSD) code 35. The payment security domain
`includes the wallet application secure data 6, along with an
`issuer security domain 36 and one or more optional other
`service provider security domains 37. The issuer security
`domain 36 may include an issuer applet package 38, an
`authentication applet instance 46, and one or more payment
`applet instances 40 which enable the transaction processing
`functionality using an activated mobile payment account. The
`payment security domain 32 may also include a Proximity
`Payment System Environment (PPSF) package 41, a PPSF.
`controller instance 42 for facilitating the transaction process-
`ing flmctionality between the payment applet instances 40
`and the contactless link interface 37, and a payment package
`43.
`
`[0035] The mobile device 3 may also include one or more
`other third