(19) United States
`a2) Patent Application Publication <0) Pub. No.: US 2012/0095852 Al
`(43) Pub. Date: Apr. 19, 2012
`
`Baueretal.
`
`US 20120095852A1
`
`(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)
`G060 20/00
`(52) US. CD. oe enceneenenenenerae 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 anotheraspect, a short-
`cut is providedto directly execute the paymentfeaturesofthe
`electronic wallet application software.
`
`
`
`
` Account Management System
`
`Cellular
`Communications
`
`
`
`Payment
`Server
`Account
`Telephone
`
`
`
`
`Network
`Issuer
` Middleware
`
`
`Cellular
`Server
`
`Payment
`
`Telephone
`
`Processing
`
`Network
`system
`Mobile Device
`Interface
`
`
`
`
`
`
`
`Trusted
`Trusted
`
`
`
`Service
`Service
`Manager
`Manager
`
`
`
`
`(TSM) Unit
`(TSM) Server
`
`
`
`Payment Account
`
`
`Wallet Module
`
`
`
` Point Of Sale
`
`(POS)
`Terminal
`
`
`
`
`
`
`
`Merchant
`
`Bank
`
`
`
` Payment Association
`Network
`
`
`Apple Ex. 1028, p. 1
`Apple Ex. 1028, p. 1
` Apple v. Fintiv
`Applev.Fintiv
`IPR2020-00019
` IPR2020-00019
`
`

`

`Patent Application Publication
`
`Apr. 19, 2012 Sheet 1 of 9
`
`US 2012/0095852 Al
`
`
`
`
`
`wayshsjuewebeueyyjunoooy
`
`
`
`
`
`SUOEDIUNLWWODJe/N||FDjunosoyJBAIBSauoydsyjea|yuewAed
`
`
`
`
`
`
`
`
`
`ianss|aJema|pplyyYOMIEN
`
`
`
`Bulsse90ldauoydela)
`
`
`yuawAedJaAJagseinied
`
`
`
`ASYIOMON
`
`
`aoeLa}uU}Qd1AQQSIGoyy
`
`49M(WSL)wun(WSL)
`
`
`
`
`
`JaBbeueyJeBeueyy
`
`
`BdINBSadIAlaFed
`
`
`peisniypejsn.junoooyjuawiAeY
`
`L'Oldos“
`
`
`
`ualjeloossyjuewAe
`
`IOMION
`
`JURY
`
`yueg
`
`31SJOWlod
`
`JEUILWIO|(SOd)
`
`
`
`junosoVyJUSWAE
`
`
`
`SINPOWJSI/EAA
`
`Apple Ex. 1028, p. 2
`Apple Ex. 1028, p. 2
` Apple v. Fintiv
`Applev.Fintiv
`IPR2020-00019
` IPR2020-00019
`
`
`
`
`
`
`

