US008380177B2
`
`(12) United States Patent
`Laracey
`
`(10) Patent No.:
`(45) Date of Patent:
`
`US 8,380,177 B2
`Feb. 19, 2013
`
`(54)
`
`(75)
`(73)
`(*)
`
`(21)
`(22)
`(65)
`
`(60)
`
`(51)
`
`(52)
`(58)
`
`MOBILE PHONE PAYMENT PROCESSING
`METHODS AND SYSTEMS
`
`Inventor: Kevin Laracey, Natick, MA (US)
`Assignee: Paydiant, Inc., Natick, MA (US)
`Notice:
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 307 days.
`Appl. No.: 12/846,911
`
`Filed:
`
`Jul. 30, 2010
`
`Prior Publication Data
`US 2011 FO251892 A1
`Oct. 13, 2011
`
`Related U.S. Application Data
`Provisional application No. 61/322,477, filed on Apr.
`9, 2010, provisional application No. 61/362,567, filed
`on Jul. 8, 2010.
`
`Int. C.
`(2006.01)
`H04M 3/42
`U.S. Cl. ..................................... 455/4.14.1; 370/259
`Field of Classification Search ............... 455/414.1;
`370/338
`See application file for complete search history.
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`7.379,921 B1* 5/2008 Kiliccote ........................ 705/75
`7,483,858 B2
`1/2009 Foran et al.
`2006/0206709 A1
`9, 2006 Labrou et al.
`2008/O133351 A1* 6/2008 White et al. .................... TO5/14
`2009/0254479 A1 * 10, 2009 Pharris ............................ 705/42
`
`FOREIGN PATENT DOCUMENTS
`102O100018744 A1
`2, 2010
`
`KR
`
`OTHER PUBLICATIONS
`“Notification of Transmittal of the International Search Report and
`the Written Opinion of the International Searching Authority, dated
`Dec. 7, 2011, for PCT Application No. PCT/US2011/031696, 11pgs.
`
`* cited by examiner
`Primary Examiner — Marcos Batista
`(74) Attorney, Agent, or Firm — Buckley, Maschoff &
`Talwalkar LLC
`
`ABSTRACT
`(57)
`Embodiments provide systems, methods, processes, and
`computer program code for using mobile devices to conduct
`payment transactions at merchant locations including brick
`and mortar locations and remote locations as well as for
`person to person transactions.
`64 Claims, 15 Drawing Sheets
`
`2O
`
`- -,
`
`-20s H
`MERCHANT
`
`to -----------
`
`202
`
`20
`
`
`
`232
`
`TRANSACTION
`MANAGEMENT
`SYSTEM
`
`PAYMENT
`PROCESSING
`
`LOCATOR
`SERVICES
`
`Ex.1008
`APPLE INC. / Page 1 of 39
`
`

`

`U.S. Patent
`
`Feb. 19, 2013
`
`Sheet 1 of 15
`
`US 8,380,177 B2
`
`-
`
`108
`
`
`
`MERCHANT
`
`- C
`
`MANAGEMENT
`SYSTEM
`
`r
`
`102
`
`- ?t
`138
`
`FIG. 1
`
`Ex.1008
`APPLE INC. / Page 2 of 39
`
`

`

`U.S. Patent
`
`Feb. 19, 2013
`
`Sheet 2 of 15
`
`US 8,380,177 B2
`
`
`
`
`
`Ex.1008
`APPLE INC. / Page 3 of 39
`
`

`

`U.S. Patent
`
`Feb. 19, 2013
`
`Sheet 3 of 15
`
`US 8,380,177 B2
`
`302
`
`304
`
`306
`
`308
`
`310
`
`500 \
`
`
`
`ACCESS REGISTRATION
`SERVER
`
`ESTABLISH ACCOUNT
`
`DENTIFY PAYMENT
`ACCOUNT(S)
`
`IDENTIFY RULES) AND
`PREFERENCES)
`
`DOWNLOAD AND INSTALL
`APPLICATION
`
`FIG. J.
`
`Ex.1008
`APPLE INC. / Page 4 of 39
`
`

