1111111111111111 IIIIII IIIII 1111111111 11111 1111111111 1111111111 11111 11111 1111111111 11111111
`c19) United States
`
`
`c12) Patent Application Publication
`c10) Pub. No.:
`US 2011/0251892 Al
`
`(43) Pub. Date: Oct. 13, 2011
`Laracey
`
`US 20110251892Al
`
`(54)MOBILE PHONE PAYMENT PROCESSING
`
`METHODSAND S YSTEMS
`
`(76)Inventor:
`
`
`
`
`
`Kevin Laracey, Natick, MA (US)
`
`(21)Appl. No.:
`
`12/846,911
`
`Publication Classification
`
`
`(51)Int. Cl.
`G06Q 20100(2006.01)
`H04N 51225 (2006.01)
`G06Q 30/00(2006.01)
`
`
`
`(52)U.S. Cl. ..... 705/14.51; 705/16; 705/42; 348/207.99;
`348/E05.024
`
`(22)Filed:
`
`Jul. 30, 2010
`
`(57)
`ABSTRACT
`Embodiments provide systems, methods, processes, com­
`
`
`
`Related U.S. Application Data
`
`
`puter program code and means for using mobile devices to
`
`
`
`
`conduct payment transactions at merchant locations includ­
`
`
`
`(60) Provisional application No. 61/322,477, filed on Apr.
`
`
`
`
`ing brick and mortar locations and remote locations as well as
`
`
`
`
`9, 2010, provisional application No. 61/362,567, filed
`
`
`for person to person transactions.
`
`on Jul. 8, 2010.
`
`c114
`l
`
`136
`
`(1�
`
`◄
`.. MERCHANT
`
`138
`
`/ 100
`
`(108
`
`l (130
`
`(11! TRANSACTION
`SYSTEM
`
`MANAGEMENT
`
`IPR2022-01239
`Apple EX1004 Page 1
`
`

`

`
`
`US 2011/0251892 Al
`Patent Application Publication
`
`
`Oct. 13, 2011 Sheet 1 of 15
`
`/ 100
`
`c114
`l
`c1�
`
`136
`
`(108
`
`◄ c11!
`
`MERCHANT
`
`l (130
`TRANSACTION
`
`MANAGEMENT
`SYSTEM
`
`138
`
`FIG. 1
`
`IPR2022-01239
`Apple EX1004 Page 2
`
`

`

`
`>....
`
`N
`1,0
`
`Ul .... QO
`0 .... ....
`
`N
`
`rJJ
`c
`
`N
`
`
`
`---0
`
`0 .... .... Ul
`('D .....
`rJJ =­('D
`0 .... ....
` � �
`
`N
`
` .......0(')
`
`
`
`N
`
`=
`
`. (') � ......... 0
`. (') � ......... 0
`t "e
`= .....
`""O � .....
`
`-...
`
`('D
`
`O"
`=
`""O
`=
`
`-...
`
`PROCESSING
`PAYMENT
`
`MANAGEMENT
`TRANSACTION
`
`232
`
`230
`
`SYSTEM
`
`-7
`
`I
`
`___,--20,
`
`SERVICES
`
`OTHER
`
`242
`
`\\£B
`
`240
`
`SERVICES
`LOCATOR
`
`_e_l30
`
`I
`I
`I
`I
`1
`I
`I
`xxxx I
`
`238
`
`=
`
`237
`236
`
`1 r=---=---=---=---=---:!_ -
`,---
`
`L_
`I
`I
`I 'ti.XX �----' MERCHANT
`___, I
`1213 --212 ----209-l-_.,,-208
`
`SYSTEM
`
`r-----1-
`
`�
` .---'--
` I
`210
`
`2
`
`20
`
`FIG. 2
`
`L ______________ J
`I
`
`.__ _ __. I
`POINT
`ACCESS I
`I
`I
`I
`I
`
`218
`
`215
`
`NEftK I
`I
`
`216
`
`\A
`
`·�
`
`I ��
`
`/V A'°
`-----
`
`IPR2022-01239
`Apple EX1004 Page 3
`
`

`

`US 2011/0251892 Al
`Patent Application Publication
`
`
`Oct. 13, 2011 Sheet 3 of 15
`
`
`
`,302
`
`ACCESS REGISTRATION
`
`SERvER
`
`304
`' (
`
`
`
`ESTABLISH ACCOUNT
`
`306
`1 ' (
`
`IDENTIFY PAYMENT
`
`ACCOUNT(S)
`
`'I
`
`308
`
`IDENTIFY RULE(S) AND
`
`
`PREFERENCE{S)
`
`1 ' ( 310
`
`DOWNLOAD ANO INSTALL
`
`APPLICATION
`
`FIG. J
`
`IPR2022-01239
`Apple EX1004 Page 4
`
`

`

`Oct. 13, 2011 Sheet 4 of 15
`
`Patent Application Publication
`
`
`
`
`
`TOTAL PURCHASE TRANSACTION AT POINT OF SALE
`
`402
`
`406
`
`NO
`
`CONTINUE STANDARD
`
`
`PAYMENT PROCESSING
`
`YES
`
`408
`
`TRANSMIT MERCHANT PAYMENT AUTHORIZAllON REQUEST,
`
`
`
`
`
`
`
`
`INCLUDING MERCHANT CHECKOUT TOKEN, AMOUNT, AND
`
`
`
`TRANSACTION DATA TO TRANSACTION MANAGEMENT SYSTIEM
`
`410
`
`
`
`
`
`DISPLAY CHECKOUT TOKEN TO CUSTOMER
`
`RECEIVE PAYMENT AUTHORIZATION FROM
`
`
`
`
`
`TRANSACTION MANAGEMENT SYSTIEM
`
`412
`
`414
`
`GENERATE TRANSACTION RECEIPT TO
`
`
`
`
`COMPLETE TRANSACTION
`
`FIG. 4A
`
`IPR2022-01239
`Apple EX1004 Page 5
`
`

`

`
`Patent Application Publication
`
`
`Oct. 13, 2011 Sheet 5 of 15 US 2011/0251892 Al
`
`
`
`422
`
`
`
`
`
`LAUNCH MOBILE PAYMENT APPLICATION
`
`
`
`
`
`
`
`
`
`PROMPT CUSTOMER TO ENTER AUTHENTICATION INFORMATION
`
`424
`
`428
`
`NO
`
`PRESENT ALTERNATIIJE
`
`PA'rMENT
`
`
`
`CAPTURE CHECKOUT TOKEN
`
`430
`
`432
`
`TRANSMIT CUSTOMER TRANSACTION LOOKUP REQUEST AND
`
`
`
`
`
`
`
`CHECKOUT TOKEN TO TRANSACTION MANAGEMENT SYSTEM
`
`434
`
`RECEIVE TRANSACTION DETAILS AND PAYMENT ACCOUNT
`
`
`
`
`
`
`
`INFORMATION FROM TRANSACTION MANAGEMENT SYSTIEM
`
`PRESENT TRANSACTION DETAILS AND ENHANCED
`
`
`
`
`
`PAYMENT ACCOUNT CHOICES TO CUSTOMER
`
`436
`
`RECEIIJE PAYMENT ACCOUNT SELECTION AND REQUEST
`
`
`
`
`
`CONFIRMATION OF SELECTION, PAYMENT AMOUNT
`& MERCHANT
`
`438
`
`440
`
`TRANSMIT CUSTOMER PAYMENT AUTHORIZATION REQUEST
`
`
`
`
`
`
`
`TO TRANSACTION MANAGEMENT SYSTEM FOR PROCESSING
`
`442
`
`
`
`
`
`RECEIVE TRANSACTION COMPLETE MESSAGE
`
`
`
`FIG. 48
`
`IPR2022-01239
`Apple EX1004 Page 6
`
`

`

`
`
`Patent Application Publication
`
`
`
`Oct. 13, 2011 Sheet 6 of 15 US 2011/0251892 Al
`
`452
`/ 450
`RECEIVE MERCHANT PAYMENT AUTHORIZATION REQUEST,
`
`
`
`
`
`
`
`TRANSACTION DATA AND ASSIGN CHECKOUT TOKEN
`
`454
`
`INSERT MERCHANT PAYMENT AUTHORIZATION REQUEST
`
`
`
`
`INTO MERCHANT TRANSACTION QUEUE
`456
`
`
`
`RECEIVE CUSTOMER AUlHENTICA TION REQUEST
`
`
`
`
`
`460
`
`TRANSMIT
`NO
`
`;;,----.� AUTHENTICATION DENIAL
`TO MOBILE DEVICE
`
`462
`
`
`
`
`
`
`
`llRANSMIT AUlHENTICATION RESPONSE TO MOBILE DE\ilCE
`464
`
`RECEIVE CUSTOMER TRANSACTION LOOKUP REQUEST
`
`
`
`
`
`
`MESSAGE INCLUDING CUSTOMER CHECKOUT TOKEN
`466
`
`MATCH CUSTOMER CHECKOUT TOKEN 1MTH MERCHANT
`
`
`
`
`CHECKOUT TOKEN AND RETIRIE\/E PAYMENT DETAILS
`468
`
`RETRIEVE CUSTOMER PAYMENT ACCOUNT INFORMATION AND
`
`
`
`
`
`
`TRANSMIT �TH TIRANSACTION DETAILS TO MOBILE DEIJICE
`470
`
`RECEIVE CUSTOMER PAYMENT AUTHORIZATION REQUEST
`
`
`
`
`
`
`INU.UDING CUSTOMER PAYMENT ACCOUNT SELECTION
`
`472
`
`RETIRIEVE ACTUAL PAYMENT PAYMENT CREDENTIALS BASED
`
`
`
`
`
`
`
`ON RECEI\/ED CUSTOMER PAYMENT ACCOUNT SELECTION
`474
`
`OBTAIN PAYMENT AUTHORIZATION FROM PAYMENT NETWORK
`
`
`
`
`
`USING ACTUAL PAYMENT CREDENTIALS
`476
`
`TRANSMIT PAYMENT AUTHORIZATION TO MERCHANT AND
`
`
`
`CONFIRMATION
`TO MOOILE DEVICE
`FIG. 4C
`
`IPR2022-01239
`Apple EX1004 Page 7
`
`

`

`
`
`Oct. 13, 2011 Sheet 7 of 15
`
`Patent Application Publication
`US 2011/0251892 Al
`
`/ 500
`
`516
`
`514
`
`532
`CUSTOMER
`MANAGEMENT
`SYSTEM
`
`504
`PAYMENT ACCOUNT­
`
`GA1£WAY
`
`
`THIRD PARTY SERVICE
`
`INlEGRA TION
`INTEGRATION
`512
`
`�-__.____._� PAYMENT ACCOUNT­
`PAYMENT
`MANAGEMENT
`
`PROCESSING SYSTEM
`r5os
`SYSTEM
`_____IPHONE
`
`r MOBILE APPLICATION
`518
`530
`MERCHANT
`TRANSACTION
`
`- MOBILE GATEWAY ,s10
`MANAGEMENT
`MANAGEMENT
`SYSTEM
`SYSTEM
`ANDROID
`L.-----MOBILE APPLICATION
`522
`36
`[COMMERCE
`MERCHANT POS
`
`�
`INTEGRATION
`PLAlfORM
`SYSTEM
`
`INlEGRA TION
`�
`26
`r524
`r52B
`�
`SECURITY
`�4
`ADMIN PORTAL
`
`MANAGEMENT
`SYSTEM
`�
`�
`
`I
`I
`r----------.1
`I s20
`
`FIG. 5
`
`IPR2022-01239
`Apple EX1004 Page 8
`
`

`

`Patent Application Publication
`
`Oct. 13, 2011 Sheet 8 of 15
`
`US 2011/025 1892 A1
`
`
`
`604
`
`GATEWAY
`CONNECTOR
`
`CUSIOWER
`MANAGEMENT
`
`SECURITY
`MANAGEMENT
`
`63
`
`MERCHANT
`DS
`ADSERS WENT
`SYSTEM
`SYSTEM
`
`MOBILE GATEWAY
`
`(o)
`
`(b)
`
`TRANSACTION
`MANAGEMENTSYSTEM
`('sign
`60S city
`
`POS GATEWAY
`
`IPR2022-01239
`Apple EX1004 Page 9
`
`

`

`j
`
`' �
`
`' �
`
`t
`
`j I
`
`l
`
`'.
`
`i l
`
`.... 0
`
`,na
`
`-...
`
`. (') � .....
`t "e
`= .....
`""O � .....
`
`('D
`
`(726
`
`(122__ (724
`
`/700
`
`r_718
`
`(714 (716
`
`MAGNETOMETER
`
`AUDIO
`
`COMMUNICATION
`
`WIRELESS
`
`CAMERA
`
`SENSOR
`PROXIMITY
`
`DEVICE
`
`ACCELEROMElER
`
`BIOMETRICS
`
`PHOTOELECTRIC
`cno
`
`....
`>
`
`N
`1,0
`.... QO
`
`Ul
`N
`0
`.... ---
`....
`
`0
`N
`
`rJJ
`c
`
`.... Ul
`....
`
`0
`
`1,0
`
`('D .....
`
`=­('D
`
`
`
`rJJ
`
`....
`....
`
`0
`N
`
` ��
`
`:-+- ....
`
`(')
`0
`
`=
`
`.... 0
`
`= (') � .....
`O"
`a'
`=
`
`RG. 7
`
`738)
`DEVICES
`PROCESSOR{S) CONTROLLER(S)
`INPUT
`/CONTROL
`OlliER
`
`l134
`
`I
`
`- �
`OTHER INPUT �
`
`-
`
`,104
`
`INTIERFACE
`. ' .
`MEMORY
`!
`,102
`
`PPLICATION n
`
`•
`
`• -
`
`•
`
`-A
`
`712 --
`
`L105
`
`•
`
`SCREEN
`TOUCH
`
`CONTROLLER
`TOUCH-SCREEN
`
`--
`
`(736
`
`(
`
`1/0 SUBSYSTEM
`
`--
`--732
`,130
`
`--
`
`-
`-
`
`INTIERFACE
`PERIPHERALS
`'
`
`' ' .
`
`' r , r
`
`I 1
`
`,
`
`'
`
`, r '
`
`TION 1
`
`710-1APPUCA
`
`,1oa
`
`IPR2022-01239
`Apple EX1004 Page 10
`
`

`

`Patent Application Publication
`
`Oct. 13, 2011 Sheet 10 of 15
`
`US 2011/025 1892 A1
`
`
`
`Scan Payment Code
`Manually enter code
`
`Anolyzing payment code
`
`)
`
`CLP
`
`ACCOUNTS
`
`MORE
`
`FIG. 3A
`
`836
`
`840
`
`842
`
`IPR2022-01239
`Apple EX1004 Page 11
`
`

`

`Patent Application Publication
`
`Oct. 13, 2011 Sheet 11 of 15
`
`US 2011/0251892 A1
`
`
`
`F
`PetPOce
`
`Hello Richard Petxtra Occount 2480789
`Regular price $39.09, PetExtra price $34.00
`You saved $5,09 today with PetFxtrol
`PetPlace Store
`112
`OCe 1745 W Home Rood
`Phoenix, AZ 85O15
`PetP
`PetPerks Credit. 685
`PetPOce
`Available: $500,00
`Additional 5% off if used today
`PetPerks Debit.8888
`PetPlace
`Available: 428.50 CD
`
`O)
`s in
`
`PetPOCe Gift. 358
`PetPOce
`Available: $100.00
`
`FIG. 8B
`
`IPR2022-01239
`Apple EX1004 Page 12
`
`

`

`Patent Application Publication
`
`Oct. 13, 2011 Sheet 12 of 15
`
`US 2011/025 1892 A1
`
`
`
`Merchant
`
`Dote
`
`PetPloce
`
`Mar 29, 2010 03:49 PM
`
`Payment Method
`
`Petxtro Credit
`
`Location
`
`Toto
`
`Confirm
`
`FIG. 8C
`
`IPR2022-01239
`Apple EX1004 Page 13
`
`

`

`Patent Application Publication
`
`Oct. 13, 2011 Sheet 13 of 15
`
`US 2011/0251892 A1
`
`
`
`PetPOce
`Save $2.00
`SuperDog
`On (6) cons of SuperDog
`dogfood, Ony variety
`
`5
`
`PetPOce
`
`Mgr 29, 2010 05:49 PM
`
`Phoenix, AZ 8505
`
`$34,00x
`
`$5.09
`
`MerchOnt
`
`Oote
`
`LOCotton
`
`Total
`
`PetExtra Sovings Todoy
`
`FIG. 3D
`
`IPR2022-01239
`Apple EX1004 Page 14
`
`

`

`Patent Application Publication
`
`Oct. 13, 2011 Sheet 14 of 15
`
`US 2011/0251892 A1
`
`
`
`802
`
`/ 800
`
`Thank you for purchasing at
`PetPOCe
`
`836
`
`858
`
`FIG. BE
`
`IPR2022-01239
`Apple EX1004 Page 15
`
`

`

`Patent Application Publication
`
`Oct. 13, 2011 Sheet 15 of 15
`
`US 2011/0251892 A1
`
`
`
`
`‘OOld SHWES
`'##### Nyd
`
`6 OLJ
`
`
`
`(S)HON}}}}}d
`
`800||
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`IPR2022-01239
`Apple EX1004 Page 16
`
`

`

`US 2011/025 1892 A1
`
`Oct. 13, 2011
`
`MOBILE PHONE PAYMENT PROCESSING
`METHODS AND SYSTEMS
`
`CROSS REFERENCE TO RELATED
`APPLICATIONS
`
`0001. The present application is based on, and claims ben
`efit and priority of U.S. Provisional Patent Application Ser.
`Nos. 61/322,477 (filed on Apr. 9, 2010), and 61/362.567 (filed
`on Jul. 8, 2010) the contents of each of which are incorporated
`herein in their entirety for all purposes.
`
`BACKGROUND
`
`0002 Credit cards, debit cards and other payment cards
`have been in use for years. The manner in which these pay
`ment cards are used is Substantially unchanged since their
`introduction—a cardholder presents their payment card to a
`merchant, who uses a magnetic stripe reader to read the
`cardholder's payment account information, and then the mer
`chant transmits the payment account information along with
`transaction details to a payment network for authorization,
`clearing and settlement. While this approach has worked
`well, there are a number of disadvantages associated with it.
`0003 For example, not all merchants are able to properly
`secure the user information that is read from a payment card.
`There have been a number of highly publicized incidents
`where cardholder data was stolen from merchant systems. In
`other incidents, employees directly skimmed or copied card
`holder data and used it for fraudulent transactions. If mer
`chants are required to continue to read, store and transmit
`payment card information, such thefts will persist. Further,
`the systems and procedures required to properly save, store
`and transmit cardholder information is a significant cost to
`merchants. It would be desirable to provide systems and
`methods in which payment card information is not stored,
`captured, or transmitted by merchants.
`0004 As another example disadvantage, current payment
`cards are typically associated with a single payment account.
`A cardholder may have a number of payment cards, but must
`make a conscious decision regarding which one (or ones, in
`the case of a split tender transaction) of those payment cards
`to use in a given transaction. It would be desirable to provide
`systems and methods which allow a customer to select one or
`more payment accounts for use in conducting a transaction.
`Further, it would be desirable to provide a customer with
`information about which account(s) should be used in a given
`transaction (e.g., in order to save on transaction costs, to earn
`rewards, to manage balances and spend, etc.).
`0005. Another disadvantage of existing payment systems
`is that current payment cards are unable to easily be used in
`conjunction with mobile devices such as Smartphones. Some
`payment card associations and issuers have proposed the use
`of RFID chips or tags installed on mobile phones as a way to
`allow payment card information to be presented at a point of
`sale location. However, Such solutions require that point of
`sale devices have RFID readers installed. The installation of
`Such devices is expensive and time consuming. It would be
`desirable to provide an ability to conduct purchase transac
`tions (both online and at brick and mortar stores) using a
`mobile device.
`
`0006. These, and other, problems are solved by using sys
`tems and methods of the present invention. Other advantages
`and features will become apparent upon reading the following
`disclosure.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`0007 FIG. 1 is a block diagram depicting a payment sys
`tem configured pursuant to some embodiments.
`0008 FIG. 2 is a block diagram depicting further details of
`a payment system configured pursuant to some embodiments.
`0009 FIG. 3 is a flow diagram depicting a customer reg
`istration process pursuant to some embodiments.
`0010 FIGS. 4A-4C are flow diagrams depicting a trans
`action process pursuant to some embodiments.
`0011
`FIG. 5 is a block diagram depicting system compo
`nents of a system pursuant to Some embodiments.
`0012 FIG. 6 is a block diagram depicting a transaction
`flow pursuant to Some embodiments.
`0013 FIG. 7 is a block diagram depicting components of
`a mobile device pursuant to some embodiments.
`0014 FIGS. 8A-8E are sample user interfaces associated
`with embodiments of the present invention.
`0015 FIG. 9 is a table depicting a portion of a customer
`database pursuant to Some embodiments.
`
`DESCRIPTION
`0016 Embodiments of the present invention relate to sys
`tems, methods, processes, computer program code, and
`means for using mobile devices to conduct payment transac
`tions at merchant locations including brick and mortar loca
`tions and remote (e.g., such as Internet or mail order and
`telephone) locations, as well as for person to person transac
`tions. In some embodiments, the mobile device can be used to
`initiate and conduct payment transactions involving a number
`of different payment accounts, including, for example, credit,
`debit, deposit, stored value, checking and other accounts. In
`Some embodiments, a mobile device configured using fea
`tures of the present invention may be capable of initiating
`payment transactions that are processed over a variety of
`different payment networks (e.g., such as the credit card
`networks operated by Visa, Inc. or MasterCard International
`Incorporated, private label processing networks, electronic
`funds transfer networks, Automated Clearing House net
`works, or the like). In some embodiments, mobile devices
`configured using features of the present invention are capable
`of determining or Suggesting a most desirable payment
`account to use in a given transaction (e.g., based on one or
`more predefined user-specified rules, account characteristics,
`merchant information or the like). In this manner, users are
`provided with greaterpayment options and better information
`about which payment account to use in any given transaction.
`0017 Pursuant to some embodiments, transaction meth
`ods, systems, apparatus, means and computer program code
`are provided for conducting payment transactions which
`include selecting a mobile payment option at a point of sale,
`obtaining, using a mobile device, a checkout token printed or
`otherwise displayed at the point of sale, selecting, using said
`mobile device, a payment account, viewing, on the mobile
`device, payment transaction details associated with a pending
`payment transaction, and authorizing, using the mobile
`device, the payment transaction. Pursuant to some embodi
`ments, the checkout token is obtained by the mobile device by
`
`IPR2022-01239
`Apple EX1004 Page 17
`
`

`

`US 2011/025 1892 A1
`
`Oct. 13, 2011
`
`capturing a barcode image, key entering the checkout token,
`by wireless communication or otherwise receiving the check
`out token at a mobile device.
`00.18 Embodiments of the present invention are believed
`to provide desirable advantages from a fraud reduction stand
`point, as the chance for fraud is low, and PCI compliance is
`made very easy for the merchant for a variety of reasons,
`including: (i) the customer's actual payment credentials are
`never provided to a merchant, and (ii) the customer's payment
`credentials can never be accessed for use in a payment trans
`action unless the access request is coming from one of the
`authorized devices that has been designated by the customer
`as having access to the customer's payment credentials.
`0019. A number of terms are used herein for convenience
`and ease of exposition. For example, the term “capture' will
`be used to refer to the act of Scanning, reading or other
`capturing of a “checkout token' (an identifier used to facili
`tate transactions pursuant to some embodiments). The term
`“capturing (or “captured) is not intended to be limiting, and
`is intended to encompass embodiments where a mobile
`device is operated to receive a checkout token (or data asso
`ciated with a checkout token) via key entry, via image capture,
`via RFID reading, and using other Scanning, reading, or other
`techniques described herein. Pursuant to some embodiments,
`the term "capture' further includes any decoding or image
`processing of a checkout token required to retrieve or other
`wise obtain information from the checkout token.
`0020. As another example, the term "wireless” is used to
`refer to unwired remote communication techniques, such as,
`for example, using radio frequency or other electromagnetic
`radiation based communication techniques (including RFID,
`wifi. Bluetooth, Zigbee or other techniques). Those skilled in
`the art, upon reading this disclosure, will appreciate that the
`use of these terms is not intended to be limiting, but for the
`purposes of exposition.
`
`INTRODUCTION
`Illustrative Examples
`0021 Embodiments of the present invention allow cus
`tomers to make purchases at merchant locations using their
`mobile devices. In the following, a number of processes and
`transaction flows will be described. To help in describing
`those processes and transaction flows, two illustrative
`example users will now be introduced. The examples will be
`used to illustrate features of some embodiments and to aid in
`describing certain features of the present invention. The
`examples are not intended to be limiting and are merely
`provided for illustration.
`0022. A first example user is referred to herein as "Jane'.
`In the example, Jane has four payment accounts that she uses
`on a regular basis: (i) a high interest rate credit card, (ii) a
`checking account, (iii) a debit card linked to her checking
`account, and (iv) a StarbuckSR gift card. Jane only likes to use
`her credit card when she has to, and always wants to make
`sure that she keeps at least S1,000 in her checking account.
`Jane also prefers, when possible, to reduce the amount offees
`she has to pay for any transaction.
`0023. A second example user is referred to herein as
`"Sam'. In the example, Sam has five payment accounts that
`he uses regularly: (i) a rewards credit card, (ii) a private label
`Sears(R credit card, (iii) a checking account, and (iv) an
`American Express(R charge card that Sam uses for work
`related expenses. Sam prefers to earn rewards when possible,
`
`which he earns with his rewards credit card and his Sears
`private label card (when shopping at Sears), and to put any
`business-related expenses on his American Express charge
`card.
`0024. Both Sam and Jane have mobile phones. Sam has a
`mobile phone that has a Web browser, and Jane has an Apple
`iPhone(R). Sam will access and use the payment system of the
`present invention using his phone's browser, while Jane will
`access and use the payment system of the present invention by
`downloading and configuring an iPhone(R) application (or
`“app') configured to facilitate payment transactions pursuant
`to the present invention.
`0025. Using features of the present invention, customers
`Such as Jane and Sam may use their mobile devices to pay for
`products or services at point of sale (or “POS) locations.
`Merchants need not modify their point of sale hardware (al
`though some embodiments involve the merchant displaying a
`checkout token on a point of sale display terminal) and users
`may pay using their existing payment accounts. Embodi
`ments allow users to choose among a variety of payment
`accounts to use the most appropriate or most desirable pay
`ment account for a given transaction. Embodiments also
`allow merchants, payment account issuers, and/or payment
`network operators to establish rules governing which pay
`ment instruments are made available for use on the phone.
`These illustrative examples will be used in conjunction with
`Some of the following description to aid in describing features
`of some embodiments of the invention. In FIG.1, an overview
`of a system according to the present invention will be
`described. In FIG. 2, a more detailed block diagram of some
`components of a system is provided. In FIG. 3, a customer
`registration process will be described, and in FIGS. 4A-C
`transaction processes will be described.
`(0026 System Overview
`0027 Features of some embodiments of the present inven
`tion will now be described by reference to FIG. 1, which is a
`block diagram of a system 100 pursuant to some embodi
`ments. As shown, a payment account holder, buyer, or other
`user or operator (hereafter, the “customer') may have or use
`a mobile device 102 (such as a mobile telephone or the like).
`The mobile device 102 has a display screen 136 and a data
`entry device 138 (such as a keypad or touch screen). Pursuant
`to embodiments of the present invention, the customer may
`use the mobile device 102 to conduct a purchase transaction
`with a merchant 108. The merchant 108 may be a physical
`storefront, electronic commerce merchant, or mail order and
`telephone (“MOTO”) merchant (or another person or entity).
`0028. In a typical example transaction, a customer may
`purchase products or services from the merchant 108 by first
`taking the products or services to a point of sale (e.g., Such as
`a physical checkout counter, an electronic shopping cart, or
`the like, generally referred to herein as the “point of sale” or
`“POS). The merchant 108 begins the checkout transaction as
`normal, by totaling the items to be purchased (e.g., by using a
`bar code scanner, key entry of product codes, or the like). The
`merchant (acting through a clerk, a display Screen, a POS
`terminal facing the customer, or the like) then prompts the
`customer to select a payment option. In prior systems, the
`merchant might prompt the customer to select “credit'.
`"debit or another payment option. Pursuant to the present
`invention, the merchant (acting through a clerk, display
`screen, a POS terminal facing the customer, or the like) may
`prompt the customer for those options as well as a mobile
`
`IPR2022-01239
`Apple EX1004 Page 18
`
`

`

`US 2011/025 1892 A1
`
`Oct. 13, 2011
`
`payment option. If the customer selects the mobile payment
`option, features of the present invention are utilized to process
`the transaction.
`0029. In some embodiments, rather than requiring the cus
`tomer to select the mobile payment option by an action (Such
`as by pushing a button on a POS terminal or communicating
`the choice to a clerk, etc.), the choice may be made by the
`customer's act of scanning, capturing or entering a checkout
`identifier (as discussed below). For example, in such embodi
`ments, the action of capturing the checkout identifier used in
`the present invention will cause the transaction to proceed
`pursuant to the present invention.
`0030) If the mobile payment option is selected, and once
`the purchase total has been generated, the merchant 108trans
`mits a merchant payment authorization request message to a
`transaction management system 130 (via path 116). The mer
`chant payment authorization request message may include
`one or more pieces of data or information about the transac
`tion. For example, the message may include one or more of a
`merchant identifier, the amount due, and a unique checkout
`token (“checkout token') which, as will be described further
`herein, is used to identify the merchant and the transaction for
`further processing.
`0031. A number of techniques may be used to generate or
`present the checkout token. For example, in some embodi
`ments, one or more checkout tokens may be predefined or
`established for use with a given merchant 108 (e.g., the mer
`chant 108 could have a number of checkout tokens available
`to display or present at the point of sale). In such embodi
`ments, the merchant 108 would choose a checkout token for
`use with a given transaction. In some embodiments, such
`checkout tokens may be generated or provided using a stan
`dardized format. As an illustrative example, a merchant 108
`may be issued or provided with a range of checkout tokens or
`a predefined series or sequencing of numbers. As a specific
`example, a merchant may be instructed to use a range of
`numbers (e.g., from "00000 to “99999') as well as a
`sequencing or usage pattern (e.g., a specific checkout token
`may only be used in conjunction with a single active transac
`tion). In such an embodiment, the POS system would pass a
`selected checkout token to the transaction management sys
`tem 130. In other embodiments, however, the checkout tokens
`are issued or selected by the transaction management system
`130 and are provided to the merchant 108 in response to a
`merchant authorization request message (as will be described
`further below). Those skilled in the art will recognize that
`other techniques for issuing, using and selecting checkout
`tokens may be used.
`0032 Pursuant to some embodiments, the checkout token
`is dynamically generated for each transaction. In some
`embodiments, the checkout token is a static identifier associ
`ated with an individual checkout location (e.g., Such as a
`specific point of sale terminal or location, or with a small
`business person Such as a plumber or electrician who has no
`specific checkout location, or with an individual). The mer
`chant 108 causes the checkout token to be displayed or pre
`sented to the customer. For example, the checkout token may
`be displayed on a display device associated with the mer
`chant, or pre-printed on a placard or other display near the
`point of sale.
`0033. From the customer perspective, the payment pro
`cess of the present invention may begin with the customer
`performing an authentication process to confirm their identity
`and authority to conduct transactions using the present inven
`
`tion. The authentication process may be performed after, or in
`Some situations, prior to the customer's selection of the
`mobile payment option at the point of sale. Pursuant to some
`embodiments, the authentication process serves to authenti
`cate the customer to the transaction management system 130.
`The authentication process may involve the customer launch
`ing a mobile payment application or a Web browser on the
`mobile device 102 and providing one or more credentials or
`items of information to the transaction management system
`130 via communication path 114. For example, the authenti
`cation process may involve the entry of a user identifier, a
`password, or other credentials into a login screen or other user
`interface displayed on a display device 136 of the mobile
`device 102. The transaction management system 130 com
`pares the received information with stored information to
`authenticate the customer.
`0034. The authentication process, in some embodiments,
`also involves the comparison of one or more attributes of the
`mobile device 102 with a stored set of attributes collected
`from the mobile device 102 during a registration process
`(such as the process of FIG. 3). For example, the attributes
`may include identifiers associated with the mobile device 102
`which uniquely identify the device. In this way, the customer
`is authenticated two ways—with something they know (login
`credentials), and something they have (mobile device). Once
`the customer is successfully authenticated, then the system
`has access to a variety of attributes about the customer,
`including a list of payment accounts that the customer previ
`ously identified to the transaction management system 130 as
`part of the registration process.
`0035. After a successful authentication process, the cus
`tomer is prompted to Scan, capture (or otherwise enter) a
`checkout token from a device associated with the merchant
`108 (shown as interaction 112 between the mobile device 102
`and the merchant 108). The checkout token is used, as will be
`described further herein, to link messages from the mobile
`device 102 and the merchant 108, and the transaction man
`agement system 130, so that transactions pursuant to the
`present invention may be accomplished. After capture of the
`checkout token, the mobile device 102 transmits the token to
`the transaction management system 130 in a customer trans
`action lookup request message (over communication path
`114). The customer transaction lookup request message
`includes the checkout token captured by the mobile device
`102.
`0036 Pursuant to some embodiments, either a “static'
`checkout token or a "dynamic checkout token may be used.
`In an embodiment where a “static' checkout token is used
`(e.g., Such as one that is assigned for use by a specific check
`out location and which does not include any variable infor
`mation for each transaction), the transaction management
`system 130 matches the information in the customer transac
`tion lookup request (received from the mobile device 102)
`with the information in the merchant payment authorization
`request (received from the merchant 108) by matching the
`checkout token information received in each of the messages.
`Once a match is found, the transaction management system
`130 transmits a transaction detail message (via path 114) to
`the customer's mobile device 102. The information from the
`transaction detail message provides the customer with details
`about the transaction, including but not limited to the amount
`due, the name and location of the merchant (information
`contained in or derived from the merchant payment authori
`Zation request), and possibly one or more marketing mes
`
`IPR2022-01239
`Apple EX1004 Page 19
`
`

`

`US 2011/025 1892 A1
`
`Oct. 13, 2011
`
`sages. In addition, the transaction management system may
`also send to the phonealist of payment accounts the customer
`has registered with the system, including credit, debit, check
`ing, prepaid and other types of accounts. The list of accounts
`may include all of the accounts the customer registered with
`the system, or it may include a Subset of accounts, based on
`rules established by the mobile payment network operator,
`the merchant, the issuer of each payment account, the cus
`tomer, or another entity (e.g., the list of accounts sent to the
`mobile device may only include those accounts that may be
`used for the current transaction). Now the customer can see on
`the display 136 of their mobile device 102 the name of the
`merchant they are about to pay, the amount to be paid, and a
`list of their payment accounts they can use to pay the mer
`chant 108.
`0037. In some embodiments, the merchant's checkout
`token may be derived from a unique identifier in the merchant
`payment authorization request. For example, in cases where
`the merchant can’t easily modify their system to pass the
`transaction management system 130 a static checkout token,
`Such a derivation may reduce or even eliminate the need for
`equipment upgrades and software changes that might other
`wise be required by a merchant adopting a new payment
`method. The checkout token may be derived using a mapping
`table which maps a merchant identifier, a terminal identifier,
`or other information (passed by the merchant system to the
`transaction management system 130) to a checkout token.
`Based on the received identifier, a mapping process may
`occur to identify the appropriate checkout token for use in that
`payment transaction. The selected checkout token is associ
`ated with the transaction in the merchant transaction queue
`where it is made available to be matched with transactions
`from the customer message queue. Those skilled in the art
`will recognize that other matching and mapping techniques
`may also be used. In either event, the checkout token is an
`identifier (consisting of a combination of letters, numbers,
`and/or symbols) used to link a me