`

`Patent Application Publication
`
`Apr. 19, 2012 Sheet 2 of 9
`
`US 2012/0095852 Al
`
`
`
`Mobile Device
`
`Handset Operating System and Hardware
`
`
`i
`
`User|
`
`nterface
`
`
`
`Working Memory
`
`a
`
`24
`
`i
`
`:
`Wailtet
`I
`Screens
`:
`qi
`
`
`25
`
`~27
`
`Wallet Application
`| Payment Shortcut Module
`
`( Non-payment Application
`Modules
`
`|
`
`19
`
`29
`
`Secure Memory
` Issuer Security Domain
`
`
`
`Payment Security Domain
`oo|
`
`
`
`‘
`Optional ‘ | (’
`
`Issuer Security
`Optional
`36
`
`Domain
`|
`apoioaton
`Other Service
`Other Service
`
`
`Secure Data|| Provider SD Provider SD Issuer Applet
`
`
`
`
`it
`Pacxage
`38
`
`
` rerrraene
`Authertication
`Apolet
`Instance
`
`|
`
`
`| Payment ~
`Applet
`Instance
`
` |
`
`|||
`
`|
`
`
`
`
`PPSE
`| PackageiL
`
`Payment
`Package
`PPSE
`Controller
`instance
`
`
`—i— 46
`
`L- 40
`
`45
`
`31
`
`32
`
`44
`
`|NO
` = :
`[mer
`Lo
`|
`2
`
`
`
`Mobile Payment Wallet Application\
`Main Menu
`
`Module— |
`Wallet
`
`
`Screen
`
`
`26
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`37 /
`UICCApplet (Network Key
`and GSM PIN)
`! q _
`_
`SSD
`Code
`7 CASD
`
`34
`
`
`Data
`Cellular Network )
`
`Communication
`Interface
`Link Interface
`
`
` Other 3% Party Apps
`
`i
`
`Coniactless Link
`Interface
`
`
`
`
` pT
`FIG. 2a
`
`To/From
`Merchant’s POS
`Terminal (5)
`
`33
`
`To/From
`Cellular Telephone
`Network (11)
`
`Apple Ex. 1028, p. 3
`Apple Ex. 1028, p. 3
` Apple v. Fintiv
`Applev.Fintiv
`IPR2020-00019
` IPR2020-00019
`
`

`

`Patent Application Publication
`
`Apr. 19, 2012 Sheet 3 of 9
`
`US 2012/0095852 Al
`
`a
`
`|r
`
`o 3
`
`
`:
`.
`Mobile Device
`
`7
`
`—
`
`
`
`Wallet Application
`Payment Shortcut Module
`JS
`
`
`
`19
`
`fi
`:
`XQ
`
`-
`Mobile Payment Wallet Application Module
`
`
`
`aS
`
`ecure Element
`
`p> B
`
`b—t+~_
`
`L 46
`
`|t
`
`Calls from
`middleware
`serverof
`account
`management
`sysiem
`
`<
`
`:
`|
`
`Oe a,
`Authentication Applet
`verate
`| Lock PIN |
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`(Secure Data
`
`Security
`PIN Entry
` Flag[sin)Flag 401 Word Nicceine||PINVerified ms < 107
`
`
`
`
`
`PIN Risk Flag >_
`Eleg
`|
`103
`|
`g
`109
`
`t
`Se
`
`
`(Payment Applet
`
`
`
`|
`A
`Generate
`Transmit
`Display
`
`| quinone
`authorization
`authorization
`transaction
`
` confirmation|ue. “\40-2 ‘\40-3 440-4
`
`ransaction
`f
`:
`:
`request
`request
`
`Check PIN
`
`Get
`
`Security
`|
`| Word
`L
`
`|
`Currently
`|
`Writeable
`lun
`46-4
`46-3
`Clear PIN- | .
`Verified
`ag
`Flag
`|
`\ 46-7
`\ 46-11
`| Updat
`Retrieve
`
`Ri ce Fs.
`PIN-Verified
`isk
`Flag
`Flag
`Xag-to
`46-12
`
`TU
`
`46-2
`Set PIN-
`Verified
`Flag
`:
`46-6
`Update
`Security
`Word
`46-9
`
`|
`Wan
`46-1
`Verify PIN |
`46-5
`|
`
`| Reset PIN
`
`M468
`
`|
`
`'
`
`PIN Locked
`
`
`
`)
`
`Apple Ex. 1028, p. 4
`Apple Ex. 1028, p. 4
` Apple v. Fintiv
`Applev.Fintiv
`IPR2020-00019
` IPR2020-00019
`
`

`

`Patent Application Publication
`
`Apr. 19,2012 Sheet 4 of 9
`
`US 2012/0095852 Al
`
`Mobile Payment Process
`
`Receive user input to unlock phone(if locked)
`
`Receive user input selection of QuickPay icon
`via handset touch sensitive display screen
`
`$3-1
`
`n > w
`
`Launch shortcut application to payment feature activation process
`
`$3-5
`
`|
`
`Processing userinputstoactivate paymentfeature on the handset
`
`Effect payment transaction from selected mobile payment account
`and output confirmation of payment
`
`$3-7
`
`$3-9
`
`END
`
`FIG. 3
`
`Apple Ex. 1028, p. 5
`Apple Ex. 1028, p. 5
` Apple v. Fintiv
`Applev.Fintiv
`IPR2020-00019
` IPR2020-00019
`
`

`

`Patent Application Publication
`
`Apr. 19, 2012 Sheet 5 of 9
`
`US 2012/0095852 Al
`
`,MlessecauseAjuo,.PanboysAemy,
`
`SpowNid4eUuD
`
`
`
`
`
`
`
`S91AEqaliqoyy
`
`LYVLS
`
`
`
`SOdJuouoay
`
`eyOld
`
`Bey48!YNidJeseu
`
`BeyPayloadNid18S
`
`
`
`Nid$0Junosayepdr
`
`sjdweyeAjue
`
`e-rS
`
`
`
`Defposinbas-Ajua-Nid
`
`yuasald
`
`éSOd0}Jospuey
`cEP2ls}USNid
`NidJ0f}dtudsd
`SliqouipueSOdF
`
`
`
`,Sulyeyspuey,soinep
`
`
`
`
`
`WO@POdSAIQDOY10.N9
`
`
`
`29o1A9patiqow
`
`Li-bS
`
`Apple Ex. 1028, p. 6
`Apple Ex. 1028, p. 6
` Apple v. Fintiv
`Applev.Fintiv
`IPR2020-00019
` IPR2020-00019
`
`
`
`
`
`
`
`
`

`

`Patent Application Publication
`
`Apr. 19, 2012 Sheet 6 of 9
`
`US 2012/0095852 Al
`
`
`
`SO1AE]aIIGoy|
`
`Lo-v
`
`P2490]NidPS
`
`ECPS
`
`PaxD0}SINid
`
`
`
`
`
`yeu}uoyesipulAeldsiq
`
`
`
`
`
`SOdo1u0a/9
`
`ajpesaueg|SOA|Le-S|oNEpaleyveNi|ON91109
`
` ||GNANidJnoyymysenbaNidupimysenbai|uoyeZVOUNe
`
`
`9e-FSS¢-rS
`
`ayelauasuo}eZOUINE
`
`
`
`Ud}}BOIpU!pasayusuolyesipulparajus
`
`
`
`SEAASOA
`
`
`
`ON|BZ-FSee-rS
`
`
`
`
`
`SspueyjussaldgsakaliqowpueSOdy
`
`
`
`
`
`éSOdO}Suryeyspuey,eaiaap
`
`qvSls
`
`LES
`
`6e-vS
`
`SOdg9)uopeZoye
`
`penyusueIy
`
`
`
`uoRezOYNEaAeoey
`
`
`
`BOIASPSf!qowWWoy
`
`Apple Ex. 1028, p. 7
`Apple Ex. 1028, p. 7
` Apple v. Fintiv
`Applev.Fintiv
`IPR2020-00019
` IPR2020-00019
`
`
`
`
`
`
`
`

`