`

`U.S. Patent
`
`Feb. 19, 2013
`
`Sheet 4 of 15
`
`US 8,380,177 B2
`
`400 \
`
`402
`
`TOTAL PURCHASE TRANSACTION AT POINT OF SALE
`
`
`
`404
`
`406
`
`
`
`
`
`MOBILE PAYMENT
`OPTION SELECTED?
`
`
`
`NO
`
`CONTINUE STANDARD
`PAYMENT PROCESSING
`
`YES
`
`408
`TRANSMIT MERCHANT PAYMENT AUTHORIZATION REQUEST,
`INCLUDING MERCHANT CHECKOUT TOKEN, AMOUNT AND
`TRANSACTION DATA TO TRANSACTION MANAGEMENTSYSTEM
`
`410
`
`412
`
`44
`
`DISPLAY CHECKOUT TOKEN TO CUSTOWER
`
`RECEIVE PAYMEN AUTHORIZATION FROM
`TRANSACTION MANAGEMENT SYSTEM
`
`CENERATE TRANSACTION RECEPT TO
`COMPLETE TRANSACTION
`
`FIG. 4A
`
`Ex.1008
`APPLE INC. / Page 5 of 39
`
`

`

`U.S. Patent
`
`Feb. 19, 2013
`
`Sheet 5 Of 15
`
`US 8,380,177 B2
`
`420 \
`
`LAUNCHMOBILE PAYMENT APPLICATION
`
`422
`
`424
`
`PROMPT CUSOMER TO ENTER AUTHENTCATION INFORMATION
`
`426
`
`428
`
`NO
`
`PRESENT ALTERNATIVE
`PAYMENT
`
`YES
`
`450
`
`CAPTURE CHECKOUT TOKEN
`
`2
`43
`TRANSMIT CUSOMER TRANSACTION LOOKUP REQUEST AND
`CHECKOUT TOKEN TO TRANSACTION MANAGEMENT SYSTEM
`
`
`
`45 4
`
`RECEIVE TRANSACTION DETALS AND PAYMENT ACCOUNT
`INFORMATION FROM TRANSACTION MANAGEMENT SYSTEM
`43
`6
`
`PRESENT TRANSACTION DETALS AND ENHANCED
`PAYMENT ACCOUNT CHOICES TO CUSTOMER
`
`RECEIVE PAYMENT ACCOUNT SELECTION AND REQUEST
`CONFIRMATION OF SELECTION, PAYMENT AMOUNT
`& MERCHAN
`
`
`
`43 8
`
`44
`O
`
`TRANSMIT CUSOMER PAYMENT AUTHORIZATION REQUEST
`TO TRANSACTION MANACEMENT SYSTEM FOR PROCESSING
`44
`2
`
`RECEIVE TRANSACTION COMPLETE MESSAGE
`FIG. 4B
`
`Ex.1008
`APPLE INC. / Page 6 of 39
`
`

`

`U.S. Patent
`
`Feb. 19, 2013
`
`Sheet 6 of 15
`
`US 8,380,177 B2
`
`452
`RECEIVE MERCHANT PAYMENT AUTHORIZATION REQUEST,
`TRANSACTION DATA AND ASSIGN CHECKOUT TOKEN
`
`-450
`
`INSERT MERCHANT PAYMENT AUTHORIZATION REQUEST
`INTO MERCHANT TRANSACTION QUEUE
`
`RECEIVE CUSTOMER AUTHENTCATION REQUEST
`
`454.
`
`45 6
`
`458
`
`NO
`
`<od
`
`YES
`
`460
`
`TRANSMIT
`AUTHENTCATION DENIAL
`TO MOBILE DEVICE
`
`462
`
`TRANSMIT AUTHENTICATION RESPONSE TO MOBILE DEVICE
`464
`
`RECEIVE CUSTONER TRANSACTION LOOKUP REQUEST
`MESSAGE INCLUDING CUSTOMER CHECKOUT TOKEN
`
`MATCH CUSTONER CHECKOUT TOKEN MTH MERCHANT
`CHECKOUT TOKEN AND RETRIEVE PAYMENT OETALS
`
`466
`
`468
`
`RETRIEVE CUSTOMER PAYMENT ACCOUNT INFORMATION AND
`TRANSMT WITH TRANSACTION DETALS TO MOBILE DEVICE
`470
`
`RECEIVE CUSTOMER PAYMENT AUTHORIZATION REQUEST
`INCLUDING CUSTOMER PAYMENT ACCOUNT SEECTION
`
`472
`
`RETRIEVE ACTUAL PAYMENT PAYMENT CREDENTIALS BASED
`ON RECEIVED CUSTOMER PAYMENT ACCOUNT SELECTION
`474
`OBAN PAYMENT AUTHORIZATION FROM PAYMENT NETWORK
`USING ACTUAL PAYMENT CREDENTALS
`
`476
`
`TRANSMIT PAYMENT AUTHORIZATION TO MERCHANT AND
`CONFIRMATION TO MOBILE DEVICE
`
`FIG. 4C
`
`Ex.1008
`APPLE INC. / Page 7 of 39
`
`

`

`U.S. Patent
`
`Feb. 19, 2013
`
`Sheet 7 of 15
`
`US 8,380,177 B2
`
`
`
`
`
`4 50
`
`PAYMEN ACCOUNT
`THIRD PARTY SERVICE
`INTEGRATION
`
`GATEWAY
`INTEGRATION
`
`CUSTOMER
`MANAGEMENT
`SYSTEM
`
`PAYMENT ACCOUNT
`MANAGEMENT
`SYSTEM
`
`MERCHANT
`MANAGEMENT
`
`TRANSACTION
`MANAGEMENT
`
`MOBILE GATEWAY
`
`/ 500
`
`PHONE
`WOBILE APPLICATION
`
`NERCHANT POS
`INTEGRATION
`SYSTEM
`
`SECURITY
`MANAGEMENT
`SYSTEM
`
`ECOMMERCE
`PLAIFORM
`INTEGRATION
`
`ANDROID
`MOBILE APPLICATION
`
`AUDING
`
`536
`
`554
`
`528
`
`REPORTS
`
`ADMIN PORTAL
`
`CSR SYSTEM
`
`FIG. 5
`
`Ex.1008
`APPLE INC. / Page 8 of 39
`
`

`

`U.S. Patent
`
`Feb. 19, 2013
`
`Sheet 8 of 15
`
`US 8,380,177 B2
`
`
`
`604
`
`GATEWAY
`CONNECTOR
`
`(24)
`
`a
`
`- one- m - arrm -
`
`CUSTOWER
`MANAGEMEN
`SYSTEM
`
`SECURITY
`MANAGEMENT
`
`MERCHANT
`DS
`ADSERS WENT
`SYSTEM
`
`8 63
`
`MOBILE GATEWAY
`
`POS GATEWAY
`
`(o)
`
`(b)
`
`TRANSACTION
`MANAGEMENTSYSTEM
`('sign
`640, GEWAY
`) \ity
`( 2 7
`
`Q Q
`SHOPPING
`CART
`
`Ex.1008
`APPLE INC. / Page 9 of 39
`
`

`

`U.S. Patent
`
`Feb. 19, 2013
`
`Sheet 9 Of 15
`
`US 8,380,177 B2
`
`:
`
`
`
`
`
`
`
`Ex.1008
`APPLE INC. / Page 10 of 39
`
`

`

`U.S. Patent
`
`Feb. 19, 2013
`
`Sheet 10 of 15
`
`US 8,380,177 B2
`
`
`
`Scan Payment Code
`Manually enter code
`
`Anolyzing payment code :
`
`CLIP
`
`ACCOUNTS
`
`MORE
`
`FIG. 3A
`
`Ex.1008
`APPLE INC. / Page 11 of 39
`
`

`