`Patent Application Publication
`
`Apr. 19, 2012 Sheet 7 of 9
`
`US 2012/0095852 Al
`
`
`
`
`
`uoHoesuedyjuauAedJo}
`
`yrs
`
`
`
`BuiuoisioepuoHeziuouny
`
`puesbeyNiguopaseq
`
`
`
`junoweWoyoesuel}
`
`Ses
`
`0}BeyYSUNidaredwog
`
`
`
`sBuniessaaias
`
`9F-¥S
`
`
`
`SpunyJosojsuel}yonpuoy
`
`
`
`uoloesueyanleoey
`
`
`
`SOd3Woyuoyonysul
`
`juawAeg
`
`Bbulsseo0ld
`
`luayshs
`
`yunoosoy
`
`juswsebeue|
`
`lua}shs
`
`6r-vS
`
`Le-7S
`
`
`
`JOUOHEWIYUOSJLUSUeLE
`
`SOd30}uonoesuey
`
`97DIA
`
`SS-¢S
`
`
`
`UOIEUNYUOSanlaoay
`
`
`
`uoyoesuedpaye|duosJo
`
`vS-PS
`
`
`
`JOuoNeuyuOSpusuedL
`
`ajiqow0}uonDesuedy
`
`aolnap
`
`
`
`
`
`so1Naqaliqoy
`
`6S-¢S
`
`GNa
`
`
`
`JOUON}BUUODBAIgI0y
`
`
`
`Widw)UOTesuel)
`
`
`
`JOAIESBIEMO|PPIW
`
`L£S-¥S
`
`
`
`JouoWeWyUuoSAejdsiq
`
`uOeSUEN
`
`
`
`Le-PS
`
`
`
`uonoesuey}usued|
`
`juewAed0}uoljonsysu
`
`
`
`wayshsBulsseooid
`
`SOda4
`
`eSvs
`
`QNA
`
`LS-7
`
`
`
`JouoyeusyuosAeydsiq
`
`SOduouoqoesueny
`
`
`
`JOUCI}EWIYUdDBAIsDay
`
`
`
`juewAedWoyUOHOesUeLy
`
`
`
`wajshsBulssaaoid
`
`Apple Ex. 1028, p. 8
`Apple Ex. 1028, p. 8
` Apple v. Fintiv
`Applev.Fintiv
`IPR2020-00019
` IPR2020-00019
`
`
`
`
`
`
`
`
`
`
`
`
`

`