`U.S. Patent
`
`Feb. 19, 2013
`
`Sheet 11 of 15
`
`US 8,380,177 B2
`
`
`
`PetPOce
`
`Hello Richard Petxtra Occount 2480789
`Regular price $39.09, PetExtra price $34.00
`You saved $5,09 today with PetFxtrol
`PetPlace Store
`112
`PetPOCe 1745 W Home Rood
`Phoenix, AZ 85O15
`PetPerks Credit. 685
`
`1 2222 S533 4444
`
`C
`WOOD 8.
`Additional 5% off if used today
`
`O)
`s in
`
`PetPerks Debit.8888
`PetPlace
`Available: 428.50 CD
`
`O) E: Gift. 358
`EIOCe
`Available: $100.00
`
`836
`
`842
`
`8440
`
`844b
`
`844
`
`FIG. 8B
`
`Ex.1008
`APPLE INC. / Page 12 of 39
`
`

`

`U.S. Patent
`
`Feb. 19, 2013
`
`Sheet 12 of 15
`
`US 8,380,177 B2
`
`
`
`Merchant
`
`Dote
`
`PetPloce
`
`Mar 29, 2010 03:49 PM
`
`Payment Method
`
`Petxtro Credit
`
`Location
`
`Toto
`
`Ex.1008
`APPLE INC. / Page 13 of 39
`
`

`

`U.S. Patent
`
`Feb. 19, 2013
`
`Sheet 13 of 15
`
`US 8,380,177 B2
`
`
`
`PetPOce
`
`836
`
`SuperDog
`on (6) Cons of SuperDog
`dogfood, Ony VOriety
`
`Merchant
`
`Oo te
`
`PetPOce
`
`Mgr 29, 2010 (5:49 PM
`
`FIG. 3D
`
`Ex.1008
`APPLE INC. / Page 14 of 39
`
`

`

`U.S. Patent
`
`Feb. 19, 2013
`
`Sheet 14 of 15
`
`US 8,380,177 B2
`
`
`
`802
`
`/ 800
`
`Thank you for purchasing at
`PetPOCe
`
`836
`
`858
`
`FIG. BE
`
`Ex.1008
`APPLE INC. / Page 15 of 39
`
`

`

`U.S. Patent
`
`Feb. 19, 2013
`
`Sheet 15 of 15
`
`US 8,380,177 B2
`
`oll
`
`HHH
`
`HHH
`
`1/90
`
`(S)IONSWAINddlJ0IA30AYNRES
`TATEINNOOOY(SIINNOI0¥
`
`
`Q00'f=WENIN|=:¥O¥“ONIIOIHO
`‘2=MIMORd}|NVNGISEGM
`
`
`N¥d‘CMYp=AMO]——_LIG3¥O3S¥HO
`VAY“ONDNO3H)Z=ALWOWdVALID
`
`N¥d‘Guvd1=AMOI)WIASIVGALINA
`HHANidL=ALIMOId‘NN1dSUIS
`
`L=AldOlddN¥d_XIN¥
`
`‘HAHANYd|=ALOR|‘LaSYONENVIS
`
`ALIMOId|SHNYESGLSESM
`
`WANIN]N¥d“L930¥SIA
`
`Z1/S0‘HEAR
`‘Lo0yBAH
`
`SISNAdXJSSINISNG|Uvayds‘2
`
`
`
`SOMYMAYNYG‘L|Zzzziaid|—SaNOrAWS}—ZO0OLN
`69
`
`
`LiaayaFonda“t}—‘Seeziaia}300aNyr
`S74PNGZggas|"jpysn|—-S¢¢z0z)
`
`
`
`21/60‘HEE
`
`01/90
`
`Loy‘HEH
`
`Hitt
`
`Ex.1008
`APPLEINC./ Page 16 of 39
`
`Ex.1008
`APPLE INC. / Page 16 of 39
`
`

`

`1.
`MOBILE PHONE PAYMENT PROCESSING
`METHODS AND SYSTEMS
`
`US 8,380,177 B2
`
`CROSS REFERENCE TO RELATED
`APPLICATIONS
`
`The present application is based on, and claims benefit 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.
`
`10
`
`BACKGROUND
`
`15
`
`25
`
`30
`
`35
`
`Credit cards, debit cards and other payment cards have
`been in use for years. The manner in which these payment
`cards are used is substantially unchanged since their intro
`duction—a cardholder presents their payment card to a mer
`chant, who uses a magnetic stripe reader to read the cardhold
`er's payment account information, and then the merchant
`transmits the payment account information along with trans
`action details to a payment network for authorization, clear
`ing and settlement. While this approach has worked well,
`there are a number of disadvantages associated with it.
`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 cardholder
`data and used it for fraudulent transactions. If merchants 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 card
`holder information is a significant cost to merchants. It would
`be desirable to provide systems and methods in which pay
`ment card information is not stored, captured, or transmitted
`by merchants.
`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.).
`Another disadvantage of existing payment systems is that
`current payment cards are unable to easily be used in con
`junction with mobile devices Such as Smart phones. 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
`55
`desirable to provide an ability to conduct purchase transac
`tions (both online and at brick and mortar stores) using a
`mobile device.
`These, and other, problems are solved by using systems
`and methods of the present invention. Other advantages and
`features will become apparent upon reading the following
`disclosure.
`
`40
`
`45
`
`50
`
`60
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`FIG. 1 is a block diagram depicting a payment system
`configured pursuant to some embodiments.
`
`65
`
`2
`FIG. 2 is a block diagram depicting further details of a
`payment system configured pursuant to Some embodiments.
`FIG. 3 is a flow diagram depicting a customer registration
`process pursuant to some embodiments.
`FIGS. 4A-4C are flow diagrams depicting a transaction
`process pursuant to some embodiments.
`FIG. 5 is a block diagram depicting system components of
`a system pursuant to Some embodiments.
`FIG. 6 is a block diagram depicting a transaction flow
`pursuant to Some embodiments.
`FIG. 7 is a block diagram depicting components of a
`mobile device pursuant to some embodiments.
`FIGS. 8A-8E are sample user interfaces associated with
`embodiments of the present invention.
`FIG.9 is a table depicting a portion of a customer database
`pursuant to Some embodiments.
`
`DESCRIPTION
`
`Embodiments of the present invention relate to systems,
`methods, processes, computer program code, and means for
`using mobile devices to conduct payment transactions at mer
`chant locations including brick and mortar locations and
`remote (e.g., such as Internet or mail order and telephone)
`locations, as well as for person to person transactions. 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 features 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 Incorpo
`rated, private label processing networks, electronic funds
`transfer networks, Automated Clearing House networks, or
`the like). In some embodiments, mobile devices configured
`using features of the present invention are capable of deter
`mining 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 infor
`mation or the like). In this manner, users are provided with
`greater payment options and better information about which
`payment account to use in any given transaction.
`Pursuant to some embodiments, transaction methods, sys
`tems, apparatus, means and computer program code are pro
`vided for conducting payment transactions which include
`selecting a mobile payment option at a point of sale, obtain
`ing, using a mobile device, a checkout token printed or oth
`erwise 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
`capturing a barcode image, key entering the checkout token,
`by wireless communication or otherwise receiving the check
`out token at a mobile device.
`Embodiments of the present invention are believed to pro
`vide desirable advantages from a fraud reduction standpoint,
`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 pro
`vided to a merchant, and (ii) the customer's payment creden
`tials can never be accessed for use in a payment transaction
`unless the access request is coming from one of the authorized
`
`Ex.1008
`APPLE INC. / Page 17 of 39
`
`

`