`Patent Application Publication
`
`Apr. 19, 2012 Sheet 8 of 9
`
`US 2012/0095852 Al
`
`9S
`
`
`
`
`6S~aoutpayuryoeHPD
`yONOSDYSSS
`Nid8eo)
`
`s~4Gio)ce
`
`
`pled-eig
`
`2Z
`
`lg
`
`juewAedago;
`
`0]BPEUGLS40|||
`
`‘UOBUUYUOD|
`yuewhed|
`
`
`
`(9,Bny)iebuel
`
`NL
`
`O
`
`
`
`Esser
`
`eseysind
`
`payury|ZSavWag
`8G“Sls
`QPieg~8ld|(GHuppayo
`{OORTDARAOSSSOTEESEI
`UOHEUUYUOS|JUSUWAB¢
`SIQowWpsiD
`
`
`
`
`
`40}YONid
`
`eseyoind
`
`Apple Ex. 1028, p. 9
`Apple Ex. 1028, p. 9
` Apple v. Fintiv
`Applev.Fintiv
`IPR2020-00019
` IPR2020-00019
`
`
`
`
`
`

`

`Patent Application Publication
`
`Apr. 19, 2012 Sheet 9 of 9
`
`US 2012/0095852 Al
`
`
`
`
`
`
`
`ino,aaesapede
`sQuSEJUNEDdYjIpas52re“pledaugpuesderaieg&ANOA
`
`
`
`pieddelieg
`
`pouyoujueudedajnejep
`
`puoahopingpioshopiogGe
`
`LonCRUE
`
`uees
`
`
`
`
`
`Apple Ex. 1028, p. 10
`Apple Ex. 1028, p. 10
` Apple v. Fintiv
`Applev.Fintiv
`IPR2020-00019
` IPR2020-00019
`
`
`

`

`US 2012/0095852 Al
`
`Apr. 19, 2012
`
`METIIOD AND SYSTEM FOR ELECTRONIC
`WALLET ACCESS
`
`FIELD OF THE INVENTION
`
`[0001] This inventionrelates to a mobile payment account
`system, and moreparticularly to an improved mobile pay-
`ment application on a mobile device to enable more efficient
`and secured contactless paymentat an electronicpointofsale.
`BACKGROUND OF THE INVENTION
`
`[0002] Mobile payment account systems are generally
`known,in whichportable 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 U.S. 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 paymenttransaction from an electronic wal-
`let. For example, U.S. Pat. No. 7,707,113 to Sprint Commu-
`nications Company L.P. discusses a method of a portable
`electronic device providing payment froman electronic wal-
`let withdifferent 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
`paymentfrom the wallet after receiving the PIN. However, in
`another level of security, no PIN is required thus enabling
`efficient but unsecured paymenttransactions 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 maynot be required at the pointofsale,
`nor a challenge for a numeric passcode (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
`uponthe 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
`ofa phone now becomesimmediately available for lowdollar
`purchases without consumerverification prior to a purchase.
`The perpetrator can make as many low dollar transactions
`without being challenged for authentication and access the
`paymentaccount. 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] Whatis desired is a moreefficient mobile payment
`system and method whichfacilitates expedient and secured
`payment
`transactions
`from an electronic wallet, and
`improved prevention of fraudulent use of the electronic wal-
`let.
`
`SUMMARYOF THE INVENTION
`
`In one aspect of the present invention, a method is
`[0007]
`provided offacilitating 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 paymenttransaction, wherein said data includes a
`passcode for enabling access to the electronic wallet and a
`flag 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
`paymenttransaction 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]
`methodis providedoffacilitating 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 codein thefirst 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 ofembodimentsofthe 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. 26 is a block diagram showing the main func-
`tional elements ofthe mobile device shownin FIG. 2a accord-
`ing to embodiments ofthe invention.
`[0015]
`FIG. 3 is a flow diagramillustrating the main pro-
`cessing steps performed bythe mobile device of FIGS. 1 and
`2 in a mobile paymentprocess according to an embodiment.
`
`Apple Ex. 1028, p. 11
`Apple Ex. 1028, p. 11
` Apple v. Fintiv
`Applev.Fintiv
`IPR2020-00019
` IPR2020-00019
`
`

`

`US 2012/0095852 Al
`
`Apr. 19, 2012
`
`T'IG. 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 deviceas illustrated in FIG.3.
`
`[0017] FIG.5, which comprises FIGS. 5a to 5f illustrates a
`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 embodimentof the invention will now be
`described for a process for conducting a paymenttransaction
`using a mobile device at a merchant’s electronic pointof 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 knownin thefield, and a account management system
`7 associated with a payment account issuer 10, which com-
`municate electronically with one another. The account man-
`agement 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 co-pending application U.S. Ser. No. 12/891,866.
`Aswill be described below, the account managementsystem
`7 may include a communications server 13 and a Trusted
`Service Manager (TSM) 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 accountissuer
`10, for example in response to payment transaction instruc-
`tions received via a payment association network 17. Inthis
`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-soniclink, an optical link, a radio frequency(eg.
`RFID)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
`embodimentincludes a secure memory 4 storing payment
`account data 6 for one or more mobile payment accounts that
`have beenset up on the mobile device 3. The secure memory
`4 mayfor 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 card—otherwise knownas a micro SD
`card, as are knownin 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 amountof pre-paid funds that have
`been transferred from the user’s payment accountissuer 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/orcredit account.
`Asanalternative, the electronic wallet mayinclude a plurality
`ofmobile payment accounts, each linked 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 exampleto 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-
`chantvia the electronic POS terminal 5 using a mobile pay-
`ment account on the mobile device3, to effectively transfer
`funds from the mobile payment account on the mobile device
`3 or an associated payment accountissuer 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 componentsofan operating system running
`on 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
`launchedbythe user, so as to carry out the above operations.
`Alternatively, the payment accountwallet application module
`8 maybestored 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-sccure mobile payment accountprovisioning and
`activation process may be carried out between the mobile
`device 3 and the account managementsystem7, as described
`in the Applicant’s above referenced co-pending application
`USS. 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 amountof funds can
`be transferred from the mobile payment accountstored in the
`mobile device 3 to the merchant’s bank 12. Techniques and
`protocols for implementing the authorization and transfer of
`funds between the merchant POS terminal 5, the merchant
`bank 12, and the payment accountissuer 10, for example via
`the paymentassociation network 17, are commonly known
`and will be apparentto 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
`Applev.Fintiv
`IPR2020-00019
` IPR2020-00019
`
`

`

`US 2012/0095852 Al
`
`Apr. 19, 2012
`
`[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 networkinterface 14 ofthe communicationsserver 13.
`The TSM server 18 may performlogical data preparation of
`the data to be communicated to the mobile device, for
`example by forming appropriate commandsto 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 paymentasso-
`ciation scheme program for facilitating payment. The TSM
`server 18 may also perform encryption of the data, for
`example of the sensitive payment account information in the
`mobile payment account data 6 such as payment keys. The
`TSMserver 18 may then pass the encrypted data to the mobile
`device 3 via the communications server 13 and the cellular
`
`quency link, or any other suitable communication channel.
`management system 7 used in embodiments of the present
`Yor instance, communication path 73 may be implemented
`invention. As shown, the account management system 7 may
`include a communicationsserver 13, a middleware server 16,
`using a combination of channels. As those skilled in the art
`will appreciate, the communication path 73 may be linked or
`and a Trusted Service Manager (TSM)server 18, which com-
`merged with the communication path from the cellular net-
`municate electronically with one another. In this embodi-
`ment, the servers communicate with one another via secure
`work interface 33 to the cellular telephone network 11.
`networklinks, for example overaprivate Local Area Network
`[0030] As mentioned above, the mobile device 3 includes a
`(LAN), a VPN connection,or other dedicated secure connec-
`secure memory 4. The mobile device 3 is operable to receive
`tion. As those skilled in the art will appreciate, although the
`the payment account data 6 and activation request messages
`components of the account management system 7 in this
`from and send validation messages to the account manage-
`embodimentare provided as separate servers, one or more of
`ment system 7 via a cellular telephone network interface 33
`the servers could be provided as software and/or hardware
`and the cellular telephone network 11, and to store the
`modules in the sameserver.
`received payment accountdata 6 in the secure memory 4. The
`mobile device 3 is also operableto receive transaction autho-
`nization 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-
`municationslink 9. As those skilled in the art will appreciate,
`communication between a POS terminal 5 and the mobile
`device 3 mayinvolvetransmissionofdatain a single direction
`from the mobile device 3 ta 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
`telephone network 11.
`[0026] The communications server 13 may also include a
`which store processing instructions to create a request for a
`separate TSM unit 15 for securely routing the data to the
`new mobile payment account if desired and to carry out a
`mobile device 3, as will be knownto the skilled person. In the
`secured account validation and activation process,
`in
`above example,
`the TSM unit 15 in the communications
`responseto user input from the keypad 23, as described in the
`server 13 would not accessany ofthe sensitive portionsof the
`above-referenced Applicant’s co-pending application Ser.
`encrypted data that is routed to the mobile device 3 via the
`No. 12/891,866. The payment account module8also includes
`cellular telephone network interface 14.
`a transaction authorization sub-module which stores process-
`[0027] Mobile Device
`ing instructions used to controlthe operation ofthe controller
`[0028]
`[TIG.2, which comprises IGS. 2a and 24, showsthe
`21 to carry out and authorize a transaction in response to user
`elements of the mobile device 3 according to an embodiment
`input from the user interface 22. The mobile payment wallet
`application module 8 may be configuredto store a plurality of
`of the present invention. In this embodiment, the mobile
`device 3 is a mobile handset and as shown in FIG. 2a, the
`wallet screens 24 and an account access screen 26 which may
`be output on display 23 of the user interface 22 to facilitate
`mobile handset operating system and hardware includes a
`user interaction with the sub-modules of the mobile payment
`user interface 22 arranged to process inputs from a keypad 23
`wallet application module 8. One wallet screen is a main
`and to control output on a display 25. As those skilled in the
`menu wallet screen 26 which maybedisplayed initially by the
`art will appreciate, the keypad 23 and display 25 may be
`wallet application module 8 in response to a user commandto
`provided as separate hardware entities of the mobile device 3
`launch the wallet application. The mobile device 3 mayalso
`or mayalternatively be provided as an integrated entity, for
`store one or more non-payment application modules 29
`example as a touch sensitive display screen user interface
`including processing instructions used to contral the opera-
`elementas is knownin the art. The mobile device 3 may also
`tion of the mobile device 3 to perform other non-payment
`include components included in commonly known mobile
`related processes.
`handsets, such as a microphone, an earpiece speaker, camera
`and controller, GPS sensors etc, which are not shown for
`[0032]
`In this embodiment, the mobile device 3 further
`clarity. A working memory 27 is provided for use by the
`includes a payment shortcut module 19 that provides a short-
`handset operating system and hardware units 21.
`cut to the payment feature within the mobile payment wallet
`[0029]
`Software and data maybetransferred via the cellu-
`application module 8. The shortcut may be implemented as
`lar network interface 33 or viaa different data communication
`processing instructionsthat link to the processing instructions
`link interface 71 for examplein the form of signals 72, which
`of the transaction authorization sub-module. Alternatively,
`maybeelectronic, electromagnetic, optical, or other signals
`the payment shortcut module 19 may comprise separate pro-
`capable of being received by the data communication link
`cessing instructions used to control the operation of the con-
`interface 71 via a communication path 73 that carries the
`troller 21 to carry out and authorize a transaction in response
`signals 72 and may be implemented using wire or cable, fiber
`to user input from the user interface 22. Provision of the
`optics, a physical phone line, a wireless link, a radio fre-
`payment shortcut module 19 advantageously enables an
`
`Apple Ex. 1028, p. 13
`Apple Ex. 1028, p. 13
` Apple v. Fintiv
`Applev.Fintiv
`IPR2020-00019
` IPR2020-00019
`
`

`

`US 2012/0095852 Al
`
`Apr. 19, 2012
`
`improveduserinterface 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]
`Inan embodiment, the mobile paymentwallet 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 bedirect 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.
`[9034] Also schematically illustrated in the exemplary
`embodiment of FIG. 2a are a plurality of security domains
`which may be implemented in the secure memory4 of the
`mobile device 3. ‘The security domains serve to segment the
`management and accessibility of variousparties’ functional-
`ity and sensitive data as will be apparentto those skilled in the
`art. As shown in FIG.2a, 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
`paymentsecurity domain 32 may also include a Proximity
`Payment System Environment (PPSF) package 41, a PPSE
`controller instance 42 for facilitating the transaction pracess-
`ing, functionality between the payment applet instances 40
`and the contactless link interface