`3
`devices that has been designated by the customer as having
`access to the customer's payment credentials.
`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 facilitate transac
`tions 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 oper
`ated to receive a checkout token (or data associated with a
`checkout token) via key entry, via image capture, via RFID
`reading, and using other scanning, reading, or other tech
`niques described herein. Pursuant to Some embodiments, the
`term "capture' further includes any decoding or image pro
`cessing of a checkout token required to retrieve or otherwise
`obtain information from the checkout token.
`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
`
`Embodiments of the present invention allow customers to
`make purchases at merchant locations using their mobile
`devices. In the following, a number of processes and transac
`tion 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 describ
`ing certain features of the present invention. The examples are
`not intended to be limiting and are merely provided for illus
`tration.
`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 Starbucks.(R) 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.
`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.
`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.
`Using features of the present invention, customers such as
`Jane and Sam may use their mobile devices to pay for prod
`
`US 8,380,177 B2
`
`4
`ucts or services at point of sale (or “POS) locations. Mer
`chants need not modify their point of sale hardware (although
`Some embodiments involve the merchant displaying a check
`out token on a point of sale display terminal) and users may
`pay using their existing payment accounts. Embodiments
`allow users to choose among a variety of payment accounts to
`use the most appropriate or most desirable payment account
`for a given transaction. Embodiments also allow merchants,
`payment account issuers, and/or payment network operators
`to establish rules governing which payment instruments are
`made available for use on the phone. These illustrative
`examples will be used in conjunction with some of the fol
`lowing 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.
`System Overview
`Features of some embodiments of the present invention
`will now be described by reference to FIG.1, which is a block
`diagram of a system 100 pursuant to Some embodiments. 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 store
`front, electronic commerce merchant, or mail order and tele
`phone (“MOTO') merchant (or another person or entity).
`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 mer
`chant (acting through a clerk, a display screen, a POS terminal
`facing the customer, or the like) then prompts the customerto
`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 mer
`chant (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 payment option. If the
`customer selects the mobile payment option, features of the
`present invention are utilized to process the transaction.
`In some embodiments, rather than requiring the customer
`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 cus
`tomer'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.
`If the mobile payment option is selected, and once the
`purchase total has been generated, the merchant 108transmits
`a merchant payment authorization request message to a trans
`action management system 130 (via path 116). The merchant
`payment authorization request message may include one or
`more pieces of data or information about the transaction. For
`example, the message may include one or more of a merchant
`
`10
`
`15
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`Ex.1008
`APPLE INC. / Page 18 of 39
`
`

`

`5
`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.
`A number of techniques may be used to generate or present
`the checkout token. For example, in Some embodiments, one
`or more checkout tokens may be predefined or established for
`use with a given merchant 108 (e.g., the merchant 108 could
`have a number of checkout tokens available to display or
`present at the point of sale). In such embodiments, the mer
`chant 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 standardized 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 transaction). In Such an
`embodiment, the POS system would pass a selected checkout
`token to the transaction management system 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.
`Pursuant to some embodiments, the checkout token is
`dynamically generated for each transaction. In some embodi
`ments, the checkout token is a static identifier associated 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 merchant 108 causes the
`checkout token to be displayed or presented to the customer.
`For example, the checkout token may be displayed on a
`display device associated with the merchant, or pre-printed
`on a placard or other display near the point of sale.
`From the customer perspective, the payment process 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 invention. 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 embodi
`ments, the authentication process serves to authenticate the
`customer to the transaction management system 130. The
`authentication process may involve the customer launching 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 authentication
`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 compares the
`received information with stored information to authenticate
`the customer.
`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
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`US 8,380,177 B2
`
`10
`
`15
`
`6
`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.
`After a Successful authentication process, the customer 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.
`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 checkout
`location and which does not include any variable information
`for each transaction), the transaction management system
`130 matches the information in the customer transaction
`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
`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.
`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 mer
`chant can’t easily modify their system to pass the transaction
`management system 130 a static checkout token, such a deri
`Vation may reduce or even eliminate the need for equipment
`upgrades and Software changes that might otherwise 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 transac
`
`Ex.1008
`APPLE INC. / Page 19 of 39
`
`

`

`7
`tion management system 130) to a checkout token. Based on
`the received identifier, a mapping process may occur to iden
`tify the appropriate checkout token for use in that payment
`transaction. The selected checkout token is associated 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 recog
`nize that other matching and mapping techniques may also be
`used. In either event, the checkout token is an identifier (con
`sisting of a combination of letters, numbers, and/or symbols)
`used to link a merchant payment authorization request to a
`payment authorization request received from a customer
`operating a mobile device pursuant to the present invention.
`In embodiments using a "dynamic checkout token (e.g.,
`where the checkout token is generated by either the merchant
`108 or the transaction management system 130 before it is
`displayed on a display device associated with the merchant
`during a checkout transaction, and where the checkout token
`may include additional information about a transaction),
`checkout processing may proceed without a need for a cus
`tomer transaction lookup request message to be transmitted to
`the transaction management system 130. For example, in
`Some embodiments. Some or all of the transaction details may
`be encoded in a dynamic checkout token which,