US20150254662A1 - Verifying transaction context data at wallet service provider - Google Patents
Verifying transaction context data at wallet service providerDownload PDFInfo
- Publication number
- US20150254662A1 US20150254662A1US14/469,380US201414469380AUS2015254662A1US 20150254662 A1US20150254662 A1US 20150254662A1US 201414469380 AUS201414469380 AUS 201414469380AUS 2015254662 A1US2015254662 A1US 2015254662A1
- Authority
- US
- United States
- Prior art keywords
- payment
- transaction
- data
- mobile device
- computer
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
- G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
- G06Q20/3674—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/20—Point-of-sale [POS] network systems
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/20—Point-of-sale [POS] network systems
- G06Q20/202—Interconnection or interaction of plural electronic cash registers [ECR] or to host computer, e.g. network details, transfer of information from host to ECR or from ECR to ECR
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/22—Payment schemes or models
- G06Q20/227—Payment schemes or models characterised in that multiple accounts are available, e.g. to the payer
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/322—Aspects of commerce using mobile devices [M-devices]
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
- G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
- G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
- G06Q20/3672—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes initialising or reloading thereof
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/327—Short range or proximity payments by means of M-devices
- G06Q20/3278—RFID or NFC payments by means of M-devices
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
Definitions
- Payment cardssuch as credit cards and debit cards are in widespread use. In some environments, payment cards in the form of magnetic stripe cards prevail in terms of popularity. With mag stripe cards, the payment card account number may be read from the card at the point of sale by a magnetic stripe reader, and then submitted with a transaction authorization request to the account issuer via the payment network.
- contactless payment cardsWith contactless payment cards, the payment card account number is stored in an integrated circuit (IC) within the card, and is read by short-range radio communication between the card and the contactless reader component of a point of sale (POS) terminal.
- ICintegrated circuit
- POSpoint of sale
- NFCnear field communication
- mobile devicesutilize a secure element (SE) to store the payment card account number and associated data, keys and Personal Identification Number (PIN) to enable the consumer to perform a payment transaction using the NFC short-range radio communications provided by the mobile device and the contactless reader component of a POS terminal.
- SEsecure element
- PINPersonal Identification Number
- so-called “contact” payment IC cardsare placed in point of sale readers that can read the payment card account number from the card IC via direct conductive contacts provided on the face of the card.
- FIG. 1is a block diagram that illustrates a conventional payment system.
- FIG. 2is a block diagram that illustrates a payment system provided in accordance with aspects of the present invention.
- FIG. 3is a block diagram that illustrates a payment-enabled mobile telephone provided in accordance with aspects of the present invention and that may be used in connection with the system of FIG. 2 .
- FIG. 4is a block diagram that illustrates a point of sale (POS) terminal provided in accordance with aspects of the present invention and that may be part of the system of FIG. 2 .
- POSpoint of sale
- FIG. 5is a block diagram that illustrates a computer system that may be operated by a wallet service provider as part of the system of FIG. 2 and in accordance with aspects of the present invention.
- FIG. 6schematically represents enrollment of a payment card account with a wallet service provider that participates in the system of FIG. 2 .
- FIG. 7schematically illustrates software and functional aspects of the payment-enabled mobile telephone of FIG. 3 .
- FIG. 8illustrates additional details of software aspects of the payment-enabled mobile telephone of FIG. 3 .
- FIG. 9illustrates still further details of software aspects of the payment-enabled mobile telephone of FIG. 3 .
- FIG. 10schematically illustrates software aspects of the POS terminal of FIG. 4 .
- FIGS. 11A and 11Btogether form a flow chart that illustrates a transaction process that may be performed in the system of FIG. 2 in accordance with aspects of the present invention.
- FIG. 12schematically illustrates a clearing process that may be performed in the system of FIG. 2 in accordance with aspects of the present invention.
- FIG. 13is a block diagram that illustrates an alternative embodiment of the payment system of FIG. 2 .
- FIG. 14is a high level flow chart that illustrates a transaction process that may be performed in the system of FIG. 13 in accordance with aspects of the present invention.
- FIG. 15schematically illustrates some details of the process of FIG. 14 .
- FIG. 16schematically illustrates a biometric-based cardholder verification method (CVM) that may be performed according to aspects of the invention in the system of FIG. 2 or FIG. 13 .
- CVMbiometric-based cardholder verification method
- FIG. 17is a block diagram that illustrates aspects of the biometric-based CVM of FIG. 16 .
- FIG. 18is a block diagram that illustrates an alternative CVM that may be performed according to aspects of the invention.
- a payment network transactionis consummated at the point of sale without the POS terminal receiving or reading a payment card account number.
- the consumeroffers a payment-enabled mobile device as a credential for the transaction.
- the payment card account numberneed not be stored in the mobile device, but rather has been enrolled in a digital wallet maintained for the consumer by a wallet service provider (WSP) that is located remotely from the point of sale.
- WSPwallet service provider
- the POS terminal and the payment-enabled mobile deviceexchange data to initiate the payment transaction.
- the data provided from the payment-enabled mobile device to the POS terminalmay include only (a) data to identify the consumer's WSP, and (b) an internet address for a server function that is hosted by the payment-enabled mobile device.
- the data provided from the POS terminal to the payment-enabled mobile devicemay relate to the current purchase transaction (e.g., transaction amount) and to the transaction context (e.g., data to identify the merchant that operates the POS terminal and the location of the purchase transaction).
- the exchange of data between the POS terminal and the payment-enabled mobile devicemay be by any convenient mode, such as NFC.
- the POS terminalmay route a message to the WSP, where the message contains the transaction data, the transaction context data and the internet address for the mobile device server function.
- the WSPmay then use the internet address to set up a cryptographically secured communication channel with the mobile device via the server function hosted by the mobile device. This may involve mutual authentication of the WSP's computer and the mobile device server function.
- the WSP's computermay transmit wallet form data to the mobile device via the secure channel to permit the consumer to select a payment card account from among those for which data is stored in the digital wallet maintained for the consumer by the WSP.
- the mobile device server functionmay send data to the WSP's computer to serve as an authentication token for the transaction, including data that indicates the consumer's selection of a payment card account to be used for the transaction, and data by which the WSP can confirm the validity of the transaction data and transaction context data provided to the WSP from the POS terminal.
- the WSPmay then act much like an acquirer in a conventional payment card system, by routing an authorization request for the transaction via the payment network to the issuer of the selected payment card account. Upon receiving a favorable authorization response, the WSP may route a confirmation to the POS terminal to indicate that a valid payment for the purchase transaction has been secured. The purchase transaction is then complete at the point of sale.
- FIG. 1is a block diagram that illustrates a conventional payment system 100 .
- the system 100includes a conventional payment card/device 102 (which may alternatively be a conventional payment-enabled mobile device that stores a payment card account number and runs a payment applet; other form factors for the payment device, such as a fob, are also possible).
- the system 100further includes a reader component 104 associated with a POS terminal 106 .
- the reader component 104is capable of reading the payment card account number and other information from the payment card/device 102 .
- the reader component 104 and the POS terminal 106may be located at the premises of a retail store and operated by a sales associate of the retailer for the purpose of processing retail transactions.
- the payment card/device 102is shown in FIG. 1 to be interacting with the proximity reader component 104 and the POS terminal 106 for the purpose of executing such a transaction.
- a computer 108 operated by an acquireris also shown as part of the system 100 in FIG. 1 .
- the acquirer computer 108may operate in a conventional manner to receive an authorization request for the transaction from the POS terminal 106 .
- the acquirer computer 108may route the authorization request via a payment network 110 to the server computer 112 operated by the issuer of a payment card account that is associated with the payment card/device 102 .
- the authorization response generated by the payment card issuer server computer 112may be routed back to the POS terminal 106 via the payment network 110 and the acquirer computer 108 .
- the payment card issuer server computer 112may be operated by or on behalf of a financial institution (“FI”) that issues payment card accounts to individual users. For example, the payment card issuer server computer 112 may perform such functions as (a) receiving and responding to requests for authorization of payment card account transactions to be charged to payment card accounts issued by the FI; and (b) tracking and storing transactions and maintaining account records.
- FIfinancial institution
- a typical payment systemmay process many purchase transactions (including simultaneous transactions) and may include a considerable number of payment card issuers and their computers, a considerable number of acquirers and their computers, and numerous merchants and their POS terminals and associated proximity reader components.
- the systemmay also include a very large number of payment card account holders, who carry payment cards or other devices for initiating payment transactions by presenting an associated payment card account number to the reader component of a POS terminal
- FIG. 2is a block diagram that illustrates a payment system 200 provided in accordance with aspects of the present invention. (As was the case in FIG. 1 , the payment system is depicted in FIG. 2 only in terms of components needed for a single transaction; in practice, and as will be discussed below, the payment system 200 may include many more instances of at least some components.)
- the payment system 200includes a payment-enabled mobile device 202 provided in accordance with aspects of the present invention.
- the payment-enabled mobile device 202may take the form of a conventional-appearing smartphone, tablet computer, or the like.
- the software configuration of the payment-enabled mobile device 202may be very different from previously proposed payment-enabled devices.
- the payment-enabled mobile device 202may not store any payment card account information, and may lack the payment applets that have heretofore typically been proposed to incorporate contactless payment capabilities into a mobile phone. Further details of the payment-enabled mobile device 202 will be described below, particularly in the ensuing sections of this description relating to FIGS. 3 , 7 , 8 and 9 , and in portions of FIGS. 11A and 11B .
- a merchant point-of-interaction (POI) terminal 204which may be a POS terminal as configured in accordance with aspects of the present invention.
- the merchant POI terminal 204may, for example, be operated by a merchant (or merchant employee) at a retail store, and may interact with the payment-enabled mobile device 202 in a manner described below (e.g., by a short-range mode of data communication). Further details of the merchant POI terminal 204 will be described subsequently, including in the sections of the description relating to FIGS. 4 and 10 .
- Another feature of the payment system 200is a computer 206 operated by a payment system acquirer (or a payment services provider—“PSP”) on behalf of an acquirer.
- the acquirermay be a financial institution with which the merchant maintains a banking relationship.
- the roles of the PSP/acquirer computer 206 in the payment systemmay be quite different from the roles typically performed by the acquirer in a conventional payment system such as that illustrated in FIG. 1 .
- a portion of the ensuing discussionwill describe actions taken by the PSP/acquirer, and the computer 206 , in connection with a typical payment transaction as performed in the payment system 200 .
- a central aspect and component of the payment system 200is a computer 208 operated by or on behalf of a wallet service provider (WSP). It is assumed that the WSP in question maintains a digital wallet for an individual user depicted at 210 as the user of the payment-enabled mobile device 202 .
- WSPwallet service provider
- FIG. 2Two main functional blocks of the WSP computer 208 are shown in FIG. 2 , namely a wallet services block 212 and a transaction concentrator block 214 .
- the wallet services block 212enrolls consumers for digital wallet services, and allows consumers' payment card accounts to be represented in digital form in the consumers' digital wallets to be maintained in the wallet services block 212 .
- the wallet services block 212also serves as a repository and as a resource for digital wallet and payment card account information to be used—as will be seen—in payment transactions that are performed in accordance with aspects of the present invention.
- the transaction concentrator block 214handles individual payment transactions in accordance with aspects of the present invention and as described in detail below.
- the payment network 110 and the issuer server computer 112which were mentioned in the above description of FIG. 1 .
- Operation of the payment system 200does not necessarily require that the payment network 110 and the issuer server computer 112 be operated in other than a conventional manner, and thus the payment network 110 and the issuer server computer 112 may be constituted in a known manner; it should be noted though that in effect, and as will be seen, the WSP computer 208 may serve (among other roles) in the place of the acquirer computer 108 that was depicted in FIG. 1 .
- the payment network 110may receive authorization requests from the WSP computer 208 as if (from the point of view of the payment network 110 ) the WSP computer 208 were an acquirer computer.
- FIG. 2also shows communication channels 216 , 218 , 220 and 222 interconnecting certain of the components of the payment system 200 . Further information about these communication channels will be provided below. It should also be noted that communication channel 224 (between the WSP computer 208 and the payment network 110 ) and communication channel 226 (between the payment network 110 and the issuer server computer 112 ) may be provided in a conventional manner.
- the block diagram representation of the payment system 200 as shown in FIG. 2represents only system components required for a single transaction.
- the payment system 200may process many transactions, including simultaneous transactions.
- a considerable number of payment card account issuersmay be included in the payment system 200 , and the payment system 200 may also include a considerable number of acquirers/PSPs and their computers.
- the payment system 200may include a large number of merchant POI devices (in-store and/or e-commerce host computers), operated by a large number of merchants.
- the usersare holders of payment card accounts issued by issuing financial institutions and have enrolled with one or more WSPs, which maintain digital wallets for the users.
- FIG. 3is a block diagram that illustrates an example embodiment of the payment-enabled mobile device 202 shown in FIG. 2 and provided in accordance with aspects of the present invention.
- the payment-enabled mobile device 202may be conventional in its hardware aspects.
- the payment-enabled mobile device 202may be a smartphone, and may resemble, in some or all of its hardware aspects and many of its functions, a conventional “iPhone” marketed by Apple Inc., or one of the numerous smartphone models that run the “Android” operating system.
- the payment-enabled mobile device 202may be a tablet computer, such as the “iPad” marketed by Apple Inc.
- the ensuing description of the payment-enabled mobile device 202is based on the assumption that it is embodied as a smartphone; those who are skilled in the art will readily understand from the following description, and from following descriptions of software aspects of the payment-enabled mobile device 202 , how to embody the payment-enabled mobile device 202 as a tablet computer or other device apart from a smartphone.
- the payment-enabled mobile device 202may include a conventional housing (indicated by dashed line 302 in FIG. 3 ) that contains and/or supports the other components of the payment-enabled mobile device 202 .
- the housing 302may be shaped and sized to be held in a user's hand, and may for example exhibit the type of form factor that is common with the current generation of smartphones.
- the payment-enabled mobile device 202further includes conventional control circuitry 304 , for controlling over-all operation of the payment-enabled mobile device 202 .
- the control circuitry 304may include a conventional processor of the type designed to be the “brains” of a smartphone.
- Other components of the payment-enabled mobile device 202which are in communication with and/or controlled by the control circuitry 304 , include: (a) one or more memory devices 306 (e.g., program and working memory, etc.); (b) a conventional SIM (subscriber identification module) card 308 ; (c) a conventional touchscreen 312 which serves as the primary input/output device for the payment-enabled mobile device 202 , and which thus receives input information from the user and displays output information to the user.
- memory devices 306e.g., program and working memory, etc.
- SIMsubscriber identification module
- a conventional touchscreen 312which serves as the primary input/output device for the payment-enabled mobile device 202 , and which thus receives input information from the user and displays output information to the user.
- the payment-enabled mobile device 202may also include a few physically-actuatable switches/controls (not shown), such as an on/off/reset switch, a menu button, a “back” button, a volume control switch, etc. It may also be the case that the payment-enabled mobile device 202 includes a conventional digital camera (as is the case with many smartphones), which is not shown.
- the payment-enabled mobile device 202also includes conventional receive/transmit circuitry 316 that is also in communication with and/or controlled by the control circuitry 304 .
- the receive/transmit circuitry 316is coupled to an antenna 318 and provides the communication channel(s) by which the payment-enabled mobile device 202 communicates via the mobile telephone communication network (not shown).
- the receive/transmit circuitry 316may operate both to receive and transmit voice signals, in addition to performing data communication functions. As is known to those who are skilled in the art, such data communication may be via HTTP (HyperText Transfer Protocol) or other communication protocol suitable for carrying out data communication over the internet.
- HTTPHyperText Transfer Protocol
- the payment-enabled mobile device 202further includes a conventional microphone 320 , coupled to the receive/transmit circuitry 316 .
- the microphone 320is for receiving voice input from the user.
- a loudspeaker 322is included to provide sound output to the user, and is coupled to the receive/transmit circuitry 316 .
- the receive/transmit circuitry 316may operate in a conventional fashion to transmit, via the antenna 318 , voice signals generated by the microphone 320 , and to reproduce, via the loudspeaker 322 , voice signals received via the antenna 318 .
- the receive/transmit circuitry 316may also handle transmission and reception of text messages and other data communications via the antenna 318 .
- the payment-enabled mobile device 202may also include circuitry 324 that is partly or wholly dedicated to implementing NFC communications functionality of the payment-enabled mobile device 202 .
- the payment-enabled mobile device 202may further include a loop antenna 326 , coupled to the NFC circuitry 324 .
- the NFC circuitry 324may partially overlap with the control circuitry 304 for the payment-enabled mobile device 202 .
- the NFC circuitry 324is associated with, and may also overlap with, a secure element 328 that is part of the payment-enabled mobile device 202 and is contained within the housing 302 , or the NFC circuitry could be omitted in embodiments that do not utilize NFC.
- secure elementis well known to those who are skilled in the art, and typically refers to a device that may include a small processor and volatile and nonvolatile memory (not separately shown) that are secured from tampering and/or reprogramming by suitable measures.
- the secure element 328may be provided as part of the SIM card 308 .
- the secure element 328may be constituted by an integrated circuit card separate from the SIM card 308 but possibly having the same form factor as the SIM card 308 .
- the secure element 328may be conventional in its hardware aspects but may be programmed in accordance with aspects of the present invention in a manner to be described below. (It should be noted that the term “secure element” is not intended to be limited to devices that are IC-based, but rather may also include any secure execution environment in a mobile device, and may include software based secure execution environments running on the main mobile device processor.)
- the payment-enabled mobile device 202may be operable as a conventional mobile telephone for communication—both voice and data—over a conventional mobile telecommunications network, which is not depicted in the drawing.
- the payment-enabled mobile device 202may be in communication from time to time in a conventional manner with a mobile network operator (“MNO”—also not shown).
- MNOmobile network operator
- an over-the air communication channel(of which an example is communication channel 222 in FIG. 2 , as discussed further below) may be established between the payment-enabled mobile device 202 and a remote computer (e.g., the WSP computer 208 ).
- FIG. 4is a block diagram that illustrates the merchant POI terminal 204 shown in FIG. 2 and provided in accordance with aspects of the present invention; as noted above, the merchant POI terminal 204 may be embodied as a POS terminal at a retail store.
- the merchant POI terminal 204may be largely or entirely conventional in its hardware aspects (with the possible exception of cost reductions that may be facilitated by teachings of this disclosure, as described below). Nevertheless, the merchant POI terminal 204 may be programmed in accordance with aspects of the present disclosure to provide functionality as described herein. In addition to the below description of functional process steps performed by the merchant POI terminal 204 as part of a typical purchase transaction (e.g., in connection with FIGS. 11 A and 11 B—see below), there will also be discussion below of some software aspects of the merchant POI terminal 204 in connection with FIG. 10 . For now, however, a brief description of hardware aspects of the merchant POI terminal 204 will follow, with continued reference to FIG. 4 .
- the merchant POI terminal 204may include a processing element (or elements) such as the processor 402 shown in FIG. 4 .
- the processor 402may, for example, be a conventional microprocessor, and may operate to control the overall functioning of the merchant POI terminal 204 .
- the merchant POI terminal 204may also include conventional peripheral components, in communication with and/or controlled by the processor 402 , such as: (a) a keypad 404 for receiving input from the human operator of the POS terminal; (b) a product reader 406 for reading any form of unique product identifier, such as a barcode or RFID, that appears on, or is attached to, products brought to the terminal for purchase; (c) a cash drawer 408 for storing cash received from customers; (d) one or more displays 410 for providing output (e.g., identifying products presented for purchase and their prices, indicating sales tax due, indicating transaction subtotals and totals, etc., providing prompts to the customer and/or to the sales associate); (e) a printer 412 for printing out sales receipts; and (f) a communication controller 414 for allowing the processor 402 , and hence, the merchant POI terminal 204 to engage in communication over data networks with other devices (e.g., the PSP/acquirer computer 206 , FIG.
- the merchant POI terminal 204may include one or more memory and/or data storage devices (indicated collectively at 416 ), which may comprise any combination of one or more of a hard disk drive, RAM (random access memory), ROM (read only memory), flash memory, etc.
- the memory/data storage device(s) 416may store software and/or firmware that programs the processor 402 and the merchant POI terminal 204 to perform functionality as described herein. Thus the memory/data storage device(s) 416 may be in communication with the processor 402 .
- the merchant POI terminal 204may include one or more housings (not shown) which contain and/or support one or more of the other components shown in FIG. 4 .
- the merchant POI terminal 204may depart from the customary hardware configuration of POS terminals, in that it may lack the usual card-reader elements such as a mag stripe reader, a contact IC card reader, a contactless IC card reader, etc. Instead, the merchant POI terminal 204 may include a suitable hardware arrangement to allow for local communications with the payment-enabled mobile device 202 , to thereby establish the communication channel indicated at 216 in FIG. 2 .
- the payment-enabled mobile device 202it is assumed for this example embodiment of the payment-enabled mobile device 202 that it is configured to communicate via NFC with the payment-enabled mobile device 202 and accordingly the merchant POI terminal 204 includes an NFC module (reference numeral 418 ) for that purpose.
- the NFC module 418is in communication with the processor 402 .
- FIG. 5is a block diagram that illustrates an example embodiment of the WSP computer 208 as shown in FIG. 2 and provided in accordance with aspects of the present invention.
- the WSP computer 208may be conventional in its hardware aspects but may be controlled by software to cause it to function as described herein.
- the WSP computer 208may be constituted by conventional server computer hardware. It should be noted however that (as discussed below) the WSP computer 208 may function as a client device in its interactions with a server function present on the payment-enabled mobile device 202 .
- the WSP computer 208may include a computer processor 500 operatively coupled to a communication device 501 , a storage device 504 , an input device 506 and an output device 508 .
- the computer processor 500may be constituted by one or more conventional processors. Processor 500 operates to execute processor-executable steps, contained in program instructions described below, so as to control the WSP computer 208 to provide desired functionality.
- Communication device 501may be used to facilitate communication with, for example, other devices (such as one or more computers operated by the payment network 110 , the PSP/acquirer computer 206 and/or computers operated by other acquirers/PSPs, and numerous payment-enabled mobile devices such as the device 202 depicted in FIGS. 2 and 3 ).
- communication device 501may comprise numerous communication ports (not separately shown), to allow the WSP computer 208 to communicate simultaneously with a number of other computers and other devices, including communications as required to simultaneously handle numerous payment transactions.
- Input device 506may comprise one or more of any type of peripheral device typically used to input data into a computer.
- the input device 506may include a keyboard and a mouse.
- Output device 508may comprise, for example, a display and/or a printer.
- Storage device 504may comprise any appropriate information storage device, including combinations of magnetic storage devices (e.g., hard disk drives), optical storage devices such as CDs and/or DVDs, and/or semiconductor memory devices such as Random Access Memory (RAM) devices and Read Only Memory (ROM) devices, as well as so-called flash memory. Any one or more of such information storage devices may be considered to be a computer-readable storage medium or a computer usable medium or a memory.
- magnetic storage devicese.g., hard disk drives
- optical storage devicessuch as CDs and/or DVDs
- semiconductor memory devicessuch as Random Access Memory (RAM) devices and Read Only Memory (ROM) devices, as well as so-called flash memory.
- RAMRandom Access Memory
- ROMRead Only Memory
- Storage device 504stores one or more programs for controlling processor 500 .
- the programscomprise program instructions (which may be referred to as computer readable program code means) that contain processor-executable process steps of the WSP computer 208 , executed by the processor 500 to cause the WSP computer 208 to function as described herein.
- the programsmay include one or more conventional operating systems (not shown) that control the processor 500 so as to manage and coordinate activities and sharing of resources in the WSP computer 208 , and to serve as a host for application programs (described below) that run on the WSP computer 208 .
- the programs stored in the storage device 504may also include a transaction handling application program 510 that controls the processor 500 to enable the WSP computer 208 to handle requests for payment transactions in a manner described below in connection with FIGS. 11A and 11B .
- the storage device 504may also store numerous instances of client software programs 512 that control the processor 500 to enable the WSP computer 208 to play a client role with respect to server functions hosted in numerous payment-enabled mobile devices (as provided in accordance with aspects of the present invention) with which the WSP computer 208 may communicate at a given time.
- the storage device 504may store a wallet interface program 514 by which the processor 500 may access digital wallet data stored in the WSP computer 208 with respect to numerous users of the payment system 200 .
- the storage device 504may store an acquirer interface program 516 , which provides a data communications interface to the PSP/acquirer computer 206 ( FIG. 2 ) and to other acquirer computers that present requests for transactions to the WSP computer 208 .
- the storage device 504may also store a payment network interface program 518 , which provides a data communications interface to the payment network 110 (FIG. 2 )—and possibly to other payment networks as well—to allow for submission of authorization requests by the WSP computer 208 and receipt of authorization responses.
- a payment network interface program 518which provides a data communications interface to the payment network 110 (FIG. 2 )—and possibly to other payment networks as well—to allow for submission of authorization requests by the WSP computer 208 and receipt of authorization responses.
- the storage device 504may additionally store a CVM (cardholder verification method) processing program 520 , which operates to handle required CVM processing with respect to consumers who access the payment system 200 via their mobile devices (as will be described further below).
- CVMcardholder verification method
- the storage device 504may store a transaction clearing program 522 , which may handle clearing of payment transactions handled via the WSP computer 208 .
- the storage device 504may also store, and the WSP computer 208 may also execute, other programs, which are not shown.
- programsmay include a reporting application, which may respond to requests from system administrators for reports on the activities performed by the WSP computer 208 .
- the other programsmay also include, e.g., one or more data communication programs, device drivers, etc.
- the storage device 504may also store one or more databases 524 required for operation of the WSP computer 208 .
- databasesmay include, for example, a database (not separately indicated in FIG. 5 ) for storing data corresponding to digital wallets maintained for consumers/cardholders in the WSP computer 208 .
- the PSP/acquirer computer 206may be constituted by conventional computer hardware; thus the PSP/acquirer computer 206 may have the same hardware architecture and aspects as described above in connection with the description of the WSP computer.
- the computer hardware making up the PSP/acquirer computer 206may be programmed to cause the PSP/acquirer computer 206 to perform functions such as are described below.
- FIG. 6schematically represents enrollment of a payment card account with a wallet service provider (e.g., the operator of WSP 208 ) that participates in the payment system 200 of FIG. 2 .
- a wallet service providere.g., the operator of WSP 208
- the block that represents the WSPis labeled with reference numeral 208 which it shares with WSP computer 208 of FIGS. 2 and 5 .
- Each WSP in the system(only one WSP is depicted but there may be a considerable number that participate in the system) has a particular identifier to distinguish the WSP from other WSPs in the system.
- the WSP service provided by the assignee hereof(MasterCard International Incorporated) is identified as “MasterPass”.
- a similar service available from Visa Inc.is identified as “V.me”.
- wallet services provided by WSP 208are “financial” in the sense that the accounts stored in the consumers' digital wallets maintained by WSP 208 are financial accounts.
- Other types of wallet servicesmay also be provided, such as “value added services” (VAS) wallets, as will be described below (for instance, in connection with FIG. 13 ).
- VASvalue added services
- a user/consumer 210is depicted in FIG. 6 ; this individual—it is assumed—wishes to have one of his/her payment card accounts added to his/her digital wallet 602 maintained for him/her by the WSP 208 .
- each consumer's digital walletmay exist as a unique entry for the consumer in a database maintained by the WSP/WSP computer 208 .
- the consumer's entry/digital walletmay be identified with a unique identifier for the entry.
- the unique identifier for the consumer's digital walletmay be a Universal Resource Identifier (URI) that has been assigned to a server function hosted on the consumer's mobile device 202 ( FIG. 2 ).
- URIUniversal Resource Identifier
- a URIuniquely identifies a point of content in internet space, and thus may serve as an internet address.
- each consumermay be registered with—and hence have a respective digital wallet with—more than one WSP.
- the consumer's respective digital walletmay be identified by the same identifier across all the WSPs, namely by the just-mentioned URI for the server function hosted on the consumer mobile device 202 .
- Each consumer's digital wallet/WSP entry 602may itself be a data repository for storing digitalized payment cards that the consumer has selected for inclusion in his/her digital wallet.
- the digitalized cardsmay be issued by the same issuing financial institution or by several different issuers.
- the digitalized cardsmay all be branded from the same payment network or from more than one payment network. Inclusion of digitalized cards from a given payment network in the WSP 208 's database (i.e., in consumers' digital wallets maintained by WSP 208 ) can occur if the WSP 208 has entered into a relationship with that payment network to allow the WSP to act as a quasi-acquirer with respect to that payment network.
- Block 604 in FIG. 6represents one of the user 210 's payment card accounts that the user has elected to have included in his her digital wallet 602 as a digitalized card 606 .
- the particular digitalized card 606may be assigned an easy-to-recognize identifier to distinguish it (for the user) from other digitalized cards (not shown) that are also present in the user's digital wallet 602 .
- the digitalized imageconsists of the personalization template of the card application (i.e., a software application for digitally implementing the payment card account).
- the items included in the digitalized imagedepend on the requirements for wallet based transactions as established by the payment network for which the payment card account was issued.
- the WSP computer 208implements an engine that emulates the card payment application for the digitalized card 606 . It can be said that the digitalized card 606 is made up of the digitalized image/personalization template for the particular payment card account plus the WSP engine for the relevant card payment application. As will be seen, the WSP 208 uses the digitalized payment card 606 to trigger and complete wallet payment transactions in place of the payment account card itself
- Every payment networkis likely to require the PAN and the expiration date for the digitalized card image.
- Some payment networksmay also require a Card Authentication Method (CAM).
- CAMCard Authentication Method
- a static CAMmay be required, such as the CVC 2 as established by MasterCard or the CVV as established by Visa.
- a dynamic CAMmay be required, such as is provided in an EMV transaction.
- EMVis a standard for inter-operation of IC cards with POS terminals and/or ATMs.
- the WSP computer 208itself may run an EMV engine.
- Some payment networksmay require a specific CVM, such as a biometric (e.g., voice recognition in real time and/or face motion recognition), for each transaction.
- a biometrice.g., voice recognition in real time and/or face motion recognition
- Other types of CAM/CVM requirementsare also possible and/or contemplated, and some others will be discussed below.
- the issuer of the payment card accountmay specify one or more CVMs instead of or in addition to CVM(s) required by the payment network.
- FIG. 7schematically illustrates software and functional aspects of the payment-enabled mobile device 202 shown in FIGS. 2 and 3 .
- the payment-enabled mobile device 202serves as the credential of the user 210 with respect to the payment system 200 and also is the mechanism by which the user 210 is able to initiate and perform payment transactions and otherwise to interact with the payment system 200 .
- the payment-enabled mobile device 202hosts a server function, represented at block 702 in FIG. 7 .
- This functionwill sometimes be referred to as the consumer device server function.
- the consumer device server function 702may be implemented in accordance with the Smart Card Web Server (SCWS) standard promulgated by the Open Mobile Alliance (OMA), and may run on the SIM card 308 ( FIG. 3 ) and/or the secure element 328 .
- SCWSSmart Card Web Server
- OMAOpen Mobile Alliance
- the consumer device server function 702may be implemented in accordance with the GlobalPlatform Networked Framework. The latter may be advantageous in that it supports unlimited quantities of data per communication and thus removes the need to segment data, as may be required in an SCWS implementation.
- the WSP 208may fulfill the role of parameterizing the consumer device server function 702 .
- the parameters to be providedmay include the WSP's identifier in the payment system 200 , and appropriate cryptographic material, to allow the WSP 208 to form a secure data communication connection with the consumer device server function 702 during execution of a payment transaction.
- Execution of a payment transactionmay require services of a number of resources within the payment-enabled mobile device 202 , such as a file system 704 .
- the file systemmay, for example, store files related to coupons, promotional vouchers, customer loyalty points, etc.
- the wallet selection application 708may function to allow the user 210 to select among payment card accounts (digitalized payment cards) housed in the user's digital wallet.
- the EMV payment application 710may provide such functionality as producing a payment token for use in offline-only EMV POI terminals (for such transactions, the WSP would not be involved, and the authentication token provided—as described below—in consumer-device-server-function-to-WSP transactions would not be produced).
- a database(block 712 , FIG. 7 ) may also be supported in the payment-enabled mobile device 202 in association with one or more of the applications 706 .
- the consumer device server function 702is uniquely identified in the payment system 200 through a unique URI, as referred to above.
- the URIis the root of a namespace tree, such as that depicted in FIG. 8 .
- the above-mentioned namespace rootis represented by block 802 .
- the wallet selection application referred to aboveis represented by block 804 , and is reached through the tree via the applications namespace (block 806 ) and the wallet path element (block 808 ).
- the above-mentioned EMV payment applicationis represented by block 810 in FIG. 8 and is reached through the tree via the applications namespace 806 and the EMV path element 812 .
- the tree illustrated in FIG. 8also may include a files namespace (block 814 ).
- a default address leaf(block 816 ) is reachable via the files namespace 814 and a shipping address path element 818 .
- the default shipping addressmay be modified by the user, and may be used to update the user's digital wallet at the WSP computer 208 , with the wallet selection application sending the updated address to the WSP computer 208 in response to a call to the wallet selection application.
- An HTTP web client(such as a client application hosted on the WSP computer 208 ) may interact with the consumer device server function 702 in the following manner, for example.
- the web clientmay ask the consumer device server function 702 for a service through an appropriate HTTP command.
- the commandmay encode several imbricated sub-commands that are targeted to resources accessible via the namespace tree.
- the consumer device server function 702may dispatch the HTTP command based on the semantic of the command.
- the consumer device server function 702may identify all imbricated sub-commands to be further directed to the appropriate resources, and then sequentially sends the identified sub-commands to each relevant resource.
- a resourcemay require an interaction with the user 210 .
- the resourcee.g., the wallet selection application
- the resourcemay need to receive input from the user 210 concerning the user's selection of a preferred card or set of cards to be used in a current payment transaction.
- the resourcemay require the user to perform a CVM (e.g., PIN entry or biometric) in order to produce proof that the user is not an impostor.
- CVMe.g., PIN entry or biometric
- Each resourcemay elaborate its partial processing result corresponding to the set of sub-commands it executed and may return the partial processing result to the consumer device server function 702 .
- the consumer device server function 702may use the partial processing results received from the various resources to compose the HTTP response to be sent to the web client that made the HTTP command.
- FIG. 9illustrates still further details of software aspects of the payment-enabled mobile device 202 shown in FIGS. 2 and 3 .
- FIG. 9illustrates a basic software configuration that may be provided to implement an authentication token procedure in accordance with aspects of the present invention.
- the payment-enabled mobile device 202may be further configured with additional software features to accommodate other functionality including possibly additional functionality described hereinbelow.
- the main software features shown in FIG. 9are an interception application software program 902 , a wallet selection application program 904 , and a contact exchange application software program 906 .
- the wallet selection application program 904may coincide or overlap with the wallet selection application 708 referred to above in connection with FIG. 7 .
- the interception application software program 902 , the wallet selection application program 904 and the contact exchange application software program 906may in some embodiments run on the secure element 328 ( FIG. 3 , also depicted in FIG. 9 ).
- FIG. 3also depicted in FIG. 9
- the interception application software program 902may serve as a front end of the consumer device server function 702 referred to in connection with FIG. 7 and may provide the connection for the server function with the outside world, while dispatching sub-commands to internal software resources of the payment-enabled mobile device 202 .
- the interception application software program 902may perform some or all of the following tasks, among others: (a) Establishing an HTTP communication session with an HTTP client (such as a client program running on the WSP computer 208 , FIG.
- the clients in questionmay include the WSP client—as just mentioned, a client program running on the payment-enabled mobile device 202 , or another web client).
- the interception application software program 902may establish a secure communication tunnel with the WSP computer 208 by taken such actions as: (a) successful authentication of the WSP computer 208 ; (b) providing authenticable information to the WSP computer 208 to certify that the payment-enabled mobile device 202 and the consumer device server function 702 are eligible for participation in the payment system 200 and were issued/enrolled by the operator of the WSP computer 208 (i.e., by the wallet service provider in question); and (c) establish secure communications with the WSP computer 208 .
- the resulting communication sessionwill provide encryption, data integrity and data origin authentication of all the data transferred between the payment-enabled mobile device 202 and the WSP computer 208 .
- Various secure tunneling technologiescan be used for this purpose, in accordance with the communication security aspects implemented in the payment-enabled mobile device 202 and the WSP computer 208 .
- the client running in the WSP computer 208can submit any type of HTTP request to the consumer device server function 702 , with imbricated sub-commands to application resources within the payment-enabled mobile device 202 .
- Establishment of the secure communication channel between the WSP computer 208 and the consumer device server function 702may involve use of a set of cryptographic keys previously loaded into the payment-enabled mobile device 202 during a personalization process performed by the WSP computer 208 with respect to the interception application software program 902 .
- the interception application software program 902may filter the sub-commands submitted by the client to limit the client's request to actions such as selecting one or more payment card accounts and corresponding amounts to be charged to the accounts in accordance with options presented in a wallet selection form uploaded from the WSP client to the consumer device server function 702 for purposes of a current transaction.
- the WSP computer 208may consider the HTTP response from the consumer device server function 702 (i.e., conveying the wallet selection data as indicated by the user) if and only if such information is coming to the WSP computer 208 via the secure communication channel referred to above and established between the WSP client and the interception application software program 902 .
- the communication of the wallet selection informationin a suitably secure manner, may be deemed an authentication token submitted for the transaction by the payment-enabled mobile device 202 .
- the user's selection of wallet options as communicated via the authentication tokenmay involve interaction between the user and the wallet selection application program 904 .
- Another action that the interception application software program 902 may permit a client on the payment-enabled mobile device 202 to performmay be a CVM for authentication of the user as the legitimate owner of the payment-enabled mobile device 202 .
- Still another action that the interception application software program 902 may permit a client on the payment-enabled mobile device 202 to performmay be selection of a communication technology (e.g., NFC, Bluetooth, Wi-Fi, QR code, SMS, USSD, etc.) as the mode of communication available between the payment-enabled mobile device 202 and the merchant POI terminal 204 ( FIG. 2 ) for exchanging contact and transaction data between the payment-enabled mobile device 202 and the merchant POI terminal 204 .
- a communication technologye.g., NFC, Bluetooth, Wi-Fi, QR code, SMS, USSD, etc.
- the interception application software program 902may function such that other clients (e.g., a client program running on the merchant POI terminal 204 ) may only send information to an application resource on the payment-enabled enabled mobile device 202 .
- the interception application software program 902may permit a client running on the merchant POI terminal 204 to send transaction detail data to the contact exchange application software program 906 , without requesting processing, and the contact exchange application software program 906 /interception application software program 902 may return contact information for the payment-enabled mobile device 202 , such as data that identifies the WSP for the user of the payment-enabled mobile device 202 , and the URI for the consumer device server function 702 on the payment-enabled mobile device 202 .
- wallet selection application program 904may serve as a resource application that receives data communicated from the WSP computer 208 via the secure tunnel established between the interception application software program 902 and the WSP computer 208 .
- This datamay include data retrieved by the WSP computer 208 from the digital wallet it maintains for the user of the payment-enabled mobile device 202 .
- This datamay be referred to as “wallet form data”, and may be such as is needed to allow the user to interact with a client running on the payment-enabled mobile device 202 to visualize his/her digital wallet as maintained on the WSP computer 208 .
- the useris able to choose from his/her digital wallet a payment card account (or more than one such account) to be used for a current transaction. (I.e., it is contemplated that the user may pay for the entire transaction with one payment card account in his/her wallet, or alternatively he/she may split the transaction amount for funding by two or more of the payment card accounts represented in his/her digital wallet.)
- the wallet selection application program 904may require the user to perform a specific CVM.
- the CVMmay call for one or more of the following: (a) entry by the user of an overall wallet access password (not specific to a particular payment card account); (b) entry by the user of the PIN for a particular payment card account selected by the user for the current transaction; and/or (c) submission by the user of biometric input.
- the required CVMmay include submission of a biometric that provides “proof of life”—one example of such a biometric would be a spoken utterance by the user to be processed for voice recognition; subsequent discussion herein will describe some examples of voice-recognition-based CVMs that may be provided in accordance with aspects of the present invention.
- the contact exchange application software program 906may also be a resource application on the payment-enabled mobile device 202 and may serve to permit the user to exchange data with the merchant POI terminal 204 .
- the contact exchange application software program 906may supply to the merchant POI terminal 204 address data that identifies the (or a) WSP for the user. In some embodiments, this address data may simply be an identifier by which the WSP is recognized or designated in the payment system 200 .
- the contact exchange application software program 906may supply to the merchant POI terminal 204 address data for the payment-enabled mobile device 202 , such as the above-mentioned URI which serves as an internet address for the consumer device server function 702 (which may ultimately be passed on to the WSP computer 208 , via the merchant POI terminal 204 and the PSP/acquirer computer 206 ).
- address data for the payment-enabled mobile device 202such as the above-mentioned URI which serves as an internet address for the consumer device server function 702 (which may ultimately be passed on to the WSP computer 208 , via the merchant POI terminal 204 and the PSP/acquirer computer 206 ).
- the latter datamay include data concerning the present transaction (which may be denoted as “transaction detail data” and which may include the transaction amount, for example), and also may include data concerning the context (“transaction context data”), such as data related to identification of the merchant, the merchant location, and/or the particular merchant POI terminal 204 in question.
- transaction detail datadata concerning the present transaction
- context datadata concerning the context
- the mode of communicationmay be selected by the user, who may provide input into the payment-enabled mobile device 202 to select, e.g., one of a list of communication modes displayed on the merchant POI terminal 204 as visual icons that are viewable by the user.
- the communication optionsmay include one or more of NFC, Bluetooth, WiFi, QR code and/or USSD.
- the consumer device server function 702may be configured to operate in accordance with GPNF, as promulgated by GlobalPlatform, and/or in accordance with the SCWS (Smart Card Web Server) standard published by OMA.
- hardware options for the payment-enabled mobile device 202may include a generally conventional smartphone, e.g., with the consumer device server function 702 running on an IC card installed in the smartphone.
- FIG. 10schematically illustrates software aspects of the merchant POI terminal 204 ( FIGS. 2 and 4 ).
- the merchant POI terminal 204may serve as the device that represents the merchant in a particular purchase transaction, and interacts on one hand with the payment-enabled mobile device 202 and on the other hand with the PSP/acquirer computer 206 .
- a contact exchange terminal application 1004is provided to interact with the payment-enabled mobile device 202
- a PSP/acquirer application 1006is provided to interact with the PSP/acquirer computer 206 .
- the contact exchange terminal application 1004may establish a handshake with the contact exchange application software program 906 in the payment-enabled mobile device 202 to allow the following data exchange: (a) (from merchant POI terminal 204 to payment-enabled mobile device 202 ) transmission of the transaction detail data for the current transaction and the transaction context (merchant context) data for the current transaction; and (b) (from payment-enabled mobile device 202 to merchant POI terminal 204 ) transmission of the URI for the consumer device server function 702 and the identifier for the user's WSP.
- the PSP/acquirer application 1006may establish an internet connection with the PSP/acquirer computer 206 using, for example, TLS (transport layer security) tunneling via the internet to enable the following exchanges of data: (a) (from merchant POI terminal 204 to PSP/acquirer computer 206 ) the PSP/acquirer application 1006 transmits the contact details for the payment-enabled mobile device 202 (i.e., WSP identifier and URI for the consumer device server function 702 ) and the same transaction detail data and transaction context data that the contact exchange terminal application 1004 provided to the contact exchange application software program 906 ; and (b) (from PSP/acquirer computer 206 to merchant POI terminal 204 ; after interaction between the PSP/acquirer computer 206 and the WSP computer 208 ) the PSP/acquir
- communication protocol softwaremay be provided, including communication protocol software elements 1010 - 1 through 1010 -n for communicating with the payment-enabled mobile device 202 , and an internet/GPRS (General Packet Radio Service) communication protocol software element 1012 . Communications via the latter may in some embodiments eventually pass through a WiFi connection.
- the communication protocol software element 1012may provide at least part of the communication link between the merchant POI terminal 204 and the PSP/acquirer computer 206 .
- FIGS. 11A and 11Btogether form a flow chart that illustrates a transaction process that may be performed in the payment system 200 ( FIG. 2 ) in accordance with aspects of the present invention.
- a purchase transactionis initiated.
- a customeruser 210 of the payment-enabled mobile device 202
- FIGS. 11A and 11Bthe process of FIGS. 11A and 11B is also generally applicable to the environment of an e-commerce transaction.
- transaction datais input into the merchant POI terminal 204 , which may be located at the point-of-sale counter. This may occur, for example, by the merchant sales associate operating the merchant POI terminal 204 by, e.g., scanning barcodes on the merchandise to allow input to the merchant POI terminal 204 of the identifiers of the merchandise items and also to allow for lookup by the merchant POI terminal 204 of price information for the merchandise items. As a result of this operation, the merchant POI terminal 204 may calculate a total amount for the purchase transaction (transaction amount). In addition, the merchant POI terminal 204 may generate other transaction data including, for example, a data element that indicates what currency the transaction amount is denominated in, as well as the date of the transaction.
- the merchant POI terminal 204may transmit the transaction detail data (e.g., amount, currency, date, etc.) to the payment-enabled mobile device 202 , and at the same time the merchant POI terminal 204 may transmit transaction context data to the payment-enabled mobile device 202 .
- the transaction context datamay include a merchant identifier and location (which may be parameters stored in the merchant POI terminal 204 ).
- the transaction context datamay include a unique transaction number (UTN).
- the merchant POI terminal 204may generate a fresh UTN for each transaction it handles.
- the merchant POI terminal 204may calculate the UTN as a hash of such information as the merchant identifier, the transaction location, a transaction counter value, and possibly other information as well.
- the merchant POI terminal 204may operate to increment the transaction counter value with each transaction that occurs at the merchant POI terminal 204 .
- the payment-enabled mobile device 202may transmit data to the merchant POI terminal 204 to permit the payment-enabled mobile device 202 to be contacted for a subsequent stage (token passing) of the transaction process.
- the data transmitted from the payment-enabled mobile device 202 to the merchant POI terminal 204may be address data, in particular: (a) the identifier for the WSP that stores the digital wallet for the user (or at least one of the user's digital wallets), and (b) the URI for the consumer device server function 702 hosted in the payment-enabled mobile device 202 .
- the usermay be prompted to select a WSP and/or a digital wallet from among a plurality of his/her WSPs/digital wallets before step 1108 occurs and/or the user may make such a selection without being prompted and perhaps while approaching the point-of-sale counter. It is within the contemplation of aspects of this invention that the payment-enabled mobile device 202 may run a WSP-selection app or the like for this purpose.)
- the communication channel 216( FIG. 2 ) between the payment-enabled mobile device 202 and the merchant POI terminal 204 need not be highly secure, as no highly sensitive data such as a PAN (primary account number) is being exchanged between the two devices.
- the merchant POI terminal 204may transmit data to the PSP/acquirer computer 206 . This may occur over communication channel 218 ( FIG. 2 ), which may be implemented over a wide-area network such as the internet or GPRS.
- the communication channel 218may be secured by an appropriate measure, such as TSL.
- the data transmitted at 1110may include the address data that the merchant POI terminal 204 received from the payment-enabled mobile device 202 at 1108 , and transaction data such as the transaction details, the transaction context and the current transaction counter value.
- decision block 1112the determination represented by decision block 1112 may be made by and at the PSP/acquirer computer 206 .
- the merchant POI terminal 204may check that the merchant is duly eligible to participate in the payment system 200 in the manner requested by the merchant POI terminal 204 . This may involve the PSP/acquirer computer 206 searching for the merchant identifier (included in the transaction context data) in one or more merchant subscription tables.
- the PSP/acquirer computer 206may proceed with further checks, such as checking that the transaction counter is fresh and that the UTN is valid relative to the merchant.
- the PSP/acquirer computer 206may check the identification of the WSP to confirm that the WSP is validly enrolled in the payment system 200 . This may occur in a manner that is analogous to a conventional operation in which an acquirer may confirm the validity of a payment network for which a PAN-based authorization request is to be submitted.
- block 1114may follow decision block 1112 in the process of FIGS. 11A and 11B .
- the PSP/acquirer computer 206may transmit data to the WSP computer 208 .
- the PSP/acquirer computer 206may use the identifier of the WSP as received from the merchant POI terminal 204 to determine that it should establish a secure communication channel (channel 220 in FIG. 2 ) with the appropriate WSP. This may be done over the internet, for example, with TSL.
- the data transmitted at 1114may include all the data received by the PSP/acquirer computer 206 at 1110 , except possibly excluding the transaction counter value provided by the merchant POI terminal 204 . It will be noted that, according to aspects of this invention, this data will typically include the URI for the consumer device server function 702 hosted on the payment-enabled mobile device 202 .
- Block 1116follows block 1114 .
- the WSP computer 208receives and processes the data transmitted by the PSP/acquirer computer 206 .
- the WSP computer 208may generate a transaction identifier, which may for example be formed from the merchant identifier (corresponding to the merchant that operates the merchant POI terminal 204 ) plus the UTN provided in the message received by the WSP computer 208 from the PSP/acquirer computer 206 .
- the WSP computer 208may store the transaction data (transaction detail data and transaction context data), as received from the PSP/acquirer computer 206 , in association with the transaction identifier generated by the WSP computer 208 .
- the WSP computer 208may read, from the data supplied by the PSP/acquirer computer 206 , the URI for the consumer device server function 702 hosted in the payment-enabled mobile device 202 .
- the WSP computer 208may verify that the URI in question is not blacklisted and that the user in question has a valid subscription to the wallet services provided by the WSP that operates the WSP computer 208 .
- Block 1118follows block 1116 .
- the WSP computer 208goes on to retrieve the wallet entry for the user of the payment-enabled mobile device 202 , as identified by the above-mentioned URI.
- the WSP computer 208forms wallet form data to be sent to the consumer device server function 702 hosted in the payment-enabled mobile device 202 .
- the wallet form datawill present information to the user to permit him/her to choose among the payment card accounts in his/her digital wallet to select the account(s) to be used for the current transaction. If the user wishes to use more than one of his/her accounts and to distribute the transaction amount among the selected accounts, the wallet form data may allow the user to indicate his/her choices in this regard as well.
- Block 1120follows block 1118 .
- the WSP computer 208uses the URI for the consumer device server function 702 hosted in the payment-enabled mobile device 202 to initiate formation of a secure communication channel (channel 222 in FIG. 2 ) between the WSP computer 208 and the consumer device server function 702 hosted in the payment-enabled mobile device 202 .
- a so-called secure tunneling technologymay be employed, such as one of the published protocols known as “SCP” (secure channel protocol).
- the consumer device server function 702 hosted in the payment-enabled mobile device 202(and particularly, the interception application software program 902 ) cooperates with the WSP computer 208 in exchanging information necessary for the WSP computer 208 and the consumer device server function 702 hosted in the payment-enabled mobile device 202 to mutually authenticate each other.
- the WSP computer 208 and the consumer device server function 702 hosted in the payment-enabled mobile device 202have mutually authenticated each other, and enciphering of communications in both directions through the channel 222 is enabled.
- block 1122follows block 1120 .
- the WSP computer 208transmits the above-referenced wallet form data to the payment-enabled mobile device 202 (i.e., to the consumer device server function 702 ).
- block 1124follows block 1122 .
- the payment-enabled mobile device 202(particularly the interception application software program 902 ) decrypts the wallet form data and submits the information contained in the wallet form data to the user via the wallet selection application program 904 .
- the user 210selects the account(s) for the current transaction, and if necessary the respective amounts for funding by each account, if more than one account is selected.
- the resulting account selection datais provided within the payment-enabled mobile device 202 to the interception application software program 902 . (It may be the case that, in connection with the user's interaction with the wallet selection application program 904 , the user may be required to properly complete a CVM process, such as those referred to above. For example, PIN entry and/or submission of biometric input may be required.
- the resulting dataultimately is passed along to the WSP computer 208 for verification.
- Block 1126follows block 1124 .
- the interception application software program 902generates an authentication token for the transaction.
- the interception application software program 902may generate the authentication token as a Message Authentication Code (MAC) on the basis of the account selection data, and the transaction data (transaction detail data and transaction context data) that the payment-enabled mobile device 202 had received at block 1106 ( FIG. 11A ) from the merchant POI terminal 204 .
- MACMessage Authentication Code
- the interception application software program 902may generate a transaction identifier, which may contain the merchant identifier for the transaction plus the UTN generated for the transaction by the merchant POI terminal 204 and transmitted to the payment-enabled mobile device 202 at block 1106 .
- the interception application software program 902(and hence the payment-enabled mobile device 202 ) may then transmit the following data to the WSP computer 208 : (a) the account selection data, as indicated by the user 210 at 1124 ; (b) the transaction identifier, and (c) the authentication token.
- the payment-enabled mobile device 202may not transmit the transaction data (i.e., the transaction detail data and the transaction context data) in their complete form to the WSP computer 208 , nevertheless, because the authentication token is based on the transaction data (with other data elements), the authentication token may be considered a verifiable copy of the transaction data.
- block 1128follows block 1126 .
- the WSP computer 208receives the data transmitted from the payment-enabled mobile device 202 (i.e., from the interception application software program 902 /consumer device server function 702 ). Using the transaction identifier provided by the payment-enabled mobile device 202 , the WSP computer 208 matches the data received from the payment-enabled mobile device 202 with the data it had stored for the transaction in association with the transaction identifier as generated by the WSP computer 208 at block 1116 .
- the WSP computer 208identifies the transaction detail data and the transaction context data that it had previously stored (after receiving same from the PSP/acquirer computer 206 at 1116 ) and proceeds to verify the authentication token as provided by the consumer device server function 702 hosted in the payment-enabled mobile device 202 . In doing so, the WSP computer 208 in effect confirms that the transaction detail data and the transaction context data as reflected in the authentication token match the transaction detail data and the transaction context data as received by the WSP computer 208 from the PSP/acquirer computer 206 . Verification of the authentication token by the WSP computer 208 indicates to the WSP computer 208 that the account selection data from the payment-enabled mobile device 202 is valid and has the effect of a payment order to be executed by the WSP computer 208 .
- Block 1130follows block 1128 . It will initially be assumed for the purpose of describing block 1130 that the user 210 had selected only one payment card account from his/her digital wallet to fund the current transaction. Accordingly, at 1130 the WSP computer 208 , acting substantially like a conventional acquirer, uses the PAN for the user-selected payment card account (as stored in and retrieved from the user's digital wallet) to route a payment network authorization request via the indicated payment network (assumed to be the payment network 110 shown in FIG. 2 ) to the issuer of the user-selected payment card account (assumed to be the issuer 112 shown in FIG. 2 ).
- the account selection data provided by the payment-enabled mobile device 202 to the WSP computer 208may include two or more lines, with each line corresponding to a respective user-selected account and with each line indicating the portion of the transaction amount to be charged to the respective account.
- the WSP computer 208may issue a respective authorization request via the appropriate payment network (i.e, more than one payment network may be involved in the current transaction, although only one payment network is depicted in FIG. 2 ) for routing to the respective issuer for the account.
- block 1132follows block 1130 .
- the WSP computer 208receives a substantially conventional authorization response message, which originated from the issuer 112 and which was routed to the WSP computer 208 via the payment network.
- the authorization responseindicates approval by the issuer of the authorization request initiated by the WSP computer 208 (or, if more than one payment card account had been selected by the user, it is assumed that all of the authorization responses from the issuers indicate approval), in which case, block 1134 follows block 1132 .
- the WSP computer 208transmits an acknowledgment message to the PSP/acquirer computer 206 to confirm that payment has been duly made for the current transaction.
- Block 1136then follows.
- the PSP/acquirer computer 206transmits an acknowledgment message to the merchant POI terminal 204 to confirm that payment has duly been made for the current transaction.
- Block 1138then follows, at which the purchase transaction at the retail store is completed.
- the merchant POI terminal 204may display to the merchant's sales associate an indication that payment has been acknowledged/confirmed, and may print a suitable receipt for the customer/mobile device user 210 . The customer may then leave the retail store with the purchased merchandise and the receipt.
- the payment system 200may provide enhanced security for sensitive information such as payment card account PANs as compared to conventional payment systems in which the merchant reads the PAN from a card or other device at the point of purchase.
- sensitive informationsuch as payment card account PANs
- the merchantnever has possession of the customer's PAN; accordingly, a mass data breach at the merchant level, with attendant difficulties and potential exposure to fraud, may be highly unlikely or impossible with the payment system 200 .
- the cost of the POS terminalmay be substantially reduced as compared to conventional POS equipment currently in use.
- the POI terminal as described hereinthere may be no need for the type of complex cryptographic calculations that are employed in some conventional POS equipment. Accordingly the POI terminal as described herein may be simplified in that it may not need to have either a fast main processor and/or a specialized cryptographic processor, such as may be included in conventional POS equipment.
- the POI terminal described hereinmay be simplified, in that there may be no need for such components as a secure keyboard, a secure biometric sensor or a secure display device.
- tampering detection and tampering reaction mechanismsmay not be needed in the POI terminal described herein, because the POI terminal no longer handles payment application processes, but rather is a protocol adapter for exchanging basic information between the customer and the merchant, while also relaying basic information from the consumer device server function 702 hosted in the payment-enabled mobile device 202 to the PSP/acquirer and on to the WSP.
- the payment-enabled mobile device 202provides a representation of transaction data to the WSP computer 208 , for comparison by the WSP computer 208 with the transaction data received from the merchant POI terminal 204 via the PSP/acquirer computer 206 , there is enhanced protection against fraudulent unsolicited transactions.
- the merchant POI terminal 204was located at the point of sale in a brick-and-mortar retail store.
- the merchant POI terminal 204may for example be constituted by an e-commerce server operated by a merchant to handle online purchase transactions.
- the customermay access the merchant POI terminal 204 initially in a conventional manner (e.g., via a browser running on a personal computer), or alternatively may use a mobile device browser running on his/her smartphone/mobile device (which may also be the above-described payment-enabled mobile device 202 ).
- the merchant POI terminal 204 and the payment-enabled mobile device 202may exchange such information as is described above in connection with blocks 1106 and 1108 . This may occur, for example, via such communication modes as SMS (short message service) or USSD (unstructured supplementary service data).
- the exchange of this informationmay alternatively be conducted via HTTP communications, with the mobile device 202 acting as a client and connecting to the merchant's website via its browser.
- the payment-enabled mobile device 202may exchange communications with the merchant POI terminal 204 via a mobile communications network (not shown) for which the payment-enabled mobile device 202 is a subscriber device.
- the process as described above in connection with FIGS. 11 A/ 11 Bmay be quite similar.
- the merchant POI terminal 204 and the payment-enabled mobile device 202may be able to interact directly via a bidirectional exchange.
- the merchant POI terminal 204 and the payment-enabled mobile device 202acting as peer devices, may perform an automatic setup of a bidirectional channel between the two devices. This could occur in a number of ways, depending on the features present in the devices. For example, this could be done directly through an NFC peer-to-peer data exchange. This may be an advantageous approach in that it takes advantage of existing smartphone capabilities.
- the bidirectional communicationcould occur through a process where the devices cooperate via NFC to transfer over to another technology such as Bluetooth or WiFi.
- the merchant POI terminal 204 and the payment-enabled mobile device 202may interact outside a communication channel.
- the payment-enabled mobile device 202may submit the information referred to in connection with block 1108 to a phone number visually displayed on the merchant POI terminal 204 .
- the payment-enabled mobile device 202(assuming it includes a camera, as many smartphones do), may capture an image of a QR code (quick response code) as displayed by the merchant POI terminal 204 (or downloaded from the merchant, in the case where the merchant POI terminal 204 is an e-commerce server).
- the PSP/acquirer computer 206functions essentially as a switch between merchant devices and WSPs. It is contemplated that some embodiments may omit the PSP/acquirer computer 206 in favor of a direct communication link between the merchant POI terminal 204 and the WSP computer 208 . However, it may be advantageous to have acquirers as a layer between merchants and WSPs to aid in managing the workload for the WSPs and to enhance scalability of the payment system 200 . It may also aid in fast and efficient conflict resolution and chargebacks to have acquirers present in the payment system 200 between merchants and WSPs.
- FIG. 12schematically illustrates a clearing process that may be performed in the system 200 of FIG. 2 in accordance with aspects of the present invention.
- payment card issuers' settlement accountsare indicated at 1202 .
- the settlement accounts of payment networksare indicated at 1204 . (Although only one payment network account 1204 is shown as having payment card issuers' accounts feeding into it, in practice, as will be appreciated, the same will be true of all of the payment network settlement accounts.)
- a first level of the clearing processis indicated at 1206 , and features a WSP 1208 , having a WSP pool account 1210 .
- a second level of the clearing processis indicated at 1212 , and features settlement accounts 1214 belonging to PSPs/acquirers.
- FIG. 12Also shown in FIG. 12 are merchant settlement accounts 1216 . (To simplify the drawing, only one of the PSP/acquirer settlement accounts 1214 is shown feeding merchant settlement accounts 1216 ; however it will be understood that in practice all the PSP/acquirer settlement accounts 1214 would do the same.)
- One of the payment card issuer settlement accounts 1202may be associated with the issuer 112 shown in FIG. 2 .
- One of the payment network settlement accounts 1204may be associated with the payment network 110 shown in FIG. 2 .
- the WSP 1208 shown in FIG. 12may be the operator of the WSP computer 208 shown in FIG. 2 .
- One of the PSP/acquirer settlement accounts 1214 shown in FIG. 12may be associated with the operator of the PSP/acquirer computer 206 shown in FIG. 2 .
- One of the merchant settlement accounts 1216 shown in FIG. 12may be associated with the merchant that operates the merchant POI terminal 204 shown in FIG. 2 .
- Block 1210 shown in FIG. 12in addition to representing the WSP pool account, should also be understood to represent a computer that manages the flow of clearing credits into and out of the pool account. That computer may be operated by a financial institution, by the WSP, or by another entity and may for example be the WSP computer 208 of FIG. 5 .
- the WSP 1208has a role like a “mega” acquirer, and each PSP/acquirer represented in FIG. 12 has a role like a “mega” merchant.
- the clearing between the WSP 1208 and the payment card issuersoccurs in the same manner as conventional clearing between an acquirer and issuers through a payment network.
- the WSP 1208manages the pool account 1210 to receive clearing credits from the payment network settlement accounts 1204 , where the clearing credits originated from payment card accounts issued by the payment card issuers represented in FIG. 12 .
- the WSP 1208manages the pool account 1210 to distribute the clearing credits among the PSP/acquirer settlement accounts 1214 .
- each acquirermanages its respective settlement account 1214 to clear credits due to its subscriber merchants.
- each of the PSP/acquirer settlement accounts 1214receives clearing credits from the WSP pool account 1210 , and those credits are further distributed to the merchant accounts 1216 .
- FIG. 12may aid in enhancing the scalability of the payment system 200 .
- FIG. 12also illustrates how funds flow among participants in the acquiring process with appropriate service fees accruing.
- FIG. 13is a block diagram that illustrates an alternative embodiment (generally indicated by reference numeral 200 a in FIG. 13 ) of the payment system of FIG. 2 .
- the payment system 200 a shown in FIG. 13may include essentially all of the components of the payment system 200 as described in connection with FIG. 2 and subsequent drawings.
- the payment systemmay include a value added services (VAS) WSP computer 1302 that is connected (at least from time to time) to an PSP/acquirer computer 206 a via a communication channel 1304 .
- VASvalue added services
- the PSP/acquirer computer 206 a shown in FIG. 13may include all of the functionality of the PSP/acquirer computer 206 shown in FIG. 2 and as described above, and in addition may perform additional switching and/or other functions to accommodate value added services/split payment functionality in the payment system 200 a of FIG.
- the VAS WSP computer 1302may maintain for the user 210 (and many other users as well) one or more digital wallets by which the user 210 may access and select funding from benefit accounts (i.e., not from payment card accounts).
- the benefits accessible via the user's digital wallet at VAS WSP computer 1302may include one or more of the following: (a) coupons, (b) loyalty/rewards points, (c) medical insurance benefits, (d) pension and/or social insurance and/or social welfare benefits, (e) casualty insurance benefits, etc.
- FIG. 13also shows two main functional blocks of the VAS WSP computer 1302 , namely a split amount engine 1306 and a VAS wallet services component 1308 .
- the split amount engine 1306may perform logic required to split payment in the payment system 200 a between benefit funding and payment card account funding.
- the VAS wallet services component 1308may maintain the VAS/benefit funds digital wallets for users of the payment system 200 a.
- the benefits system operator computer 1310may be connected to the VAS WSP computer 1302 , at least from time to time, via a communication channel 1312 ; in some embodiments, a one-to-one connection may be provided between the benefits system operator computer 1310 and the VAS WSP computer 1302 as part of a dedicated financial services communications network.
- the VAS WSP computer 1302 , the benefits system operator computer 1310 and the PSP/acquirer computer 206may all be constituted by conventional computer hardware, such as that described above in connection with the description of the WSP computer 208 hardware shown in FIG. 5 .
- the VAS WSP computer 1302 , the benefits system operator computer 1310 and the PSP/acquirer computer 206may be programmed to provide system functionality as described herein.
- the VAS WSP computer 1302may store (in a storage medium such as those referred to above in connection with FIG. 5 ) and may be programmed/controlled by one or more software programs so that the VAS WSP computer 1302 may provide functionality as described herein.
- the wallet services provided by the VAS WSP computer 1302may entail maintaining one or more digital wallets per user/subscriber for the services of the VAS WSP.
- the user 210may have stored for his/her benefit in the VAS WSP computer 1302 one or more of the following: (a) a rewards wallet, for loyalty points, coupons, promotional payments, etc.; (b) a medical insurance wallet for medical, dental, long term care, and other like benefits; (c) a casualty insurance wallet; and (d) a social benefits wallet (e.g., for social welfare payments, government pension plan benefits, etc.).
- FIG. 14is a high level flow chart that illustrates a transaction process that may be performed in the payment system 200 a in accordance with aspects of the present invention.
- the process of FIG. 14may, for example, be triggered by a signal that indicates that the current transaction is eligible for split payment between two or more of the user's digital wallets, such as a benefits account wallet and a payment card account wallet.
- the signalmay be a code provided by the merchant POI terminal 204 and/or may be the identifier for the merchant that operates the merchant POI terminal 204 .
- the signalmay identify the merchant as a medical services provider, for which the charges are eligible for partial payment via a medical insurance benefit.
- the signalmay be received to trigger the process of FIG. 14 at the PSP/acquirer computer 206 a.
- the PSP/acquirer computer 206 aselects an appropriate benefits wallet or other digital wallet for the user 210 in response to the triggering signal referred to above.
- the PSP/acquirer computer 206 amay select the user's digital wallet that is appropriate in view of the triggering signal.
- the triggering signalmay indicate to the PSP/acquirer computer 206 a that the merchant is a service provider whose services are eligible for benefits payments.
- the PSP/acquirer computer 206 amay also look up the user (via the URI for the server function in the payment-enabled mobile device 202 ) to determine that the user is eligible for benefits and has a wallet service provider for the benefits.)
- the PSP/acquirer computer 206 amay then contact the wallet service provider that maintains the selected wallet, assumed in this case to be the operator of the VAS WSP computer 1302 .
- the PSP/acquirer computer 206 atransmits a request to the VAS WSP computer 1302 to download wallet form data for the selected wallet.
- the process of FIG. 14advances from block 1402 to block 1404 .
- the user 210is permitted to select a funding account from the selected digital wallet.
- corresponding wallet form dataprovided by the VAS WSP computer 1302 is transmitted to the payment-enabled mobile device 202 .
- the wallet form datamay be received by the WSP computer 208 directly or indirectly from the VAS WSP computer 1302 and then relayed on from the WSP computer 208 to the payment-enabled mobile device 202 .
- the VAS WSP computer 1302transmits the wallet form data to the PSP/acquirer computer 206 a, which relays the wallet form data to the WSP computer 208 , along with the URI for the server function in the payment-enabled mobile device 202 .
- the WSP computer 208may then form a secure communication channel with the payment-enabled mobile device 202 , in the manner described above in connection with block 120 of FIG. 11 .)
- the wallet form datawhen received by the payment-enabled mobile device 202 , provides to the user 210 at least one funding account option that is available to the user 210 and represented in the digital wallet selected at block 1402 .
- the selected digital walletmay contain only one funding account option (e.g., a medical insurance benefits account), and the user selection of that funding account option may occur simply by the user 210 indicating that he/she wishes the funding account in question be applied to a first portion of the transaction amount that is to be funded.
- the selected digital walletmay contain two or more funding account options (e.g., various loyalty points, coupons or promotion accounts available to the user 210 ) and the user 210 may provide input via the payment-enabled mobile device 202 to indicate the user's selection of one of the funding account options.
- the resulting account selection signalindicative of the user's selection of an account (or confirmation that an account is to be used, if it is the only option in the selected digital wallet) may be received by one or more of the WSP computer 208 , the PSP/acquirer computer 206 a and the VAS WSP computer 1302 .
- the account selection signalmay be transmitted from the payment-enabled mobile device 202 via the secure communication channel 222 to the WSP computer 208 .
- the WSP computer 208may relay the account selection signal to the PSP/acquirer computer 206 a, which in turn transmits the account selection signal to the VAS WSP computer 1302 .
- FIG. 15schematically illustrates one example process by which the payment split may take place. (This process may be performed, for example, by the VAS WSP computer 1302 .)
- block 1502represents a benefit computation method that may be applicable to the funding account selected at 1404 .
- the benefit computation method block 1502may receive as an input (as indicated at 1504 ) the total amount that is to be paid for the current transaction (i.e., the transaction amount).
- the output (reference numeral 1506 ) from the benefit computation method block 1502may be the maximum amount that the transaction is eligible to receive in funding from the selected funding account.
- an input 1510may be received to indicate the user's preference that less than the entire available benefit be drawn from the selected funding account. (That is, the process of FIG.
- the payment-enabled mobile device 202may receive input from the user 210 to indicate that the user elects to receive the maximum benefit available, or to indicate a smaller amount of the benefit that the user 210 opts to apply to the current transaction.
- the communications to support the user inputmay run between the VAS WSP computer 1302 and the payment-enabled mobile device 202 , via the PSP/acquirer computer 206 a and the WSP computer 208 .)
- the output 1512 from the node 1508is the smaller amount of the inputs 1506 and 1510 , and becomes the amount to be funded for the current transaction from the selected funding account.
- the feedback path indicated at 1514represents updating (reduction) of the available balance in the selected funding account.
- Block 1408 in FIG. 14represents the partial funding of the transaction amount, by the amount output from node 1508 in FIG. 15 , from the funding account selected at block 1404 .
- block 1410Following block 1408 in FIG. 14 is block 1410 .
- another one of the user's digital walletsmay be selected by the PSP/acquirer computer 206 a.
- the PSP/acquirer computer 206 amay next select the user's digital wallet maintained at the WSP computer 208 .
- the process of FIG. 14advances to block 1412 .
- the user 210is permitted to select a funding account from the second digital wallet that was selected.
- wallet form datathat corresponds to the second selected digital wallet is transmitted to the payment-enabled mobile device 202 .
- the latter wallet form datawhen received by the payment-enabled mobile device 202 , provides to the user 210 at least one, and possibly two or more, funding account options that are available to the user and are represented by the second selected digital wallet (i.e., the digital wallet selected at block 1410 ).
- the user interface of the payment-enabled mobile device 202may present those options to the user 210 , and may receive input from the user 210 to indicate the user's selection of an account from among those options.
- the resulting account selection signalincluding data indicative of the user's selection of the latter account, may be received by one or more of the WSP computer 208 , the PSP/acquirer computer 206 a and the VAS WSP computer 1302 .
- the balance of the operation corresponding to block 1412may include operations such as those described above in connection with blocks 1130 , 1132 , 1134 , 1136 and 1138 in FIG. 11B , resulting in funding of the balance of the transaction amount (block 1414 , FIG. 14 ) from a payment card account selected by the user 210 at block 1412 .
- the PSP/acquirer computer 206 ahandled selection of a first one of the user's digital wallets and thereafter a second one of the user's digital wallets.
- another entity in the payment system 200 amay perform one or both of the wallet selections.
- the user 210may make one or both of the wallet selections, possibly with guidance from the PSP/acquirer computer 206 a via a communication path running through the WSP computer 208 to the payment-enabled mobile device 202 .
- FIG. 16schematically illustrates a biometric-based cardholder verification method (CVM) that may be performed according to aspects of the invention in the payment systems 200 or 200 a of FIG. 2 or FIG. 13 .
- CVMbiometric-based cardholder verification method
- components to the left of dividing line 1602may be part of the payment-enabled mobile device 202 shown in FIG. 2
- components to the right of the dividing line 1602may be part of the WSP computer 208
- the payment-enabled mobile device 202may serve as a proving device
- WSP computer 208may serve as a verifying device, for the biometric CVM operation.
- a biometric sensor 1604 and a data acquisition unit 1606may be constituted by the microphone 320 ( FIG.
- the payment-enabled mobile device 202may perform the relatively limited function of acquiring the raw biometric data and sending it to the WSP computer 208 via the communication channel 222 .
- the payment-enabled mobile device 202need not store any biometric reference data, and accordingly need not be personalized for biometric CVM. This may tend to reduce or eliminate the need for a large permanent memory in the payment-enabled mobile device 202 .
- the cryptographically secured communication channel 222is available between the payment-enabled mobile device 202 and the WSP computer 208 to allow for transmission of the raw biometric data from the former device to the latter device.
- the reference data for the biometric CVMmay be stored at the WSP computer 208 , as indicated by block 1608 in FIG. 16 .
- Processing of the raw biometric data received by the WSP computer 208 from the payment-enabled mobile device 202may be performed by functional blocks such as feature extraction block 1610 , image signal processing block 1612 and comparison/matching block 1614 .
- a decision function 1616 on the WSP computer sidemay determine whether the CVM is valid based on output from the comparison/matching block 1614 and based on previously stored decision parameters indicated at 1618 in FIG. 16 .
- the output from the decision function 1616may be authorization of the transaction, as indicated at 1620 .
- biometric data captured by the payment-enabled mobile device 202is not analyzed at the payment-enabled mobile device 202 , but rather un-analyzed biometric data is transmitted from the payment-enabled mobile device 202 to be received by the WSP computer 208 , and to be analyzed and verified at the WSP computer 208 .
- This arrangementmay result in a high degree of flexibility in terms of permitting various different types of biometric CVM to be employed for different accounts in the user's digital wallet, and/or for new types of biometric CVM to be introduced into the operations of the payment system 200 a.
- the flexibility available for applying different types of biometric CVMmay also be utilized to match the type of biometric CVM capability supported by the particular mobile device to be used in the transaction.
- the WSP computer 208is highly secure, it is quite unlikely that the user's biometric reference data would be compromised, as could more easily occur if the biometric reference data were present in the payment-enabled mobile device 202 and the latter were lost or stolen.
- FIG. 17is a block diagram that illustrates aspects of the biometric-based CVM of FIG. 16 .
- FIG. 17may aid in illustrating how a biometric-based CVM as in FIG. 16 may be integrated into the transaction process described above primarily with reference to FIGS. 2 , 11 A and 11 B.
- FIG. 17may be considered to represent a subset of the apparatus of FIG. 2 , as modified to accommodate a biometric CVM process as described above in connection with FIG. 16 .
- FIG. 17shows the following features shown in and discussed above in connection with FIG. 2 —the payment-enabled mobile device 202 , the WSP computer 208 , and the communication channel 222 . Further, as part of the payment-enabled mobile device 202 , FIG. 17 also shows the following software elements that were discussed above in connection with FIG. 7 —the consumer device server function 702 and the wallet selection application 708 . Still further, and also as part of the payment-enabled mobile device 202 , FIG. 17 shows the components 1604 , 1606 (biometric sensor and biometric data acquisition) referred to in the above discussion of FIG. 16 .
- biometric verification block 1702 in FIG. 17which is shown as part of the WSP computer 208 , represents the functional blocks shown in FIG. 16 to the right of dividing line 1602 .
- the transaction concentrator block 214As part of the WSP computer 208 is the transaction concentrator block 214 referred to above in connection with FIG. 2 .
- the transaction concentrator block 214In the apparatus as illustrated in FIG. 17 , the transaction concentrator block 214 is shown as being in communication with the biometric verification block 1702 of the WSP computer 208 .
- the user 210may perform account selection via the wallet selection application 708 , and may present his/her biometric feature to the biometric sensor 1604 .
- the biometric sensor 1604After acquisition of the user's biometric data, the latter is transmitted—together with a biometric technology identifier (e.g., fingerprint, voice recognition, finger vein, retina, facial geometry, etc.) to the wallet selection application 708 .
- a biometric technology identifiere.g., fingerprint, voice recognition, finger vein, retina, facial geometry, etc.
- the wallet selection application 708sends them via the consumer device server function 702 and the secure channel 222 to the WSP computer 208 .
- the WSP computer 208chooses the appropriate biometric data processing algorithm for the raw biometric data and the appropriate stored biometric reference data repository.
- the particular set of biometric reference data for the user in questionmay be retrieved based on the URI for the consumer device server function 702 in the payment-enabled mobile device 202 .
- the biometric verification block 1702then applies the biometric verification process illustrated in FIG. 16 to the raw data. Assuming the result of the process is, “valid”, then the transaction concentrator block 214 may trigger the authorization request(s) as referred to above in connection with block 1130 of FIG. 11B .
- FIG. 18is a block diagram that illustrates an alternative CVM that may be performed according to aspects of the invention.
- FIG. 18may aid in illustrating a CVM that may be particularly suitable for use in remote (e-commerce) transactions, although it may also be useful for an in-store transaction that is not consummated via a local POS terminal
- FIG. 18shows a modified version (reference numeral 208 a ) of the WSP computer referred to above.
- the WSP computer 208 amay include an interactive voice response (IVR) unit 1802 , a voice recognition unit 1804 , a wallet partition unit 1806 and a payment gateway function 1808 .
- the WSP computer 208 amay interact with a cell-phone 1810 via the IVR unit 1802 and the voice recognition unit 1804 .
- the cell-phone 1810may or may not be a smartphone, and may or may not be a payment-enabled mobile device (such as described hereinabove).
- the WSP computer 208 amay also interact with a conventional browser 1812 via the payment gateway function 1808 .
- the browser 1812may run on a conventional personal computer, tablet, smartphone or the like, which are not separately shown.
- the browser 1812may receive input from the same individual (not shown) who owns and uses the cell-phone 1810 .
- the browsermay be configured so that it “knows” the telephone number for the cell-phone 1810 .
- the browser 1812may retrieve an ordering page from the merchant e-commerce site (not shown), and may allow the user to select one or more items for purchase, as indicated via the browser to the e-commerce site.
- the e-commerce sitemay then compute the amount due for the transaction and submit the transaction amount to the browser.
- the browsermay then send the transaction amount, the cell-phone telephone number and possibly other transaction information as well to the payment gateway function 1808 of the WSP computer 208 a.
- the payment gateway function 1808retrieves the digital wallet for the user from the wallet partition unit 1806 , and from the user's digital wallet the WSP computer 208 a generates wallet form data, which is supplied to the IVR unit 1802 together with the cell-phone telephone number.
- the IVR unit 1802calls the cell-phone 1810 and audibly prompts the user to make an account selection based on the wallet form data.
- the userresponds by spoken utterance into the cell-phone 1810 to indicate his/her payment card account selection.
- the voice utteranceis sent from the cell-phone 1810 to the voice recognition unit 1804 of the WSP computer 208 a.
- the voice recognition unitperforms both of the following on the basis of the voice utterance—(a) identifying the user based on a voice sample reference previously stored in a reference data repository on the WSP computer 208 a (where the reference was associated with the cell-phone telephone number)—i.e., in effect CVM; and (b) detecting the user's selection of a payment card account from the user's digital wallet based on speech content recognition as applied to the voice utterance received from the cell-phone 1810 . If the CVM is found “valid”, then the account selection is passed on to a wallet unit in the WSP computer 208 a.
- the wallet unitthen triggers an authorization request for the selected payment card account (or more than one authorization request, if the user elected to split payment among two or more of his/her payment card accounts).
- the WSP computer 208 athen receives an authorization response from the payment card account issuer (or more than one, if more than one account is being used). The result of the authorization response is provided to the payment gateway function 1808 of the WSP computer 208 a. If the transaction is approved, the payment gateway provides an acknowledgment message accordingly to the merchant e-commerce site, such that the transaction is successfully concluded.
- the device 202may be physically constituted by smartphone hardware.
- the device 202may be an IC card of the type that includes a display and keyboard.
- the device 202may communicate with the WSP computer 202 via the POI terminal
- the IC cardneed not have a keyboard or display.
- the IC cardwhich may be a contactless card or a contact card, may be in communication with the POI terminal, which may provide a user interface for the card and for selection of wallet account(s).
- the term “computer”should be understood to encompass a single computer or two or more computers in communication with each other.
- processorshould be understood to encompass a single processor or two or more processors in communication with each other.
- memoryshould be understood to encompass a single memory or storage device or two or more memories or storage devices.
- the term “payment card system account”includes a credit card account or a deposit account that the account holder may access using a debit card.
- the terms “payment card system account” and “payment card account”are used interchangeably herein.
- the term “payment card account number”includes a number that identifies a payment card system account or a number carried by a payment card, or a number that is used to route a transaction in a payment system that handles debit card and/or credit card transactions.
- the term “payment card”includes a credit card or a debit card.
- the term “payment card system”refers to a system for handling purchase transactions and related transactions.
- An example of such a systemis the one operated by MasterCard International Incorporated, the assignee of the present disclosure.
- the term “payment card system”may be limited to systems in which member financial institutions issue payment card accounts to individuals, businesses and/or other organizations.
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Engineering & Computer Science (AREA)
- Finance (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- Theoretical Computer Science (AREA)
- Strategic Management (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computer Security & Cryptography (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Cash Registers Or Receiving Machines (AREA)
Abstract
Description
- This application claims the benefit of U.S. Provisional Patent Application No. 61/948,197 filed on Mar. 5, 2014, the contents of which are hereby incorporated by reference for all purposes.
- Payment cards such as credit cards and debit cards are in widespread use. In some environments, payment cards in the form of magnetic stripe cards prevail in terms of popularity. With mag stripe cards, the payment card account number may be read from the card at the point of sale by a magnetic stripe reader, and then submitted with a transaction authorization request to the account issuer via the payment network.
- In other environments, it is more common to use so-called “contactless” payment cards. With contactless payment cards, the payment card account number is stored in an integrated circuit (IC) within the card, and is read by short-range radio communication between the card and the contactless reader component of a point of sale (POS) terminal With enhancements that have occurred to mobile phones, including smartphones, the capability has been added to perform NFC (near field communication) communications to enable so-called “contactless” payment cards to be digitized into these consumer devices. These mobile devices utilize a secure element (SE) to store the payment card account number and associated data, keys and Personal Identification Number (PIN) to enable the consumer to perform a payment transaction using the NFC short-range radio communications provided by the mobile device and the contactless reader component of a POS terminal.
- In still other environments, so-called “contact” payment IC cards are placed in point of sale readers that can read the payment card account number from the card IC via direct conductive contacts provided on the face of the card.
- As recent events have underlined, security of payment card account numbers can be a significant issue. Large scale data breaches at the merchant level have occurred and have compromised many cardholders' payment card account numbers. Efforts are ongoing to reduce the risk of theft and misuse of payment card account numbers.
- Features and advantages of some embodiments of the present invention, and the manner in which the same are accomplished, will become more readily apparent upon consideration of the following detailed description of the invention taken in conjunction with the accompanying drawings, which illustrate preferred and exemplary embodiments and which are not necessarily drawn to scale, wherein:
FIG. 1 is a block diagram that illustrates a conventional payment system.FIG. 2 is a block diagram that illustrates a payment system provided in accordance with aspects of the present invention.FIG. 3 is a block diagram that illustrates a payment-enabled mobile telephone provided in accordance with aspects of the present invention and that may be used in connection with the system ofFIG. 2 .FIG. 4 is a block diagram that illustrates a point of sale (POS) terminal provided in accordance with aspects of the present invention and that may be part of the system ofFIG. 2 .FIG. 5 is a block diagram that illustrates a computer system that may be operated by a wallet service provider as part of the system ofFIG. 2 and in accordance with aspects of the present invention.FIG. 6 schematically represents enrollment of a payment card account with a wallet service provider that participates in the system ofFIG. 2 .FIG. 7 schematically illustrates software and functional aspects of the payment-enabled mobile telephone ofFIG. 3 .FIG. 8 illustrates additional details of software aspects of the payment-enabled mobile telephone ofFIG. 3 .FIG. 9 illustrates still further details of software aspects of the payment-enabled mobile telephone ofFIG. 3 .FIG. 10 schematically illustrates software aspects of the POS terminal ofFIG. 4 .FIGS. 11A and 11B together form a flow chart that illustrates a transaction process that may be performed in the system ofFIG. 2 in accordance with aspects of the present invention.FIG. 12 schematically illustrates a clearing process that may be performed in the system ofFIG. 2 in accordance with aspects of the present invention.FIG. 13 is a block diagram that illustrates an alternative embodiment of the payment system ofFIG. 2 .FIG. 14 is a high level flow chart that illustrates a transaction process that may be performed in the system ofFIG. 13 in accordance with aspects of the present invention.FIG. 15 schematically illustrates some details of the process ofFIG. 14 .FIG. 16 schematically illustrates a biometric-based cardholder verification method (CVM) that may be performed according to aspects of the invention in the system ofFIG. 2 orFIG. 13 .FIG. 17 is a block diagram that illustrates aspects of the biometric-based CVM ofFIG. 16 .FIG. 18 is a block diagram that illustrates an alternative CVM that may be performed according to aspects of the invention.- In general, and for the purpose of introducing concepts of embodiments of the present invention, a payment network transaction is consummated at the point of sale without the POS terminal receiving or reading a payment card account number. The consumer offers a payment-enabled mobile device as a credential for the transaction. The payment card account number need not be stored in the mobile device, but rather has been enrolled in a digital wallet maintained for the consumer by a wallet service provider (WSP) that is located remotely from the point of sale.
- The POS terminal and the payment-enabled mobile device exchange data to initiate the payment transaction. The data provided from the payment-enabled mobile device to the POS terminal may include only (a) data to identify the consumer's WSP, and (b) an internet address for a server function that is hosted by the payment-enabled mobile device. The data provided from the POS terminal to the payment-enabled mobile device may relate to the current purchase transaction (e.g., transaction amount) and to the transaction context (e.g., data to identify the merchant that operates the POS terminal and the location of the purchase transaction).
- The exchange of data between the POS terminal and the payment-enabled mobile device may be by any convenient mode, such as NFC.
- Using the identity of the WSP as received from the payment-enabled mobile device, the POS terminal may route a message to the WSP, where the message contains the transaction data, the transaction context data and the internet address for the mobile device server function. The WSP may then use the internet address to set up a cryptographically secured communication channel with the mobile device via the server function hosted by the mobile device. This may involve mutual authentication of the WSP's computer and the mobile device server function.
- The WSP's computer may transmit wallet form data to the mobile device via the secure channel to permit the consumer to select a payment card account from among those for which data is stored in the digital wallet maintained for the consumer by the WSP. The mobile device server function may send data to the WSP's computer to serve as an authentication token for the transaction, including data that indicates the consumer's selection of a payment card account to be used for the transaction, and data by which the WSP can confirm the validity of the transaction data and transaction context data provided to the WSP from the POS terminal.
- The WSP may then act much like an acquirer in a conventional payment card system, by routing an authorization request for the transaction via the payment network to the issuer of the selected payment card account. Upon receiving a favorable authorization response, the WSP may route a confirmation to the POS terminal to indicate that a valid payment for the purchase transaction has been secured. The purchase transaction is then complete at the point of sale.
- By way of background, and to more sharply illustrate differences between conventional practices and the teachings of the present disclosure, a conventional payment system will first be briefly described.
FIG. 1 is a block diagram that illustrates aconventional payment system 100. - The
system 100 includes a conventional payment card/device102 (which may alternatively be a conventional payment-enabled mobile device that stores a payment card account number and runs a payment applet; other form factors for the payment device, such as a fob, are also possible). Thesystem 100 further includes areader component 104 associated with aPOS terminal 106. In some known manner (depending on the type of the payment card/device102) thereader component 104 is capable of reading the payment card account number and other information from the payment card/device 102. - The
reader component 104 and thePOS terminal 106 may be located at the premises of a retail store and operated by a sales associate of the retailer for the purpose of processing retail transactions. The payment card/device 102 is shown inFIG. 1 to be interacting with theproximity reader component 104 and thePOS terminal 106 for the purpose of executing such a transaction. - A
computer 108 operated by an acquirer (acquiring financial institution) is also shown as part of thesystem 100 inFIG. 1 . Theacquirer computer 108 may operate in a conventional manner to receive an authorization request for the transaction from thePOS terminal 106. Theacquirer computer 108 may route the authorization request via apayment network 110 to theserver computer 112 operated by the issuer of a payment card account that is associated with the payment card/device 102. As is also well known, the authorization response generated by the payment cardissuer server computer 112 may be routed back to thePOS terminal 106 via thepayment network 110 and theacquirer computer 108. - One well known example of a payment network is referred to as the “Banknet” system, and is operated by MasterCard International Incorporated, which is the assignee hereof.
- The payment card
issuer server computer 112 may be operated by or on behalf of a financial institution (“FI”) that issues payment card accounts to individual users. For example, the payment cardissuer server computer 112 may perform such functions as (a) receiving and responding to requests for authorization of payment card account transactions to be charged to payment card accounts issued by the FI; and (b) tracking and storing transactions and maintaining account records. - The components of the
system 100 as depicted inFIG. 1 are only those that are needed for processing a single transaction. A typical payment system may process many purchase transactions (including simultaneous transactions) and may include a considerable number of payment card issuers and their computers, a considerable number of acquirers and their computers, and numerous merchants and their POS terminals and associated proximity reader components. The system may also include a very large number of payment card account holders, who carry payment cards or other devices for initiating payment transactions by presenting an associated payment card account number to the reader component of a POS terminal FIG. 2 is a block diagram that illustrates apayment system 200 provided in accordance with aspects of the present invention. (As was the case inFIG. 1 , the payment system is depicted inFIG. 2 only in terms of components needed for a single transaction; in practice, and as will be discussed below, thepayment system 200 may include many more instances of at least some components.)- As illustrated in
FIG. 2 , thepayment system 200 includes a payment-enabledmobile device 202 provided in accordance with aspects of the present invention. The payment-enabledmobile device 202 may take the form of a conventional-appearing smartphone, tablet computer, or the like. However, as will be seen from subsequent discussion, the software configuration of the payment-enabledmobile device 202 may be very different from previously proposed payment-enabled devices. In at least some embodiments, the payment-enabledmobile device 202 may not store any payment card account information, and may lack the payment applets that have heretofore typically been proposed to incorporate contactless payment capabilities into a mobile phone. Further details of the payment-enabledmobile device 202 will be described below, particularly in the ensuing sections of this description relating toFIGS. 3 ,7,8 and9, and in portions ofFIGS. 11A and 11B . - Also included in the
payment system 200 is a merchant point-of-interaction (POI)terminal 204, which may be a POS terminal as configured in accordance with aspects of the present invention. Themerchant POI terminal 204 may, for example, be operated by a merchant (or merchant employee) at a retail store, and may interact with the payment-enabledmobile device 202 in a manner described below (e.g., by a short-range mode of data communication). Further details of themerchant POI terminal 204 will be described subsequently, including in the sections of the description relating toFIGS. 4 and 10 . - Another feature of the
payment system 200 is acomputer 206 operated by a payment system acquirer (or a payment services provider—“PSP”) on behalf of an acquirer. As is customary, the acquirer may be a financial institution with which the merchant maintains a banking relationship. However, as will be seen from subsequent discussion, the roles of the PSP/acquirer computer 206 in the payment system may be quite different from the roles typically performed by the acquirer in a conventional payment system such as that illustrated inFIG. 1 . A portion of the ensuing discussion will describe actions taken by the PSP/acquirer, and thecomputer 206, in connection with a typical payment transaction as performed in thepayment system 200. - A central aspect and component of the
payment system 200 is acomputer 208 operated by or on behalf of a wallet service provider (WSP). It is assumed that the WSP in question maintains a digital wallet for an individual user depicted at210 as the user of the payment-enabledmobile device 202. Two main functional blocks of theWSP computer 208 are shown inFIG. 2 , namely a wallet services block212 and atransaction concentrator block 214. The wallet services block212 enrolls consumers for digital wallet services, and allows consumers' payment card accounts to be represented in digital form in the consumers' digital wallets to be maintained in the wallet services block212. The wallet services block212 also serves as a repository and as a resource for digital wallet and payment card account information to be used—as will be seen—in payment transactions that are performed in accordance with aspects of the present invention. - The
transaction concentrator block 214 handles individual payment transactions in accordance with aspects of the present invention and as described in detail below. - Also shown in
FIG. 2 , and forming part of thepayment system 200, are thepayment network 110 and theissuer server computer 112 which were mentioned in the above description ofFIG. 1 . Operation of thepayment system 200 does not necessarily require that thepayment network 110 and theissuer server computer 112 be operated in other than a conventional manner, and thus thepayment network 110 and theissuer server computer 112 may be constituted in a known manner; it should be noted though that in effect, and as will be seen, theWSP computer 208 may serve (among other roles) in the place of theacquirer computer 108 that was depicted inFIG. 1 . Thus, and as described below, thepayment network 110 may receive authorization requests from theWSP computer 208 as if (from the point of view of the payment network110) theWSP computer 208 were an acquirer computer. FIG. 2 also showscommunication channels payment system 200. Further information about these communication channels will be provided below. It should also be noted that communication channel224 (between theWSP computer 208 and the payment network110) and communication channel226 (between thepayment network 110 and the issuer server computer112) may be provided in a conventional manner.- A detailed description of operation of the
payment system 200 will be provided below, particularly with reference toFIGS. 11A and 11B . - As noted above, the block diagram representation of the
payment system 200 as shown inFIG. 2 represents only system components required for a single transaction. In a practical embodiment of thepayment system 200, there may be, for example, more than one payment network that participates in the system. Also, there may be a number of WSPs that participate rather than just one. - Moreover, as will be understood from the above description of a conventional payment system, the
payment system 200 may process many transactions, including simultaneous transactions. A considerable number of payment card account issuers may be included in thepayment system 200, and thepayment system 200 may also include a considerable number of acquirers/PSPs and their computers. In addition, thepayment system 200 may include a large number of merchant POI devices (in-store and/or e-commerce host computers), operated by a large number of merchants. Also, there may be a very large number of payment-enabled mobile devices as described herein (each including the above-mentioned server function which has a unique URI), and owned/used by numerous individual users. The users are holders of payment card accounts issued by issuing financial institutions and have enrolled with one or more WSPs, which maintain digital wallets for the users. FIG. 3 is a block diagram that illustrates an example embodiment of the payment-enabledmobile device 202 shown inFIG. 2 and provided in accordance with aspects of the present invention. The payment-enabledmobile device 202 may be conventional in its hardware aspects. For example, the payment-enabledmobile device 202 may be a smartphone, and may resemble, in some or all of its hardware aspects and many of its functions, a conventional “iPhone” marketed by Apple Inc., or one of the numerous smartphone models that run the “Android” operating system. Alternatively, the payment-enabledmobile device 202 may be a tablet computer, such as the “iPad” marketed by Apple Inc. The ensuing description of the payment-enabledmobile device 202 is based on the assumption that it is embodied as a smartphone; those who are skilled in the art will readily understand from the following description, and from following descriptions of software aspects of the payment-enabledmobile device 202, how to embody the payment-enabledmobile device 202 as a tablet computer or other device apart from a smartphone.- The payment-enabled
mobile device 202 may include a conventional housing (indicated by dashedline 302 inFIG. 3 ) that contains and/or supports the other components of the payment-enabledmobile device 202. Thehousing 302 may be shaped and sized to be held in a user's hand, and may for example exhibit the type of form factor that is common with the current generation of smartphones. - The payment-enabled
mobile device 202 further includesconventional control circuitry 304, for controlling over-all operation of the payment-enabledmobile device 202. For example, thecontrol circuitry 304 may include a conventional processor of the type designed to be the “brains” of a smartphone. - Other components of the payment-enabled
mobile device 202, which are in communication with and/or controlled by thecontrol circuitry 304, include: (a) one or more memory devices306 (e.g., program and working memory, etc.); (b) a conventional SIM (subscriber identification module)card 308; (c) aconventional touchscreen 312 which serves as the primary input/output device for the payment-enabledmobile device 202, and which thus receives input information from the user and displays output information to the user. As is the case with many models of smartphones, in some embodiments the payment-enabledmobile device 202 may also include a few physically-actuatable switches/controls (not shown), such as an on/off/reset switch, a menu button, a “back” button, a volume control switch, etc. It may also be the case that the payment-enabledmobile device 202 includes a conventional digital camera (as is the case with many smartphones), which is not shown. - The payment-enabled
mobile device 202 also includes conventional receive/transmitcircuitry 316 that is also in communication with and/or controlled by thecontrol circuitry 304. The receive/transmitcircuitry 316 is coupled to anantenna 318 and provides the communication channel(s) by which the payment-enabledmobile device 202 communicates via the mobile telephone communication network (not shown). The receive/transmitcircuitry 316 may operate both to receive and transmit voice signals, in addition to performing data communication functions. As is known to those who are skilled in the art, such data communication may be via HTTP (HyperText Transfer Protocol) or other communication protocol suitable for carrying out data communication over the internet. - The payment-enabled
mobile device 202 further includes aconventional microphone 320, coupled to the receive/transmitcircuitry 316. Of course, themicrophone 320 is for receiving voice input from the user. In addition, aloudspeaker 322 is included to provide sound output to the user, and is coupled to the receive/transmitcircuitry 316. - The receive/transmit
circuitry 316 may operate in a conventional fashion to transmit, via theantenna 318, voice signals generated by themicrophone 320, and to reproduce, via theloudspeaker 322, voice signals received via theantenna 318. The receive/transmitcircuitry 316 may also handle transmission and reception of text messages and other data communications via theantenna 318. - The payment-enabled
mobile device 202 may also includecircuitry 324 that is partly or wholly dedicated to implementing NFC communications functionality of the payment-enabledmobile device 202. The payment-enabledmobile device 202 may further include aloop antenna 326, coupled to theNFC circuitry 324. In some embodiments, theNFC circuitry 324 may partially overlap with thecontrol circuitry 304 for the payment-enabledmobile device 202. Moreover, theNFC circuitry 324 is associated with, and may also overlap with, asecure element 328 that is part of the payment-enabledmobile device 202 and is contained within thehousing 302, or the NFC circuitry could be omitted in embodiments that do not utilize NFC. The term “secure element” is well known to those who are skilled in the art, and typically refers to a device that may include a small processor and volatile and nonvolatile memory (not separately shown) that are secured from tampering and/or reprogramming by suitable measures. In some embodiments, thesecure element 328 may be provided as part of theSIM card 308. In other embodiments, thesecure element 328 may be constituted by an integrated circuit card separate from theSIM card 308 but possibly having the same form factor as theSIM card 308. In some embodiments of the payment-enabledmobile device 202, thesecure element 328 may be conventional in its hardware aspects but may be programmed in accordance with aspects of the present invention in a manner to be described below. (It should be noted that the term “secure element” is not intended to be limited to devices that are IC-based, but rather may also include any secure execution environment in a mobile device, and may include software based secure execution environments running on the main mobile device processor.) - It should also be understood that the payment-enabled
mobile device 202 may be operable as a conventional mobile telephone for communication—both voice and data—over a conventional mobile telecommunications network, which is not depicted in the drawing. Thus, the payment-enabledmobile device 202 may be in communication from time to time in a conventional manner with a mobile network operator (“MNO”—also not shown). For example, an over-the air communication channel (of which an example iscommunication channel 222 inFIG. 2 , as discussed further below) may be established between the payment-enabledmobile device 202 and a remote computer (e.g., the WSP computer208). - Later sections of this disclosure, including those related to
FIGS. 7-9 , will discuss software aspects of the payment-enabledmobile device 202, as provided in accordance with aspects of the present invention. FIG. 4 is a block diagram that illustrates themerchant POI terminal 204 shown inFIG. 2 and provided in accordance with aspects of the present invention; as noted above, themerchant POI terminal 204 may be embodied as a POS terminal at a retail store.- In some embodiments, the
merchant POI terminal 204 may be largely or entirely conventional in its hardware aspects (with the possible exception of cost reductions that may be facilitated by teachings of this disclosure, as described below). Nevertheless, themerchant POI terminal 204 may be programmed in accordance with aspects of the present disclosure to provide functionality as described herein. In addition to the below description of functional process steps performed by themerchant POI terminal 204 as part of a typical purchase transaction (e.g., in connection with FIGS.11A and11B—see below), there will also be discussion below of some software aspects of themerchant POI terminal 204 in connection withFIG. 10 . For now, however, a brief description of hardware aspects of themerchant POI terminal 204 will follow, with continued reference toFIG. 4 . - The
merchant POI terminal 204 may include a processing element (or elements) such as theprocessor 402 shown inFIG. 4 . Theprocessor 402 may, for example, be a conventional microprocessor, and may operate to control the overall functioning of themerchant POI terminal 204. - The
merchant POI terminal 204 may also include conventional peripheral components, in communication with and/or controlled by theprocessor 402, such as: (a) akeypad 404 for receiving input from the human operator of the POS terminal; (b) aproduct reader 406 for reading any form of unique product identifier, such as a barcode or RFID, that appears on, or is attached to, products brought to the terminal for purchase; (c) acash drawer 408 for storing cash received from customers; (d) one ormore displays 410 for providing output (e.g., identifying products presented for purchase and their prices, indicating sales tax due, indicating transaction subtotals and totals, etc., providing prompts to the customer and/or to the sales associate); (e) aprinter 412 for printing out sales receipts; and (f) acommunication controller 414 for allowing theprocessor 402, and hence, themerchant POI terminal 204 to engage in communication over data networks with other devices (e.g., the PSP/acquirer computer 206,FIG. 2 ). (In some embodiments, at least one of thedisplays 410 may be a touch screen, so as to provide an input function as well as an output function.) - In addition, the
merchant POI terminal 204 may include one or more memory and/or data storage devices (indicated collectively at416), which may comprise any combination of one or more of a hard disk drive, RAM (random access memory), ROM (read only memory), flash memory, etc. The memory/data storage device(s)416 may store software and/or firmware that programs theprocessor 402 and themerchant POI terminal 204 to perform functionality as described herein. Thus the memory/data storage device(s)416 may be in communication with theprocessor 402. Further, themerchant POI terminal 204 may include one or more housings (not shown) which contain and/or support one or more of the other components shown inFIG. 4 . - In some embodiments, the
merchant POI terminal 204 may depart from the customary hardware configuration of POS terminals, in that it may lack the usual card-reader elements such as a mag stripe reader, a contact IC card reader, a contactless IC card reader, etc. Instead, themerchant POI terminal 204 may include a suitable hardware arrangement to allow for local communications with the payment-enabledmobile device 202, to thereby establish the communication channel indicated at216 inFIG. 2 . - Referring again to
FIG. 4 , it is assumed for this example embodiment of the payment-enabledmobile device 202 that it is configured to communicate via NFC with the payment-enabledmobile device 202 and accordingly themerchant POI terminal 204 includes an NFC module (reference numeral418) for that purpose. TheNFC module 418 is in communication with theprocessor 402. - With the absence of card-reading capability, and also with no need to provide security measures to safeguard PANs (primary account numbers) and other sensitive consumer information (because, as will be seen, such information is never received in the
merchant POI terminal 204 according to the processes contemplated herein), it may be possible to greatly simplify themerchant POI terminal 204 and to reduce it in cost in comparison to widely used models of POS terminals. Nevertheless, alternative embodiments of themerchant POI terminal 204 are also contemplated in which, to accommodate legacy technology, card-reader(s), etc., are included so that themerchant POI terminal 204 may read conventional payment cards in addition to accepting payment via the payment-enabledmobile device 202 as described herein. FIG. 5 is a block diagram that illustrates an example embodiment of theWSP computer 208 as shown inFIG. 2 and provided in accordance with aspects of the present invention.- Referring now to
FIG. 5 , theWSP computer 208 may be conventional in its hardware aspects but may be controlled by software to cause it to function as described herein. For example, theWSP computer 208 may be constituted by conventional server computer hardware. It should be noted however that (as discussed below) theWSP computer 208 may function as a client device in its interactions with a server function present on the payment-enabledmobile device 202. - The
WSP computer 208 may include acomputer processor 500 operatively coupled to acommunication device 501, astorage device 504, aninput device 506 and anoutput device 508. - The
computer processor 500 may be constituted by one or more conventional processors.Processor 500 operates to execute processor-executable steps, contained in program instructions described below, so as to control theWSP computer 208 to provide desired functionality. Communication device 501 may be used to facilitate communication with, for example, other devices (such as one or more computers operated by thepayment network 110, the PSP/acquirer computer 206 and/or computers operated by other acquirers/PSPs, and numerous payment-enabled mobile devices such as thedevice 202 depicted inFIGS. 2 and 3 ). For example (and continuing to refer toFIG. 5 ),communication device 501 may comprise numerous communication ports (not separately shown), to allow theWSP computer 208 to communicate simultaneously with a number of other computers and other devices, including communications as required to simultaneously handle numerous payment transactions.Input device 506 may comprise one or more of any type of peripheral device typically used to input data into a computer. For example, theinput device 506 may include a keyboard and a mouse.Output device 508 may comprise, for example, a display and/or a printer.Storage device 504 may comprise any appropriate information storage device, including combinations of magnetic storage devices (e.g., hard disk drives), optical storage devices such as CDs and/or DVDs, and/or semiconductor memory devices such as Random Access Memory (RAM) devices and Read Only Memory (ROM) devices, as well as so-called flash memory. Any one or more of such information storage devices may be considered to be a computer-readable storage medium or a computer usable medium or a memory.Storage device 504 stores one or more programs for controllingprocessor 500. The programs comprise program instructions (which may be referred to as computer readable program code means) that contain processor-executable process steps of theWSP computer 208, executed by theprocessor 500 to cause theWSP computer 208 to function as described herein.- The programs may include one or more conventional operating systems (not shown) that control the
processor 500 so as to manage and coordinate activities and sharing of resources in theWSP computer 208, and to serve as a host for application programs (described below) that run on theWSP computer 208. - The programs stored in the
storage device 504 may also include a transactionhandling application program 510 that controls theprocessor 500 to enable theWSP computer 208 to handle requests for payment transactions in a manner described below in connection withFIGS. 11A and 11B . - The
storage device 504 may also store numerous instances ofclient software programs 512 that control theprocessor 500 to enable theWSP computer 208 to play a client role with respect to server functions hosted in numerous payment-enabled mobile devices (as provided in accordance with aspects of the present invention) with which theWSP computer 208 may communicate at a given time. - In addition, the
storage device 504 may store awallet interface program 514 by which theprocessor 500 may access digital wallet data stored in theWSP computer 208 with respect to numerous users of thepayment system 200. - Still further, the
storage device 504 may store anacquirer interface program 516, which provides a data communications interface to the PSP/acquirer computer206 (FIG. 2 ) and to other acquirer computers that present requests for transactions to theWSP computer 208. - Continuing to refer to
FIG. 5 , thestorage device 504 may also store a paymentnetwork interface program 518, which provides a data communications interface to the payment network110 (FIG.2)—and possibly to other payment networks as well—to allow for submission of authorization requests by theWSP computer 208 and receipt of authorization responses. - Again continuing to refer to
FIG. 5 , thestorage device 504 may additionally store a CVM (cardholder verification method)processing program 520, which operates to handle required CVM processing with respect to consumers who access thepayment system 200 via their mobile devices (as will be described further below). - Moreover, the
storage device 504 may store atransaction clearing program 522, which may handle clearing of payment transactions handled via theWSP computer 208. - The
storage device 504 may also store, and theWSP computer 208 may also execute, other programs, which are not shown. For example, such programs may include a reporting application, which may respond to requests from system administrators for reports on the activities performed by theWSP computer 208. The other programs may also include, e.g., one or more data communication programs, device drivers, etc. - The
storage device 504 may also store one ormore databases 524 required for operation of theWSP computer 208. Such databases may include, for example, a database (not separately indicated inFIG. 5 ) for storing data corresponding to digital wallets maintained for consumers/cardholders in theWSP computer 208. - Like the
WSP computer 208, the PSP/acquirer computer 206 may be constituted by conventional computer hardware; thus the PSP/acquirer computer 206 may have the same hardware architecture and aspects as described above in connection with the description of the WSP computer. The computer hardware making up the PSP/acquirer computer 206 may be programmed to cause the PSP/acquirer computer 206 to perform functions such as are described below. FIG. 6 schematically represents enrollment of a payment card account with a wallet service provider (e.g., the operator of WSP208) that participates in thepayment system 200 ofFIG. 2 . InFIG. 6 , the block that represents the WSP is labeled withreference numeral 208 which it shares withWSP computer 208 ofFIGS. 2 and 5 . Each WSP in the system (only one WSP is depicted but there may be a considerable number that participate in the system) has a particular identifier to distinguish the WSP from other WSPs in the system. For example, the WSP service provided by the assignee hereof (MasterCard International Incorporated) is identified as “MasterPass”. A similar service available from Visa Inc. is identified as “V.me”. It is assumed that the wallet services provided byWSP 208 are “financial” in the sense that the accounts stored in the consumers' digital wallets maintained byWSP 208 are financial accounts. Other types of wallet services may also be provided, such as “value added services” (VAS) wallets, as will be described below (for instance, in connection withFIG. 13 ).- A user/
consumer 210 is depicted inFIG. 6 ; this individual—it is assumed—wishes to have one of his/her payment card accounts added to his/herdigital wallet 602 maintained for him/her by theWSP 208. It should be understood that each consumer's digital wallet may exist as a unique entry for the consumer in a database maintained by the WSP/WSP computer 208. The consumer's entry/digital wallet may be identified with a unique identifier for the entry. In some embodiments of the invention, the unique identifier for the consumer's digital wallet may be a Universal Resource Identifier (URI) that has been assigned to a server function hosted on the consumer's mobile device202 (FIG. 2 ). (As is known to those who are skilled in the art, a URI uniquely identifies a point of content in internet space, and thus may serve as an internet address.) It should also be noted that each consumer may be registered with—and hence have a respective digital wallet with—more than one WSP. In each case, for WSPs that participate in thepayment system 200, the consumer's respective digital wallet may be identified by the same identifier across all the WSPs, namely by the just-mentioned URI for the server function hosted on the consumermobile device 202. - Each consumer's digital wallet/
WSP entry 602 may itself be a data repository for storing digitalized payment cards that the consumer has selected for inclusion in his/her digital wallet. The digitalized cards may be issued by the same issuing financial institution or by several different issuers. The digitalized cards may all be branded from the same payment network or from more than one payment network. Inclusion of digitalized cards from a given payment network in theWSP 208's database (i.e., in consumers' digital wallets maintained by WSP208) can occur if theWSP 208 has entered into a relationship with that payment network to allow the WSP to act as a quasi-acquirer with respect to that payment network. Block 604 inFIG. 6 represents one of theuser 210's payment card accounts that the user has elected to have included in his herdigital wallet 602 as adigitalized card 606. The particulardigitalized card 606 may be assigned an easy-to-recognize identifier to distinguish it (for the user) from other digitalized cards (not shown) that are also present in the user'sdigital wallet 602.- For each
digitalized card 606 in the user'sdigital wallet 602, there is a digitalized image of the payment card account stored in theWSP computer 208. The digitalized image consists of the personalization template of the card application (i.e., a software application for digitally implementing the payment card account). The items included in the digitalized image depend on the requirements for wallet based transactions as established by the payment network for which the payment card account was issued. - The
WSP computer 208 implements an engine that emulates the card payment application for thedigitalized card 606. It can be said that thedigitalized card 606 is made up of the digitalized image/personalization template for the particular payment card account plus the WSP engine for the relevant card payment application. As will be seen, theWSP 208 uses thedigitalized payment card 606 to trigger and complete wallet payment transactions in place of the payment account card itself - It will be noted that every payment network is likely to require the PAN and the expiration date for the digitalized card image. Some payment networks may also require a Card Authentication Method (CAM). For example, a static CAM may be required, such as the CVC2 as established by MasterCard or the CVV as established by Visa. Alternatively, a dynamic CAM may be required, such as is provided in an EMV transaction. (As is known to those who are skilled in the art, EMV is a standard for inter-operation of IC cards with POS terminals and/or ATMs.) For a digitalized card for which EMV is required as a CAM/CVM, the
WSP computer 208 itself may run an EMV engine. Some payment networks may require a specific CVM, such as a biometric (e.g., voice recognition in real time and/or face motion recognition), for each transaction. Other types of CAM/CVM requirements are also possible and/or contemplated, and some others will be discussed below. In some embodiments, the issuer of the payment card account may specify one or more CVMs instead of or in addition to CVM(s) required by the payment network. FIG. 7 schematically illustrates software and functional aspects of the payment-enabledmobile device 202 shown inFIGS. 2 and 3 .- The payment-enabled
mobile device 202 serves as the credential of theuser 210 with respect to thepayment system 200 and also is the mechanism by which theuser 210 is able to initiate and perform payment transactions and otherwise to interact with thepayment system 200. - One salient feature of the payment-enabled
mobile device 202 is that it hosts a server function, represented atblock 702 inFIG. 7 . This function will sometimes be referred to as the consumer device server function. In some embodiments, the consumerdevice server function 702 may be implemented in accordance with the Smart Card Web Server (SCWS) standard promulgated by the Open Mobile Alliance (OMA), and may run on the SIM card308 (FIG. 3 ) and/or thesecure element 328. Alternatively, the consumerdevice server function 702 may be implemented in accordance with the GlobalPlatform Networked Framework. The latter may be advantageous in that it supports unlimited quantities of data per communication and thus removes the need to segment data, as may be required in an SCWS implementation. - The
WSP 208 may fulfill the role of parameterizing the consumerdevice server function 702. The parameters to be provided may include the WSP's identifier in thepayment system 200, and appropriate cryptographic material, to allow theWSP 208 to form a secure data communication connection with the consumerdevice server function 702 during execution of a payment transaction. - Execution of a payment transaction may require services of a number of resources within the payment-enabled
mobile device 202, such as afile system 704. - The file system may, for example, store files related to coupons, promotional vouchers, customer loyalty points, etc.
- Other necessary or desirable resources may fall into the category of applications (block706), and may include a
wallet selection application 708, and anEMV payment application 710, among others. Thewallet selection application 708, as will be seen, may function to allow theuser 210 to select among payment card accounts (digitalized payment cards) housed in the user's digital wallet. TheEMV payment application 710 may provide such functionality as producing a payment token for use in offline-only EMV POI terminals (for such transactions, the WSP would not be involved, and the authentication token provided—as described below—in consumer-device-server-function-to-WSP transactions would not be produced). - A database (block712,
FIG. 7 ) may also be supported in the payment-enabledmobile device 202 in association with one or more of theapplications 706. - The consumer
device server function 702 is uniquely identified in thepayment system 200 through a unique URI, as referred to above. The URI is the root of a namespace tree, such as that depicted inFIG. 8 . - As seen in
FIG. 8 , the above-mentioned namespace root is represented byblock 802. The wallet selection application referred to above is represented byblock 804, and is reached through the tree via the applications namespace (block806) and the wallet path element (block808). Similarly, the above-mentioned EMV payment application is represented byblock 810 inFIG. 8 and is reached through the tree via theapplications namespace 806 and theEMV path element 812. - The tree illustrated in
FIG. 8 also may include a files namespace (block814). In one example embodiment, a default address leaf (block816) is reachable via thefiles namespace 814 and a shippingaddress path element 818. The default shipping address may be modified by the user, and may be used to update the user's digital wallet at theWSP computer 208, with the wallet selection application sending the updated address to theWSP computer 208 in response to a call to the wallet selection application. - An HTTP web client (such as a client application hosted on the WSP computer208) may interact with the consumer
device server function 702 in the following manner, for example. The web client may ask the consumerdevice server function 702 for a service through an appropriate HTTP command. The command may encode several imbricated sub-commands that are targeted to resources accessible via the namespace tree. The consumerdevice server function 702 may dispatch the HTTP command based on the semantic of the command. The consumerdevice server function 702 may identify all imbricated sub-commands to be further directed to the appropriate resources, and then sequentially sends the identified sub-commands to each relevant resource. - While processing a sub-command, a resource may require an interaction with the
user 210. For example, the resource (e.g., the wallet selection application) may need to receive input from theuser 210 concerning the user's selection of a preferred card or set of cards to be used in a current payment transaction. As another example, the resource may require the user to perform a CVM (e.g., PIN entry or biometric) in order to produce proof that the user is not an impostor. - Each resource may elaborate its partial processing result corresponding to the set of sub-commands it executed and may return the partial processing result to the consumer
device server function 702. The consumerdevice server function 702 may use the partial processing results received from the various resources to compose the HTTP response to be sent to the web client that made the HTTP command. FIG. 9 illustrates still further details of software aspects of the payment-enabledmobile device 202 shown inFIGS. 2 and 3 . In particular,FIG. 9 illustrates a basic software configuration that may be provided to implement an authentication token procedure in accordance with aspects of the present invention. (In addition to the software features illustrated inFIG. 9 , the payment-enabledmobile device 202 may be further configured with additional software features to accommodate other functionality including possibly additional functionality described hereinbelow.)- The main software features shown in
FIG. 9 are an interceptionapplication software program 902, a walletselection application program 904, and a contact exchangeapplication software program 906. The walletselection application program 904 may coincide or overlap with thewallet selection application 708 referred to above in connection withFIG. 7 . The interceptionapplication software program 902, the walletselection application program 904 and the contact exchangeapplication software program 906, may in some embodiments run on the secure element328 (FIG. 3 , also depicted inFIG. 9 ). There are other possible arrangements for providing an operating environment within the payment-enabledmobile device 202 for these software features, as will be understood from the above discussion ofFIG. 3 . - The interception
application software program 902 may serve as a front end of the consumerdevice server function 702 referred to in connection withFIG. 7 and may provide the connection for the server function with the outside world, while dispatching sub-commands to internal software resources of the payment-enabledmobile device 202. For example, the interceptionapplication software program 902 may perform some or all of the following tasks, among others: (a) Establishing an HTTP communication session with an HTTP client (such as a client program running on theWSP computer 208,FIG. 5 ); and (b) determining what type of client is requesting service and applying appropriate access condition mechanisms to guarantee that each client is only permitted to ask for services to which it is entitled (the clients in question may include the WSP client—as just mentioned, a client program running on the payment-enabledmobile device 202, or another web client). - Moreover, if the HTTP client is the
WSP computer 208, the interceptionapplication software program 902 may establish a secure communication tunnel with theWSP computer 208 by taken such actions as: (a) successful authentication of theWSP computer 208; (b) providing authenticable information to theWSP computer 208 to certify that the payment-enabledmobile device 202 and the consumerdevice server function 702 are eligible for participation in thepayment system 200 and were issued/enrolled by the operator of the WSP computer208 (i.e., by the wallet service provider in question); and (c) establish secure communications with theWSP computer 208. The resulting communication session will provide encryption, data integrity and data origin authentication of all the data transferred between the payment-enabledmobile device 202 and theWSP computer 208. Various secure tunneling technologies can be used for this purpose, in accordance with the communication security aspects implemented in the payment-enabledmobile device 202 and theWSP computer 208. - Once a secure communication channel has been established between the
WSP computer 208 and the consumerdevice server function 702, the client running in theWSP computer 208 can submit any type of HTTP request to the consumerdevice server function 702, with imbricated sub-commands to application resources within the payment-enabledmobile device 202. - Establishment of the secure communication channel between the
WSP computer 208 and the consumerdevice server function 702 may involve use of a set of cryptographic keys previously loaded into the payment-enabledmobile device 202 during a personalization process performed by theWSP computer 208 with respect to the interceptionapplication software program 902. - In a case where the client making the request is one that runs on the payment-enabled
mobile device 202 itself, the interceptionapplication software program 902 may filter the sub-commands submitted by the client to limit the client's request to actions such as selecting one or more payment card accounts and corresponding amounts to be charged to the accounts in accordance with options presented in a wallet selection form uploaded from the WSP client to the consumerdevice server function 702 for purposes of a current transaction. In this case theWSP computer 208 may consider the HTTP response from the consumer device server function702 (i.e., conveying the wallet selection data as indicated by the user) if and only if such information is coming to theWSP computer 208 via the secure communication channel referred to above and established between the WSP client and the interceptionapplication software program 902. In this case, the communication of the wallet selection information, in a suitably secure manner, may be deemed an authentication token submitted for the transaction by the payment-enabledmobile device 202. It will be appreciated that the user's selection of wallet options as communicated via the authentication token may involve interaction between the user and the walletselection application program 904. - Another action that the interception
application software program 902 may permit a client on the payment-enabledmobile device 202 to perform may be a CVM for authentication of the user as the legitimate owner of the payment-enabledmobile device 202. - Still another action that the interception
application software program 902 may permit a client on the payment-enabledmobile device 202 to perform may be selection of a communication technology (e.g., NFC, Bluetooth, Wi-Fi, QR code, SMS, USSD, etc.) as the mode of communication available between the payment-enabledmobile device 202 and the merchant POI terminal204 (FIG. 2 ) for exchanging contact and transaction data between the payment-enabledmobile device 202 and themerchant POI terminal 204. - In some embodiments, the interception
application software program 902 may function such that other clients (e.g., a client program running on the merchant POI terminal204) may only send information to an application resource on the payment-enabled enabledmobile device 202. For example, the interceptionapplication software program 902 may permit a client running on themerchant POI terminal 204 to send transaction detail data to the contact exchangeapplication software program 906, without requesting processing, and the contact exchangeapplication software program 906/interceptionapplication software program 902 may return contact information for the payment-enabledmobile device 202, such as data that identifies the WSP for the user of the payment-enabledmobile device 202, and the URI for the consumerdevice server function 702 on the payment-enabledmobile device 202. - Turning now to the wallet
selection application program 904, the latter may serve as a resource application that receives data communicated from theWSP computer 208 via the secure tunnel established between the interceptionapplication software program 902 and theWSP computer 208. This data may include data retrieved by theWSP computer 208 from the digital wallet it maintains for the user of the payment-enabledmobile device 202. This data may be referred to as “wallet form data”, and may be such as is needed to allow the user to interact with a client running on the payment-enabledmobile device 202 to visualize his/her digital wallet as maintained on theWSP computer 208. With this data, the user is able to choose from his/her digital wallet a payment card account (or more than one such account) to be used for a current transaction. (I.e., it is contemplated that the user may pay for the entire transaction with one payment card account in his/her wallet, or alternatively he/she may split the transaction amount for funding by two or more of the payment card accounts represented in his/her digital wallet.) - Depending on the requirements set forth by the payment network (and/or the issuer) in question, the wallet
selection application program 904 may require the user to perform a specific CVM. For example, the CVM may call for one or more of the following: (a) entry by the user of an overall wallet access password (not specific to a particular payment card account); (b) entry by the user of the PIN for a particular payment card account selected by the user for the current transaction; and/or (c) submission by the user of biometric input. (As just one example of the latter, where the transaction is to be funded wholly or in part from a social benefits (e.g., a government pension/social security scheme) account, the required CVM may include submission of a biometric that provides “proof of life”—one example of such a biometric would be a spoken utterance by the user to be processed for voice recognition; subsequent discussion herein will describe some examples of voice-recognition-based CVMs that may be provided in accordance with aspects of the present invention.) - The discussion will now turn to the contact exchange
application software program 906. The contact exchangeapplication software program 906 may also be a resource application on the payment-enabledmobile device 202 and may serve to permit the user to exchange data with themerchant POI terminal 204. For example, the contact exchangeapplication software program 906 may supply to themerchant POI terminal 204 address data that identifies the (or a) WSP for the user. In some embodiments, this address data may simply be an identifier by which the WSP is recognized or designated in thepayment system 200. In addition, the contact exchangeapplication software program 906 may supply to themerchant POI terminal 204 address data for the payment-enabledmobile device 202, such as the above-mentioned URI which serves as an internet address for the consumer device server function702 (which may ultimately be passed on to theWSP computer 208, via themerchant POI terminal 204 and the PSP/acquirer computer206). - In terms of data communicated in the other direction, i.e., from the
merchant POI terminal 204 to the contact exchangeapplication software program 906, the latter data may include data concerning the present transaction (which may be denoted as “transaction detail data” and which may include the transaction amount, for example), and also may include data concerning the context (“transaction context data”), such as data related to identification of the merchant, the merchant location, and/or the particularmerchant POI terminal 204 in question. - To enable the communication between the contact exchange
application software program 906 and themerchant POI terminal 204 it may be necessary for there to be agreement on a mode of peer-to-peer communication by which the data is to be exchanged. In some embodiments, the mode of communication may be selected by the user, who may provide input into the payment-enabledmobile device 202 to select, e.g., one of a list of communication modes displayed on themerchant POI terminal 204 as visual icons that are viewable by the user. For example, the communication options may include one or more of NFC, Bluetooth, WiFi, QR code and/or USSD. - As noted before, and among a number of possibilities, the consumer
device server function 702 may be configured to operate in accordance with GPNF, as promulgated by GlobalPlatform, and/or in accordance with the SCWS (Smart Card Web Server) standard published by OMA. Also as noted above, hardware options for the payment-enabledmobile device 202 may include a generally conventional smartphone, e.g., with the consumerdevice server function 702 running on an IC card installed in the smartphone. FIG. 10 schematically illustrates software aspects of the merchant POI terminal204 (FIGS. 2 and 4 ). As can be gathered fromFIG. 2 , themerchant POI terminal 204 may serve as the device that represents the merchant in a particular purchase transaction, and interacts on one hand with the payment-enabledmobile device 202 and on the other hand with the PSP/acquirer computer 206.- At a higher level of the software in the merchant POI terminal204 (
reference numeral 1002 inFIG. 10 ), a contactexchange terminal application 1004 is provided to interact with the payment-enabledmobile device 202, and a PSP/acquirer application 1006 is provided to interact with the PSP/acquirer computer 206. - Relative to the contact
exchange terminal application 1004 and the interaction with the payment-enabledmobile device 202, the contactexchange terminal application 1004 may establish a handshake with the contact exchangeapplication software program 906 in the payment-enabledmobile device 202 to allow the following data exchange: (a) (frommerchant POI terminal 204 to payment-enabled mobile device202) transmission of the transaction detail data for the current transaction and the transaction context (merchant context) data for the current transaction; and (b) (from payment-enabledmobile device 202 to merchant POI terminal204) transmission of the URI for the consumerdevice server function 702 and the identifier for the user's WSP. - Relative to the PSP/
acquirer application 1006 and the interaction with the PSP/acquirer computer 206, the PSP/acquirer application 1006 may establish an internet connection with the PSP/acquirer computer 206 using, for example, TLS (transport layer security) tunneling via the internet to enable the following exchanges of data: (a) (frommerchant POI terminal 204 to PSP/acquirer computer206) the PSP/acquirer application 1006 transmits the contact details for the payment-enabled mobile device202 (i.e., WSP identifier and URI for the consumer device server function702) and the same transaction detail data and transaction context data that the contactexchange terminal application 1004 provided to the contact exchangeapplication software program 906; and (b) (from PSP/acquirer computer 206 tomerchant POI terminal 204; after interaction between the PSP/acquirer computer 206 and the WSP computer208) the PSP/acquirer application 1006 running in themerchant POI terminal 204 receives a transaction result (e.g., approve/decline), to indicate that the purchase transaction may be completed. - At a lower level of the software in the merchant POI terminal204 (
reference numeral 1008 inFIG. 10 ) communication protocol software may be provided, including communication protocol software elements1010-1 through1010-n for communicating with the payment-enabledmobile device 202, and an internet/GPRS (General Packet Radio Service) communicationprotocol software element 1012. Communications via the latter may in some embodiments eventually pass through a WiFi connection. The communicationprotocol software element 1012 may provide at least part of the communication link between themerchant POI terminal 204 and the PSP/acquirer computer 206. FIGS. 11A and 11B together form a flow chart that illustrates a transaction process that may be performed in the payment system200 (FIG. 2 ) in accordance with aspects of the present invention.- At
block 1102 inFIG. 11A , a purchase transaction is initiated. For example, in the context of a brick-and-mortar retail store, a customer (user 210 of the payment-enabled mobile device202) may select merchandise and present it for purchase at a point-of-sale counter. (As will be understood from a later section of this disclosure, the process ofFIGS. 11A and 11B is also generally applicable to the environment of an e-commerce transaction.) - At1104 in
FIG. 11A , transaction data is input into themerchant POI terminal 204, which may be located at the point-of-sale counter. This may occur, for example, by the merchant sales associate operating themerchant POI terminal 204 by, e.g., scanning barcodes on the merchandise to allow input to themerchant POI terminal 204 of the identifiers of the merchandise items and also to allow for lookup by themerchant POI terminal 204 of price information for the merchandise items. As a result of this operation, themerchant POI terminal 204 may calculate a total amount for the purchase transaction (transaction amount). In addition, themerchant POI terminal 204 may generate other transaction data including, for example, a data element that indicates what currency the transaction amount is denominated in, as well as the date of the transaction. - At1106, the
merchant POI terminal 204 may transmit the transaction detail data (e.g., amount, currency, date, etc.) to the payment-enabledmobile device 202, and at the same time themerchant POI terminal 204 may transmit transaction context data to the payment-enabledmobile device 202. For example, the transaction context data may include a merchant identifier and location (which may be parameters stored in the merchant POI terminal204). In addition, the transaction context data may include a unique transaction number (UTN). In some embodiments, themerchant POI terminal 204 may generate a fresh UTN for each transaction it handles. For example, themerchant POI terminal 204 may calculate the UTN as a hash of such information as the merchant identifier, the transaction location, a transaction counter value, and possibly other information as well. Themerchant POI terminal 204 may operate to increment the transaction counter value with each transaction that occurs at themerchant POI terminal 204. - At1108, the payment-enabled
mobile device 202 may transmit data to themerchant POI terminal 204 to permit the payment-enabledmobile device 202 to be contacted for a subsequent stage (token passing) of the transaction process. As mentioned before, the data transmitted from the payment-enabledmobile device 202 to themerchant POI terminal 204 may be address data, in particular: (a) the identifier for the WSP that stores the digital wallet for the user (or at least one of the user's digital wallets), and (b) the URI for the consumerdevice server function 702 hosted in the payment-enabledmobile device 202. (It is worth noting at this point that in some embodiments of the invention and of the payment-enabledmobile device 202, the user may be prompted to select a WSP and/or a digital wallet from among a plurality of his/her WSPs/digital wallets beforestep 1108 occurs and/or the user may make such a selection without being prompted and perhaps while approaching the point-of-sale counter. It is within the contemplation of aspects of this invention that the payment-enabledmobile device 202 may run a WSP-selection app or the like for this purpose.) - It should also be noted that the communication channel216 (
FIG. 2 ) between the payment-enabledmobile device 202 and themerchant POI terminal 204 need not be highly secure, as no highly sensitive data such as a PAN (primary account number) is being exchanged between the two devices. - At1110 in
FIG. 11A , themerchant POI terminal 204 may transmit data to the PSP/acquirer computer 206. This may occur over communication channel218 (FIG. 2 ), which may be implemented over a wide-area network such as the internet or GPRS. Thecommunication channel 218 may be secured by an appropriate measure, such as TSL. The data transmitted at1110 may include the address data that themerchant POI terminal 204 received from the payment-enabledmobile device 202 at1108, and transaction data such as the transaction details, the transaction context and the current transaction counter value. - Following
block 1110 inFIG. 11A is decision block1112. In some embodiments, the determination represented by decision block1112 may be made by and at the PSP/acquirer computer 206. For example, themerchant POI terminal 204 may check that the merchant is duly eligible to participate in thepayment system 200 in the manner requested by themerchant POI terminal 204. This may involve the PSP/acquirer computer 206 searching for the merchant identifier (included in the transaction context data) in one or more merchant subscription tables. If the PSP/acquirer computer 206 determines that the merchant is eligible to request the transaction, then the PSP/acquirer computer 206 may proceed with further checks, such as checking that the transaction counter is fresh and that the UTN is valid relative to the merchant. - In addition, the PSP/
acquirer computer 206 may check the identification of the WSP to confirm that the WSP is validly enrolled in thepayment system 200. This may occur in a manner that is analogous to a conventional operation in which an acquirer may confirm the validity of a payment network for which a PAN-based authorization request is to be submitted. - Assuming that the checks all result in satisfactory findings, block1114 may follow decision block1112 in the process of
FIGS. 11A and 11B . Atblock 1114, the PSP/acquirer computer 206 may transmit data to theWSP computer 208. As part of this operation, the PSP/acquirer computer 206 may use the identifier of the WSP as received from themerchant POI terminal 204 to determine that it should establish a secure communication channel (channel 220 inFIG. 2 ) with the appropriate WSP. This may be done over the internet, for example, with TSL. The data transmitted at1114 may include all the data received by the PSP/acquirer computer 206 at1110, except possibly excluding the transaction counter value provided by themerchant POI terminal 204. It will be noted that, according to aspects of this invention, this data will typically include the URI for the consumerdevice server function 702 hosted on the payment-enabledmobile device 202. Block 1116 followsblock 1114. Atblock 1116, theWSP computer 208 receives and processes the data transmitted by the PSP/acquirer computer 206. In particular, theWSP computer 208 may generate a transaction identifier, which may for example be formed from the merchant identifier (corresponding to the merchant that operates the merchant POI terminal204) plus the UTN provided in the message received by theWSP computer 208 from the PSP/acquirer computer 206. Further as part of the operation ofblock 1116, theWSP computer 208 may store the transaction data (transaction detail data and transaction context data), as received from the PSP/acquirer computer 206, in association with the transaction identifier generated by theWSP computer 208. Still further as part of the operation ofblock 1116, theWSP computer 208 may read, from the data supplied by the PSP/acquirer computer 206, the URI for the consumerdevice server function 702 hosted in the payment-enabledmobile device 202. Next, theWSP computer 208 may verify that the URI in question is not blacklisted and that the user in question has a valid subscription to the wallet services provided by the WSP that operates theWSP computer 208.Block 1118 followsblock 1116. Atblock 1118, theWSP computer 208 goes on to retrieve the wallet entry for the user of the payment-enabledmobile device 202, as identified by the above-mentioned URI. With the data from the user's wallet entry (i.e., the user's digital wallet maintained by the WSP computer208), theWSP computer 208 forms wallet form data to be sent to the consumerdevice server function 702 hosted in the payment-enabledmobile device 202. The wallet form data will present information to the user to permit him/her to choose among the payment card accounts in his/her digital wallet to select the account(s) to be used for the current transaction. If the user wishes to use more than one of his/her accounts and to distribute the transaction amount among the selected accounts, the wallet form data may allow the user to indicate his/her choices in this regard as well.Block 1120 followsblock 1118. Atblock 1120, theWSP computer 208 uses the URI for the consumerdevice server function 702 hosted in the payment-enabledmobile device 202 to initiate formation of a secure communication channel (channel 222 inFIG. 2 ) between theWSP computer 208 and the consumerdevice server function 702 hosted in the payment-enabledmobile device 202. For example, a so-called secure tunneling technology may be employed, such as one of the published protocols known as “SCP” (secure channel protocol). The consumerdevice server function 702 hosted in the payment-enabled mobile device202 (and particularly, the interception application software program902) cooperates with theWSP computer 208 in exchanging information necessary for theWSP computer 208 and the consumerdevice server function 702 hosted in the payment-enabledmobile device 202 to mutually authenticate each other. With the successful formation of thesecure communication channel 222, it is established that theWSP computer 208 and the consumerdevice server function 702 hosted in the payment-enabledmobile device 202 have mutually authenticated each other, and enciphering of communications in both directions through thechannel 222 is enabled.- Referring again to the flowchart of
FIGS. 11A-11B , and particularly toFIG. 11B ,block 1122 followsblock 1120. Atblock 1122, theWSP computer 208 transmits the above-referenced wallet form data to the payment-enabled mobile device202 (i.e., to the consumer device server function702). Then block1124 followsblock 1122. At1124, the payment-enabled mobile device202 (particularly the interception application software program902) decrypts the wallet form data and submits the information contained in the wallet form data to the user via the walletselection application program 904. Using the interface provided to him/her via the payment-enabledmobile device 202, theuser 210 selects the account(s) for the current transaction, and if necessary the respective amounts for funding by each account, if more than one account is selected. The resulting account selection data is provided within the payment-enabledmobile device 202 to the interceptionapplication software program 902. (It may be the case that, in connection with the user's interaction with the walletselection application program 904, the user may be required to properly complete a CVM process, such as those referred to above. For example, PIN entry and/or submission of biometric input may be required. In some embodiments, the resulting data ultimately is passed along to theWSP computer 208 for verification.) Block 1126 followsblock 1124. As part of the operation ofblock 1126, the interceptionapplication software program 902 generates an authentication token for the transaction. The interceptionapplication software program 902 may generate the authentication token as a Message Authentication Code (MAC) on the basis of the account selection data, and the transaction data (transaction detail data and transaction context data) that the payment-enabledmobile device 202 had received at block1106 (FIG. 11A ) from themerchant POI terminal 204. Also as part of the operation ofblock 1126, the interceptionapplication software program 902 may generate a transaction identifier, which may contain the merchant identifier for the transaction plus the UTN generated for the transaction by themerchant POI terminal 204 and transmitted to the payment-enabledmobile device 202 atblock 1106. The interception application software program902 (and hence the payment-enabled mobile device202) may then transmit the following data to the WSP computer208: (a) the account selection data, as indicated by theuser 210 at1124; (b) the transaction identifier, and (c) the authentication token. It should be noted that although the payment-enabledmobile device 202 may not transmit the transaction data (i.e., the transaction detail data and the transaction context data) in their complete form to theWSP computer 208, nevertheless, because the authentication token is based on the transaction data (with other data elements), the authentication token may be considered a verifiable copy of the transaction data.- Continuing to refer to
FIG. 11B ,block 1128 followsblock 1126. Atblock 1128, theWSP computer 208 receives the data transmitted from the payment-enabled mobile device202 (i.e., from the interceptionapplication software program 902/consumer device server function702). Using the transaction identifier provided by the payment-enabledmobile device 202, theWSP computer 208 matches the data received from the payment-enabledmobile device 202 with the data it had stored for the transaction in association with the transaction identifier as generated by theWSP computer 208 atblock 1116. TheWSP computer 208 identifies the transaction detail data and the transaction context data that it had previously stored (after receiving same from the PSP/acquirer computer 206 at1116) and proceeds to verify the authentication token as provided by the consumerdevice server function 702 hosted in the payment-enabledmobile device 202. In doing so, theWSP computer 208 in effect confirms that the transaction detail data and the transaction context data as reflected in the authentication token match the transaction detail data and the transaction context data as received by theWSP computer 208 from the PSP/acquirer computer 206. Verification of the authentication token by theWSP computer 208 indicates to theWSP computer 208 that the account selection data from the payment-enabledmobile device 202 is valid and has the effect of a payment order to be executed by theWSP computer 208. Block 1130 followsblock 1128. It will initially be assumed for the purpose of describingblock 1130 that theuser 210 had selected only one payment card account from his/her digital wallet to fund the current transaction. Accordingly, at1130 theWSP computer 208, acting substantially like a conventional acquirer, uses the PAN for the user-selected payment card account (as stored in and retrieved from the user's digital wallet) to route a payment network authorization request via the indicated payment network (assumed to be thepayment network 110 shown inFIG. 2 ) to the issuer of the user-selected payment card account (assumed to be theissuer 112 shown inFIG. 2 ).- Now, for an alternate description of
block 1130, it will be assumed that the user selected more than one payment card account from his/her digital wallet, for distribution of the transaction amount among the selected payment card accounts. In this case, the account selection data provided by the payment-enabledmobile device 202 to theWSP computer 208 may include two or more lines, with each line corresponding to a respective user-selected account and with each line indicating the portion of the transaction amount to be charged to the respective account. For each such account, theWSP computer 208 may issue a respective authorization request via the appropriate payment network (i.e, more than one payment network may be involved in the current transaction, although only one payment network is depicted inFIG. 2 ) for routing to the respective issuer for the account. - Continuing to refer to
FIG. 11B ,block 1132 followsblock 1130. Atblock 1132, theWSP computer 208 receives a substantially conventional authorization response message, which originated from theissuer 112 and which was routed to theWSP computer 208 via the payment network. It will next be assumed that the authorization response indicates approval by the issuer of the authorization request initiated by the WSP computer208 (or, if more than one payment card account had been selected by the user, it is assumed that all of the authorization responses from the issuers indicate approval), in which case,block 1134 followsblock 1132. - At
block 1134, theWSP computer 208 transmits an acknowledgment message to the PSP/acquirer computer 206 to confirm that payment has been duly made for the current transaction.Block 1136 then follows. Atblock 1136, the PSP/acquirer computer 206 transmits an acknowledgment message to themerchant POI terminal 204 to confirm that payment has duly been made for the current transaction.Block 1138 then follows, at which the purchase transaction at the retail store is completed. For example, themerchant POI terminal 204 may display to the merchant's sales associate an indication that payment has been acknowledged/confirmed, and may print a suitable receipt for the customer/mobile device user 210. The customer may then leave the retail store with the purchased merchandise and the receipt. - The
payment system 200, as described herein, may provide enhanced security for sensitive information such as payment card account PANs as compared to conventional payment systems in which the merchant reads the PAN from a card or other device at the point of purchase. In thepayment system 200, the merchant never has possession of the customer's PAN; accordingly, a mass data breach at the merchant level, with attendant difficulties and potential exposure to fraud, may be highly unlikely or impossible with thepayment system 200. - Moreover, because the PAN and related data do not pass through the POS terminal (also referred to as the POI terminal) in the
payment system 200, the cost of the POS terminal may be substantially reduced as compared to conventional POS equipment currently in use. For example, in the POI terminal as described herein, there may be no need for the type of complex cryptographic calculations that are employed in some conventional POS equipment. Accordingly the POI terminal as described herein may be simplified in that it may not need to have either a fast main processor and/or a specialized cryptographic processor, such as may be included in conventional POS equipment. Moreover, with this arrangement PCI compliance may not be required for the POI terminal There may also be savings with respect to the software that programs the POI terminal as described herein in that the software itself may be less complex than conventional POS equipment software, and may be subject to less complex certification processes than are conventionally employed in many cases for POS equipment software. - Further, in other hardware respects the POI terminal described herein may be simplified, in that there may be no need for such components as a secure keyboard, a secure biometric sensor or a secure display device. In general, tampering detection and tampering reaction mechanisms may not be needed in the POI terminal described herein, because the POI terminal no longer handles payment application processes, but rather is a protocol adapter for exchanging basic information between the customer and the merchant, while also relaying basic information from the consumer
device server function 702 hosted in the payment-enabledmobile device 202 to the PSP/acquirer and on to the WSP. - It is another advantage of the
payment system 200 that, in contrast to other payment token systems that have been proposed, there are potentially an unlimited number of authentication tokens available as the same have been described in this disclosure. - Still further, since the payment-enabled
mobile device 202 provides a representation of transaction data to theWSP computer 208, for comparison by theWSP computer 208 with the transaction data received from themerchant POI terminal 204 via the PSP/acquirer computer 206, there is enhanced protection against fraudulent unsolicited transactions. - In the above discussion of the embodiment shown in
FIG. 2 and subsequent drawings, it has been assumed that themerchant POI terminal 204 was located at the point of sale in a brick-and-mortar retail store. However, in other embodiments of thepayment system 200, themerchant POI terminal 204 may for example be constituted by an e-commerce server operated by a merchant to handle online purchase transactions. In such embodiments, the customer may access themerchant POI terminal 204 initially in a conventional manner (e.g., via a browser running on a personal computer), or alternatively may use a mobile device browser running on his/her smartphone/mobile device (which may also be the above-described payment-enabled mobile device202). In any case, for the payment portion of the transaction, themerchant POI terminal 204 and the payment-enabledmobile device 202 may exchange such information as is described above in connection withblocks mobile device 202 acting as a client and connecting to the merchant's website via its browser. For these purposes the payment-enabledmobile device 202 may exchange communications with themerchant POI terminal 204 via a mobile communications network (not shown) for which the payment-enabledmobile device 202 is a subscriber device. In other ways, for this case of themerchant POI terminal 204 as an e-commerce server, the process as described above in connection with FIGS.11A/11B may be quite similar. - Referring again to the case where the purchase transaction occurs face-to-face, the
merchant POI terminal 204 and the payment-enabledmobile device 202 may be able to interact directly via a bidirectional exchange. To establish the bidirectional exchange, themerchant POI terminal 204 and the payment-enabledmobile device 202, acting as peer devices, may perform an automatic setup of a bidirectional channel between the two devices. This could occur in a number of ways, depending on the features present in the devices. For example, this could be done directly through an NFC peer-to-peer data exchange. This may be an advantageous approach in that it takes advantage of existing smartphone capabilities. - However, in other embodiments, or if additional features require a larger volume of data to be exchanged, the bidirectional communication could occur through a process where the devices cooperate via NFC to transfer over to another technology such as Bluetooth or WiFi.
- As another alternative, and as suggested above (and in either a face-to-face or remote transaction situation), the
merchant POI terminal 204 and the payment-enabledmobile device 202 may interact outside a communication channel. For example, via USSD or SMS, the payment-enabledmobile device 202 may submit the information referred to in connection withblock 1108 to a phone number visually displayed on themerchant POI terminal 204. As another possibility, the payment-enabled mobile device202 (assuming it includes a camera, as many smartphones do), may capture an image of a QR code (quick response code) as displayed by the merchant POI terminal204 (or downloaded from the merchant, in the case where themerchant POI terminal 204 is an e-commerce server). - In the embodiment shown in
FIG. 2 , the PSP/acquirer computer 206 functions essentially as a switch between merchant devices and WSPs. It is contemplated that some embodiments may omit the PSP/acquirer computer 206 in favor of a direct communication link between themerchant POI terminal 204 and theWSP computer 208. However, it may be advantageous to have acquirers as a layer between merchants and WSPs to aid in managing the workload for the WSPs and to enhance scalability of thepayment system 200. It may also aid in fast and efficient conflict resolution and chargebacks to have acquirers present in thepayment system 200 between merchants and WSPs. FIG. 12 schematically illustrates a clearing process that may be performed in thesystem 200 ofFIG. 2 in accordance with aspects of the present invention.- In
FIG. 12 , payment card issuers' settlement accounts are indicated at1202. The settlement accounts of payment networks are indicated at1204. (Although only onepayment network account 1204 is shown as having payment card issuers' accounts feeding into it, in practice, as will be appreciated, the same will be true of all of the payment network settlement accounts.) - A first level of the clearing process is indicated at1206, and features a
WSP 1208, having aWSP pool account 1210. A second level of the clearing process is indicated at1212, and features settlement accounts1214 belonging to PSPs/acquirers. - Also shown in
FIG. 12 are merchant settlement accounts1216. (To simplify the drawing, only one of the PSP/acquirer settlement accounts1214 is shown feeding merchant settlement accounts1216; however it will be understood that in practice all the PSP/acquirer settlement accounts1214 would do the same.) - One of the payment card issuer settlement accounts1202 may be associated with the
issuer 112 shown inFIG. 2 . One of the payment network settlement accounts1204 may be associated with thepayment network 110 shown inFIG. 2 . TheWSP 1208 shown inFIG. 12 may be the operator of theWSP computer 208 shown inFIG. 2 . One of the PSP/acquirer settlement accounts1214 shown inFIG. 12 may be associated with the operator of the PSP/acquirer computer 206 shown inFIG. 2 . One of the merchant settlement accounts1216 shown inFIG. 12 may be associated with the merchant that operates themerchant POI terminal 204 shown inFIG. 2 . - It will be understood that two or more different payment networks are represented in the payment network settlement accounts1204 shown in
FIG. 12 , whereas those two or more different payment networks are also participants in the payment system200 (notwithstanding that only one payment network is explicitly shown inFIG. 2 ). Block 1210 shown inFIG. 12 , in addition to representing the WSP pool account, should also be understood to represent a computer that manages the flow of clearing credits into and out of the pool account. That computer may be operated by a financial institution, by the WSP, or by another entity and may for example be theWSP computer 208 ofFIG. 5 .- At the
first level 1206 of the clearing process, theWSP 1208 has a role like a “mega” acquirer, and each PSP/acquirer represented inFIG. 12 has a role like a “mega” merchant. The clearing between theWSP 1208 and the payment card issuers occurs in the same manner as conventional clearing between an acquirer and issuers through a payment network. TheWSP 1208 manages thepool account 1210 to receive clearing credits from the payment network settlement accounts1204, where the clearing credits originated from payment card accounts issued by the payment card issuers represented inFIG. 12 . Moreover, theWSP 1208 manages thepool account 1210 to distribute the clearing credits among the PSP/acquirer settlement accounts1214. - At the
second level 1212 of the clearing process, each acquirer manages itsrespective settlement account 1214 to clear credits due to its subscriber merchants. In particular, each of the PSP/acquirer settlement accounts1214 receives clearing credits from theWSP pool account 1210, and those credits are further distributed to the merchant accounts1216. - The layered clearing process as illustrated in
FIG. 12 may aid in enhancing the scalability of thepayment system 200.FIG. 12 also illustrates how funds flow among participants in the acquiring process with appropriate service fees accruing. FIG. 13 is a block diagram that illustrates an alternative embodiment (generally indicated byreference numeral 200ainFIG. 13 ) of the payment system ofFIG. 2 .- The
payment system 200ashown inFIG. 13 may include essentially all of the components of thepayment system 200 as described in connection withFIG. 2 and subsequent drawings. In addition, the payment system may include a value added services (VAS)WSP computer 1302 that is connected (at least from time to time) to an PSP/acquirer computer206avia acommunication channel 1304. (The PSP/acquirer computer206ashown inFIG. 13 may include all of the functionality of the PSP/acquirer computer 206 shown inFIG. 2 and as described above, and in addition may perform additional switching and/or other functions to accommodate value added services/split payment functionality in thepayment system 200aofFIG. 13 .) TheVAS WSP computer 1302 may maintain for the user210 (and many other users as well) one or more digital wallets by which theuser 210 may access and select funding from benefit accounts (i.e., not from payment card accounts). The benefits accessible via the user's digital wallet atVAS WSP computer 1302 may include one or more of the following: (a) coupons, (b) loyalty/rewards points, (c) medical insurance benefits, (d) pension and/or social insurance and/or social welfare benefits, (e) casualty insurance benefits, etc. FIG. 13 also shows two main functional blocks of theVAS WSP computer 1302, namely asplit amount engine 1306 and a VASwallet services component 1308. Thesplit amount engine 1306 may perform logic required to split payment in thepayment system 200abetween benefit funding and payment card account funding.- The VAS
wallet services component 1308 may maintain the VAS/benefit funds digital wallets for users of thepayment system 200a. - Also shown in
FIG. 13 is a benefitssystem operator computer 1310. The benefitssystem operator computer 1310 may be connected to theVAS WSP computer 1302, at least from time to time, via acommunication channel 1312; in some embodiments, a one-to-one connection may be provided between the benefitssystem operator computer 1310 and theVAS WSP computer 1302 as part of a dedicated financial services communications network. - The
VAS WSP computer 1302, the benefitssystem operator computer 1310 and the PSP/acquirer computer 206 may all be constituted by conventional computer hardware, such as that described above in connection with the description of theWSP computer 208 hardware shown inFIG. 5 . TheVAS WSP computer 1302, the benefitssystem operator computer 1310 and the PSP/acquirer computer 206 may be programmed to provide system functionality as described herein. - The
VAS WSP computer 1302 may store (in a storage medium such as those referred to above in connection withFIG. 5 ) and may be programmed/controlled by one or more software programs so that theVAS WSP computer 1302 may provide functionality as described herein. - In some embodiments, the wallet services provided by the
VAS WSP computer 1302 may entail maintaining one or more digital wallets per user/subscriber for the services of the VAS WSP. In some embodiments, for example, theuser 210 may have stored for his/her benefit in theVAS WSP computer 1302 one or more of the following: (a) a rewards wallet, for loyalty points, coupons, promotional payments, etc.; (b) a medical insurance wallet for medical, dental, long term care, and other like benefits; (c) a casualty insurance wallet; and (d) a social benefits wallet (e.g., for social welfare payments, government pension plan benefits, etc.). FIG. 14 is a high level flow chart that illustrates a transaction process that may be performed in thepayment system 200ain accordance with aspects of the present invention.- The process of
FIG. 14 may, for example, be triggered by a signal that indicates that the current transaction is eligible for split payment between two or more of the user's digital wallets, such as a benefits account wallet and a payment card account wallet. For example, the signal may be a code provided by themerchant POI terminal 204 and/or may be the identifier for the merchant that operates themerchant POI terminal 204. For example, the signal may identify the merchant as a medical services provider, for which the charges are eligible for partial payment via a medical insurance benefit. In some embodiments, the signal may be received to trigger the process ofFIG. 14 at the PSP/acquirer computer206a. - At
block 1402 inFIG. 14 , the PSP/acquirer computer206aselects an appropriate benefits wallet or other digital wallet for theuser 210 in response to the triggering signal referred to above. For example, the PSP/acquirer computer206amay select the user's digital wallet that is appropriate in view of the triggering signal. (For example, the triggering signal may indicate to the PSP/acquirer computer206athat the merchant is a service provider whose services are eligible for benefits payments. The PSP/acquirer computer206amay also look up the user (via the URI for the server function in the payment-enabled mobile device202) to determine that the user is eligible for benefits and has a wallet service provider for the benefits.) - Accordingly, the PSP/acquirer computer206amay then contact the wallet service provider that maintains the selected wallet, assumed in this case to be the operator of the
VAS WSP computer 1302. Thus, the PSP/acquirer computer206atransmits a request to theVAS WSP computer 1302 to download wallet form data for the selected wallet. - The process of
FIG. 14 advances fromblock 1402 to block1404. At block1404, theuser 210 is permitted to select a funding account from the selected digital wallet. For that purpose, corresponding wallet form data provided by theVAS WSP computer 1302 is transmitted to the payment-enabledmobile device 202. (For example, the wallet form data may be received by theWSP computer 208 directly or indirectly from theVAS WSP computer 1302 and then relayed on from theWSP computer 208 to the payment-enabledmobile device 202. In some embodiments, theVAS WSP computer 1302 transmits the wallet form data to the PSP/acquirer computer206a,which relays the wallet form data to theWSP computer 208, along with the URI for the server function in the payment-enabledmobile device 202. TheWSP computer 208 may then form a secure communication channel with the payment-enabledmobile device 202, in the manner described above in connection with block120 ofFIG. 11 .) The wallet form data, when received by the payment-enabledmobile device 202, provides to theuser 210 at least one funding account option that is available to theuser 210 and represented in the digital wallet selected atblock 1402. In some embodiments, the selected digital wallet may contain only one funding account option (e.g., a medical insurance benefits account), and the user selection of that funding account option may occur simply by theuser 210 indicating that he/she wishes the funding account in question be applied to a first portion of the transaction amount that is to be funded. In other cases, the selected digital wallet may contain two or more funding account options (e.g., various loyalty points, coupons or promotion accounts available to the user210) and theuser 210 may provide input via the payment-enabledmobile device 202 to indicate the user's selection of one of the funding account options. The resulting account selection signal, indicative of the user's selection of an account (or confirmation that an account is to be used, if it is the only option in the selected digital wallet) may be received by one or more of theWSP computer 208, the PSP/acquirer computer206aand theVAS WSP computer 1302. - In some embodiments, the account selection signal may be transmitted from the payment-enabled
mobile device 202 via thesecure communication channel 222 to theWSP computer 208. TheWSP computer 208 may relay the account selection signal to the PSP/acquirer computer206a,which in turn transmits the account selection signal to theVAS WSP computer 1302. - Then, at
block 1406 inFIG. 14 , the required payment for the current transaction is split.FIG. 15 schematically illustrates one example process by which the payment split may take place. (This process may be performed, for example, by theVAS WSP computer 1302.) InFIG. 15 ,block 1502 represents a benefit computation method that may be applicable to the funding account selected at1404. - The benefit
computation method block 1502 may receive as an input (as indicated at1504) the total amount that is to be paid for the current transaction (i.e., the transaction amount). The output (reference numeral1506) from the benefitcomputation method block 1502 may be the maximum amount that the transaction is eligible to receive in funding from the selected funding account. At a node indicated byreference numeral 1508, aninput 1510 may be received to indicate the user's preference that less than the entire available benefit be drawn from the selected funding account. (That is, the process ofFIG. 15 gives theuser 210 an option to elect to use less than the entire benefit for which he/she is eligible for the current transaction; information may be presented to theuser 210 concerning this option via the payment-enabledmobile device 202, and the payment-enabledmobile device 202 may receive input from theuser 210 to indicate that the user elects to receive the maximum benefit available, or to indicate a smaller amount of the benefit that theuser 210 opts to apply to the current transaction. The communications to support the user input may run between theVAS WSP computer 1302 and the payment-enabledmobile device 202, via the PSP/acquirer computer206aand theWSP computer 208.) Theoutput 1512 from thenode 1508 is the smaller amount of theinputs - A consequence of the process of
FIG. 15 is that a partial transaction amount is determined, which partial transaction amount is funded from the funding account option selected (or confirmed) by theuser 210 at block1404.Block 1408 inFIG. 14 represents the partial funding of the transaction amount, by the amount output fromnode 1508 inFIG. 15 , from the funding account selected at block1404. - Following
block 1408 inFIG. 14 isblock 1410. Atblock 1410, another one of the user's digital wallets may be selected by the PSP/acquirer computer206a.For example, the PSP/acquirer computer206amay next select the user's digital wallet maintained at theWSP computer 208. - With the second digital wallet having been selected, the process of
FIG. 14 advances to block1412. Atblock 1412, theuser 210 is permitted to select a funding account from the second digital wallet that was selected. To allow the user to select the next funding account, wallet form data that corresponds to the second selected digital wallet is transmitted to the payment-enabledmobile device 202. The latter wallet form data, when received by the payment-enabledmobile device 202, provides to theuser 210 at least one, and possibly two or more, funding account options that are available to the user and are represented by the second selected digital wallet (i.e., the digital wallet selected at block1410). Assuming that two or more funding account options (say, two or more payment card accounts) are represented in the second selected digital wallet, the user interface of the payment-enabledmobile device 202 may present those options to theuser 210, and may receive input from theuser 210 to indicate the user's selection of an account from among those options. The resulting account selection signal, including data indicative of the user's selection of the latter account, may be received by one or more of theWSP computer 208, the PSP/acquirer computer206aand theVAS WSP computer 1302. In some embodiments, if the second selected wallet was maintained by theWSP computer 208, the balance of the operation corresponding to block1412 may include operations such as those described above in connection withblocks FIG. 11B , resulting in funding of the balance of the transaction amount (block 1414,FIG. 14 ) from a payment card account selected by theuser 210 atblock 1412. - In the above discussion of
FIG. 14 , it was stated that the PSP/acquirer computer206ahandled selection of a first one of the user's digital wallets and thereafter a second one of the user's digital wallets. Alternatively, however, in some embodiments another entity in thepayment system 200amay perform one or both of the wallet selections. For example, theuser 210 may make one or both of the wallet selections, possibly with guidance from the PSP/acquirer computer206avia a communication path running through theWSP computer 208 to the payment-enabledmobile device 202. - As noted above (e.g., in connection with discussion of
block 1124 inFIG. 11B and/or the discussion of the walletselection application program 904 in relation to FIG. 9 ), the user's selection of an account (e.g., a payment card account) from the user's digital wallet may be accompanied by a requirement that the user participate in a CVM operation.FIG. 16 schematically illustrates a biometric-based cardholder verification method (CVM) that may be performed according to aspects of the invention in thepayment systems FIG. 2 orFIG. 13 .- In
FIG. 16 , components to the left ofdividing line 1602 may be part of the payment-enabledmobile device 202 shown inFIG. 2 , while components to the right of thedividing line 1602 may be part of theWSP computer 208. In this arrangement, the payment-enabledmobile device 202 may serve as a proving device, andWSP computer 208 may serve as a verifying device, for the biometric CVM operation. For example, as part of the payment-enabledmobile device 202 there may be abiometric sensor 1604 and adata acquisition unit 1606. (In some embodiments, the biometric sensor may be constituted by the microphone320 (FIG. 3 ) or a camera (not shown) included in the payment-enabledmobile device 202.) The payment-enabledmobile device 202 may perform the relatively limited function of acquiring the raw biometric data and sending it to theWSP computer 208 via thecommunication channel 222. In this embodiment, the payment-enabledmobile device 202 need not store any biometric reference data, and accordingly need not be personalized for biometric CVM. This may tend to reduce or eliminate the need for a large permanent memory in the payment-enabledmobile device 202. It is also advantageous that the cryptographically securedcommunication channel 222 is available between the payment-enabledmobile device 202 and theWSP computer 208 to allow for transmission of the raw biometric data from the former device to the latter device. - The reference data for the biometric CVM, in this embodiment, may be stored at the
WSP computer 208, as indicated byblock 1608 inFIG. 16 . Processing of the raw biometric data received by theWSP computer 208 from the payment-enabledmobile device 202 may be performed by functional blocks such asfeature extraction block 1610, imagesignal processing block 1612 and comparison/matching block 1614. Adecision function 1616 on the WSP computer side may determine whether the CVM is valid based on output from the comparison/matching block 1614 and based on previously stored decision parameters indicated at1618 inFIG. 16 . - Assuming that the decision parameters are satisfied, the output from the
decision function 1616 may be authorization of the transaction, as indicated at1620. - With the arrangement shown in
FIG. 16 , biometric data captured by the payment-enabledmobile device 202 is not analyzed at the payment-enabledmobile device 202, but rather un-analyzed biometric data is transmitted from the payment-enabledmobile device 202 to be received by theWSP computer 208, and to be analyzed and verified at theWSP computer 208. This arrangement may result in a high degree of flexibility in terms of permitting various different types of biometric CVM to be employed for different accounts in the user's digital wallet, and/or for new types of biometric CVM to be introduced into the operations of thepayment system 200a.The flexibility available for applying different types of biometric CVM may also be utilized to match the type of biometric CVM capability supported by the particular mobile device to be used in the transaction. Also, since theWSP computer 208 is highly secure, it is quite unlikely that the user's biometric reference data would be compromised, as could more easily occur if the biometric reference data were present in the payment-enabledmobile device 202 and the latter were lost or stolen. FIG. 17 is a block diagram that illustrates aspects of the biometric-based CVM ofFIG. 16 . In addition,FIG. 17 may aid in illustrating how a biometric-based CVM as inFIG. 16 may be integrated into the transaction process described above primarily with reference toFIGS. 2 ,11A and11B.FIG. 17 may be considered to represent a subset of the apparatus ofFIG. 2 , as modified to accommodate a biometric CVM process as described above in connection withFIG. 16 .FIG. 17 shows the following features shown in and discussed above in connection with FIG.2—the payment-enabledmobile device 202, theWSP computer 208, and thecommunication channel 222. Further, as part of the payment-enabledmobile device 202,FIG. 17 also shows the following software elements that were discussed above in connection with FIG.7—the consumerdevice server function 702 and thewallet selection application 708. Still further, and also as part of the payment-enabledmobile device 202,FIG. 17 shows thecomponents 1604,1606 (biometric sensor and biometric data acquisition) referred to in the above discussion ofFIG. 16 .- Also,
biometric verification block 1702 inFIG. 17 , which is shown as part of theWSP computer 208, represents the functional blocks shown inFIG. 16 to the right ofdividing line 1602. Also seen inFIG. 17 , as part of theWSP computer 208 is thetransaction concentrator block 214 referred to above in connection withFIG. 2 . In the apparatus as illustrated inFIG. 17 , thetransaction concentrator block 214 is shown as being in communication with thebiometric verification block 1702 of theWSP computer 208. - In operation of the apparatus of
FIG. 17 (and also referring toblocks FIG. 11B ), theuser 210 may perform account selection via thewallet selection application 708, and may present his/her biometric feature to thebiometric sensor 1604. After acquisition of the user's biometric data, the latter is transmitted—together with a biometric technology identifier (e.g., fingerprint, voice recognition, finger vein, retina, facial geometry, etc.) to thewallet selection application 708. After gathering the user's account selection, the biometry identifier and the raw biometric data, thewallet selection application 708 sends them via the consumerdevice server function 702 and thesecure channel 222 to theWSP computer 208. - Based on the biometry identifier, the
WSP computer 208 chooses the appropriate biometric data processing algorithm for the raw biometric data and the appropriate stored biometric reference data repository. Within the selected biometric data repository, the particular set of biometric reference data for the user in question may be retrieved based on the URI for the consumerdevice server function 702 in the payment-enabledmobile device 202. Thebiometric verification block 1702 then applies the biometric verification process illustrated inFIG. 16 to the raw data. Assuming the result of the process is, “valid”, then thetransaction concentrator block 214 may trigger the authorization request(s) as referred to above in connection withblock 1130 ofFIG. 11B . FIG. 18 is a block diagram that illustrates an alternative CVM that may be performed according to aspects of the invention.FIG. 18 may aid in illustrating a CVM that may be particularly suitable for use in remote (e-commerce) transactions, although it may also be useful for an in-store transaction that is not consummated via a local POS terminalFIG. 18 shows a modified version (reference numeral208a) of the WSP computer referred to above. TheWSP computer 208amay include an interactive voice response (IVR)unit 1802, avoice recognition unit 1804, awallet partition unit 1806 and apayment gateway function 1808. TheWSP computer 208amay interact with a cell-phone 1810 via theIVR unit 1802 and thevoice recognition unit 1804. The cell-phone 1810 may or may not be a smartphone, and may or may not be a payment-enabled mobile device (such as described hereinabove). TheWSP computer 208amay also interact with aconventional browser 1812 via thepayment gateway function 1808. (Thebrowser 1812 may run on a conventional personal computer, tablet, smartphone or the like, which are not separately shown. Thebrowser 1812 may receive input from the same individual (not shown) who owns and uses the cell-phone 1810. The browser may be configured so that it “knows” the telephone number for the cell-phone 1810.)- In operation of the apparatus of
FIG. 18 , thebrowser 1812 may retrieve an ordering page from the merchant e-commerce site (not shown), and may allow the user to select one or more items for purchase, as indicated via the browser to the e-commerce site. The e-commerce site may then compute the amount due for the transaction and submit the transaction amount to the browser. The browser may then send the transaction amount, the cell-phone telephone number and possibly other transaction information as well to thepayment gateway function 1808 of theWSP computer 208a. - Using the cell-phone telephone number, the
payment gateway function 1808 retrieves the digital wallet for the user from thewallet partition unit 1806, and from the user's digital wallet theWSP computer 208agenerates wallet form data, which is supplied to theIVR unit 1802 together with the cell-phone telephone number. TheIVR unit 1802 calls the cell-phone 1810 and audibly prompts the user to make an account selection based on the wallet form data. The user responds by spoken utterance into the cell-phone 1810 to indicate his/her payment card account selection. The voice utterance is sent from the cell-phone 1810 to thevoice recognition unit 1804 of theWSP computer 208a.The voice recognition unit performs both of the following on the basis of the voice utterance—(a) identifying the user based on a voice sample reference previously stored in a reference data repository on theWSP computer 208a(where the reference was associated with the cell-phone telephone number)—i.e., in effect CVM; and (b) detecting the user's selection of a payment card account from the user's digital wallet based on speech content recognition as applied to the voice utterance received from the cell-phone 1810. If the CVM is found “valid”, then the account selection is passed on to a wallet unit in theWSP computer 208a.The wallet unit then triggers an authorization request for the selected payment card account (or more than one authorization request, if the user elected to split payment among two or more of his/her payment card accounts). TheWSP computer 208athen receives an authorization response from the payment card account issuer (or more than one, if more than one account is being used). The result of the authorization response is provided to thepayment gateway function 1808 of theWSP computer 208a.If the transaction is approved, the payment gateway provides an acknowledgment message accordingly to the merchant e-commerce site, such that the transaction is successfully concluded. - Returning the discussion now to the payment-enabled
mobile device 202, it has been noted above that in some embodiments thedevice 202 may be physically constituted by smartphone hardware. Alternatively, however, thedevice 202 may be an IC card of the type that includes a display and keyboard. In such a case, for example, thedevice 202 may communicate with theWSP computer 202 via the POI terminal In still other embodiments, the IC card need not have a keyboard or display. The IC card, which may be a contactless card or a contact card, may be in communication with the POI terminal, which may provide a user interface for the card and for selection of wallet account(s). - As used herein and in the appended claims, the term “computer” should be understood to encompass a single computer or two or more computers in communication with each other.
- As used herein and in the appended claims, the term “processor” should be understood to encompass a single processor or two or more processors in communication with each other.
- As used herein and in the appended claims, the term “memory” should be understood to encompass a single memory or storage device or two or more memories or storage devices.
- The flow charts and descriptions thereof herein should not be understood to prescribe a fixed order of performing the method steps described therein. Rather the method steps may be performed in any order that is practicable.
- As used herein and in the appended claims, the term “payment card system account” includes a credit card account or a deposit account that the account holder may access using a debit card. The terms “payment card system account” and “payment card account” are used interchangeably herein. The term “payment card account number” includes a number that identifies a payment card system account or a number carried by a payment card, or a number that is used to route a transaction in a payment system that handles debit card and/or credit card transactions. The term “payment card” includes a credit card or a debit card.
- As used herein and in the appended claims, the term “payment card system” refers to a system for handling purchase transactions and related transactions. An example of such a system is the one operated by MasterCard International Incorporated, the assignee of the present disclosure. In some embodiments, the term “payment card system” may be limited to systems in which member financial institutions issue payment card accounts to individuals, businesses and/or other organizations.
- Although the present invention has been described in connection with specific exemplary embodiments, it should be understood that various changes, substitutions, and alterations apparent to those skilled in the art can be made to the disclosed embodiments without departing from the spirit and scope of the invention as set forth in the appended claims.
Claims (23)
1. A method comprising:
receiving a first message at a wallet service provider computer, the first message including (a) transaction detail data indicative of a transaction originated at a point of interaction (POI) device, and (b) transaction context data for the transaction;
receiving a second message at the wallet service provider computer, the second message including (i) a copy of the transaction detail data, and (ii) a copy of the transaction context data;
verifying, by the wallet service provider computer, that the copy of the transaction detail data matches the transaction detail data included in the first message and that the copy of the transaction context data matches the transaction context data included in the first message.
2. The method ofclaim 1 , wherein the wallet service provider computer receives the second message via a cryptographically-secured internet communication channel between the wallet service provider computer and a server function present in a payment-enabled mobile device.
3. The method ofclaim 2 , wherein the wallet service provider computer receives the first message from an acquirer financial institution.
4. The method ofclaim 2 , wherein the wallet service provider computer receives the first message from a merchant that operates the POI device.
5. The method ofclaim 1 , wherein:
the transaction detail data includes a transaction amount and a transaction date, and
the transaction context data includes (x) merchant identification data for identifying a merchant that operates the POI device; (y) location data for identifying a location of the POI device; and (z) a unique transaction number generated for the transaction by the POI device.
6. The method ofclaim 5 , wherein the first message includes device address data that indicates an internet address for said server function present in the payment-enabled mobile device.
7. A non-transitory medium having program instructions stored thereon, the medium comprising:
an interception application software program for providing a server function for receiving service requests from a remote device; and
a contact exchange application software program for (a) exchanging communications with the interception application software program, and (b) providing contact data to a device in proximity to the medium, the contact data including (i) data that identifies a wallet service provider, and (ii) data that represents an internet address for the interception application software program.
8. The medium ofclaim 7 , further comprising:
a wallet selection application program for (x) exchanging communications with the interception application software program, and (y) receiving input from a user to select a payment card account from among a plurality of payment card accounts represented in a digital wallet maintained for the user by the wallet service provider.
9. The method ofclaim 8 , wherein the remote device is a computer operated by the wallet service provider.
10. The medium ofclaim 9 , wherein the wallet selection application software program is configured to receive from the remote device, via the interception application software program, data that represents said plurality of payment card accounts.
11. The medium ofclaim 10 , wherein the interception application software program is configured to generate and transmit to the remote device a message authentication code based at least in part on (a) said user input for payment card account selection, (b) transaction data received from the device in proximity to the medium, and (c) transaction context data received from the device in proximity to the medium.
12. The medium ofclaim 11 , wherein the contact exchange application software program is configured to receive the transaction data and the transaction context data and to provide the transaction data and the transaction context data to the interception application software program for forwarding to the remote device.
13. The medium ofclaim 12 , wherein the medium is part of a mobile device.
14. The medium ofclaim 13 , wherein the device in proximity to the medium is a point of interaction (POI) device that is in proximity to the mobile device.
15. The method ofclaim 14 , wherein the contact exchange application software program is operative to select a mode of communication between the mobile device and the POI device.
16. The method ofclaim 13 , wherein the wallet selection application program is operative to require a user of the mobile device to perform a cardholder verification method (CVM).
17. A method comprising:
receiving, in a pool account computer operated by a wallet service provider, payment network clearing credits from payment card accounts; and
distributing the payment network clearing credits, from the pool account computer, among a plurality of acquirer financial institutions, the distributed credits for further distribution from the acquirer financial institutions to merchants that accepted the payment card accounts.
18. The method ofclaim 17 , wherein the receiving step includes receiving the credits from issuers of the payment card accounts via at least one payment network clearing account.
19. The method ofclaim 17 , wherein the payment card accounts include:
a first plurality of payment card accounts issued in connection with a first payment network; and
a second plurality of payment card accounts issued in connection with a second payment network that is different from the first payment network.
20. The method ofclaim 17 , wherein the received payment network clearing credits correspond to payment network transactions for which the wallet service provider requested authorization.
21. An apparatus comprising:
a processor; and
a memory in communication with the processor, the memory storing program instructions, the program instructions controlling the processor to perform operations as follows:
receiving a first message, the first message including (a) transaction detail data indicative of a transaction originated at a point of interaction (POI) device, and (b) transaction context data for the transaction;
receiving a second message, the second message including (i) a copy of the transaction detail data, and (ii) a copy of the transaction context data; and
verifying that the copy of the transaction detail data matches the transaction detail data included in the first message and that the copy of the transaction context data matches the transaction context data included in the first message.
22. The apparatus ofclaim 21 , wherein the second message is received via a cryptographically-secured internet communication channel with a server function present in a payment-enabled mobile device.
23. The apparatus ofclaim 22 , wherein the first message is received from an acquirer financial institution.
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US14/469,380US20150254662A1 (en) | 2014-03-05 | 2014-08-26 | Verifying transaction context data at wallet service provider |
| PCT/US2015/018750WO2015134623A1 (en) | 2014-03-05 | 2015-03-04 | Verifying transaction context data at wallet service provider |
| EP15759056.3AEP3114635B1 (en) | 2014-03-05 | 2015-03-04 | Verifying transaction context data at wallet service provider |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US201461948197P | 2014-03-05 | 2014-03-05 | |
| US14/469,380US20150254662A1 (en) | 2014-03-05 | 2014-08-26 | Verifying transaction context data at wallet service provider |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| US20150254662A1true US20150254662A1 (en) | 2015-09-10 |
Family
ID=54017735
Family Applications (4)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| US14/469,304Active2036-04-11US10078835B2 (en) | 2014-03-05 | 2014-08-26 | Authentication token for wallet based transactions |
| US14/469,380AbandonedUS20150254662A1 (en) | 2014-03-05 | 2014-08-26 | Verifying transaction context data at wallet service provider |
| US14/469,346Active2037-05-15US10664833B2 (en) | 2014-03-05 | 2014-08-26 | Transactions utilizing multiple digital wallets |
| US16/103,214Active2035-09-20US11216803B2 (en) | 2014-03-05 | 2018-08-14 | Authentication token for wallet based transactions |
Family Applications Before (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| US14/469,304Active2036-04-11US10078835B2 (en) | 2014-03-05 | 2014-08-26 | Authentication token for wallet based transactions |
Family Applications After (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| US14/469,346Active2037-05-15US10664833B2 (en) | 2014-03-05 | 2014-08-26 | Transactions utilizing multiple digital wallets |
| US16/103,214Active2035-09-20US11216803B2 (en) | 2014-03-05 | 2018-08-14 | Authentication token for wallet based transactions |
Country Status (3)
| Country | Link |
|---|---|
| US (4) | US10078835B2 (en) |
| EP (3) | EP3114635B1 (en) |
| WO (3) | WO2015134615A1 (en) |
Cited By (24)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20140370879A1 (en)* | 2012-02-22 | 2014-12-18 | Qualcomm Incorporated | Proximity Application Discovery and Provisioning |
| US20160117659A1 (en)* | 2014-10-28 | 2016-04-28 | Poynt Co. | Payment terminal operation method and system therefor |
| US20160364719A1 (en)* | 2015-06-11 | 2016-12-15 | Sk Planet Co., Ltd. | User equipment for reverse nfc payment, nfc payment terminal, reverse nfc payment system comprising the same, control method thereof and non-transitory computer readable storage medium having computer program recorded thereon |
| US9544075B2 (en) | 2012-02-22 | 2017-01-10 | Qualcomm Incorporated | Platform for wireless identity transmitter and system using short range wireless broadcast |
| WO2018034805A1 (en)* | 2016-08-18 | 2018-02-22 | Mastercard International Incorporated | Method for making a transaction |
| US10078835B2 (en)* | 2014-03-05 | 2018-09-18 | Mastercard International Incorporated | Authentication token for wallet based transactions |
| CN109564659A (en)* | 2016-07-29 | 2019-04-02 | 万事达卡国际公司 | Sharing data with a card issuer via a wallet application in a payment-enabled mobile device |
| US20190108512A1 (en)* | 2017-10-11 | 2019-04-11 | Mastercard International Incorporated | Token-based web authorized split transactions |
| US10360593B2 (en) | 2012-04-24 | 2019-07-23 | Qualcomm Incorporated | Retail proximity marketing |
| US10521046B2 (en) | 2016-10-03 | 2019-12-31 | Poynt Co. | System and method for disabled user assistance |
| US10698704B1 (en) | 2019-06-10 | 2020-06-30 | Captial One Services, Llc | User interface common components and scalable integrable reusable isolated user interface |
| US20200250673A1 (en)* | 2017-03-20 | 2020-08-06 | Square, Inc. | Configuring Verification Information At Point-of-Sale Devices |
| US10755264B2 (en) | 2014-10-10 | 2020-08-25 | Mastercard Asia Pacific Pte. Ltd. | Methods and systems for secure online payment |
| US10846436B1 (en) | 2019-11-19 | 2020-11-24 | Capital One Services, Llc | Swappable double layer barcode |
| US10909544B1 (en) | 2019-12-26 | 2021-02-02 | Capital One Services, Llc | Accessing and utilizing multiple loyalty point accounts |
| US20210334800A1 (en)* | 2018-05-17 | 2021-10-28 | Standard Chartered Bank | Methods, systems, and devices for managing communication requests from a plurality of users |
| US11177956B2 (en)* | 2018-10-25 | 2021-11-16 | Advanced New Technologies Co., Ltd. | Identity authentication, number saving and sending, and number binding method, apparatus and device |
| TWI747287B (en)* | 2020-05-15 | 2021-11-21 | 華南商業銀行股份有限公司 | Transaction verification system and method |
| US11379835B2 (en)* | 2019-07-31 | 2022-07-05 | Visa International Service Association | System, method, and computer program product to ensure data integrity for conducting a payment transaction |
| US11416594B2 (en)* | 2020-04-28 | 2022-08-16 | Daon Enterprises Limited | Methods and systems for ensuring a user is permitted to use an object to conduct an activity |
| TWI789971B (en)* | 2020-05-15 | 2023-01-11 | 華南商業銀行股份有限公司 | Transaction verification system and method for cross validation |
| TWI789972B (en)* | 2020-05-15 | 2023-01-11 | 華南商業銀行股份有限公司 | Transaction verification system and method capable of suspending connection |
| US11812262B2 (en)* | 2017-12-22 | 2023-11-07 | British Telecommunications Public Limited Company | Device authentication |
| US20230394482A1 (en)* | 2015-01-19 | 2023-12-07 | Royal Bank Of Canada | Secure processing of electronic payments |
Families Citing this family (54)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9177313B1 (en)* | 2007-10-18 | 2015-11-03 | Jpmorgan Chase Bank, N.A. | System and method for issuing, circulating and trading financial instruments with smart features |
| US11210648B2 (en) | 2012-10-17 | 2021-12-28 | Royal Bank Of Canada | Systems, methods, and devices for secure generation and processing of data sets representing pre-funded payments |
| US20180253727A1 (en)* | 2016-07-02 | 2018-09-06 | Royal Bank Of Canada | Secure funding of electronic payments |
| WO2015073888A2 (en)* | 2013-11-14 | 2015-05-21 | Protean Payment, Inc. | Method for remotely controlling a reprogrammable payment card |
| US10706380B2 (en) | 2014-05-08 | 2020-07-07 | Visa International Service Association | Split shipment processing |
| JP6087884B2 (en)* | 2014-09-19 | 2017-03-01 | ヤフー株式会社 | Information providing apparatus, information providing method, and information providing program |
| EP3204903A4 (en)* | 2014-10-10 | 2018-02-21 | Royal Bank Of Canada | Systems for processing electronic transactions |
| US10262332B2 (en)* | 2014-10-30 | 2019-04-16 | San Diego County Credit Union | Integrated internet banking system and method of use |
| US11354651B2 (en) | 2015-01-19 | 2022-06-07 | Royal Bank Of Canada | System and method for location-based token transaction processing |
| GB201507047D0 (en)* | 2015-04-24 | 2015-06-10 | Visa Europe Ltd | Method of retaining transaction context |
| DE102015006907A1 (en)* | 2015-05-29 | 2016-12-01 | Giesecke & Devrient Gmbh | Terminal and method for mobile payment |
| KR101728310B1 (en)* | 2015-06-03 | 2017-04-19 | 윤태식 | A real-time sharing security system for smart phone |
| US20170061461A1 (en)* | 2015-08-26 | 2017-03-02 | Paypal, Inc. | Secondary device communications for intelligent selection of electronic sources |
| US20180285853A1 (en)* | 2015-10-12 | 2018-10-04 | Walmart Apollo, Llc | Merchant split tender systems and methods |
| US11113687B2 (en)* | 2015-12-15 | 2021-09-07 | Mastercard International Incorporated | System for performing cross card authentication using wallet transaction authentication history |
| CN108292402B (en) | 2016-02-23 | 2022-10-04 | 恩链控股有限公司 | Determination of a common secret and hierarchical deterministic keys for the secure exchange of information |
| BR112018016819A2 (en) | 2016-02-23 | 2018-12-26 | Nchain Holdings Ltd | method and systems for protecting a controlled digital resource using a distributed scatter table and ledger and a blockchain |
| MX2018010050A (en) | 2016-02-23 | 2019-01-21 | Nchain Holdings Ltd | Agent-based turing complete transactions integrating feedback within a blockchain system. |
| EP4235552A3 (en) | 2016-02-23 | 2023-09-13 | nChain Licensing AG | Methods and systems for efficient transfer of entities on a peer-to-peer distributed ledger using the blockchain |
| BR112018016234A2 (en)* | 2016-02-23 | 2019-01-02 | Nchain Holdings Ltd | computer-implemented method for controlling access to a resource, computer-based systems and method for controlling access to a digital wallet |
| SG11201806702XA (en) | 2016-02-23 | 2018-09-27 | Nchain Holdings Ltd | Personal device security using elliptic curve cryptography for secret sharing |
| CN116957790A (en) | 2016-02-23 | 2023-10-27 | 区块链控股有限公司 | Method and system for realizing universal certification of exchange on blockchain |
| JP6511201B1 (en) | 2016-02-23 | 2019-05-15 | エヌチェーン ホールディングス リミテッドＮｃｈａｉｎ Ｈｏｌｄｉｎｇｓ Ｌｉｍｉｔｅｄ | Registry and Automated Management Method for Sophisticated Trading Enforced by Blockchain |
| AU2017223138B2 (en) | 2016-02-23 | 2022-02-10 | nChain Holdings Limited | Method and system for efficient transfer of cryptocurrency associated with a payroll on a blockchain that leads to an automated payroll method and system based on smart contracts |
| EP3748903A1 (en) | 2016-02-23 | 2020-12-09 | Nchain Holdings Limited | Universal tokenisation system for blockchain-based cryptocurrencies |
| BR112018016821A2 (en) | 2016-02-23 | 2018-12-26 | Nchain Holdings Ltd | computer-implemented system and methods |
| US10943220B1 (en)* | 2016-04-28 | 2021-03-09 | Wells Fargo Bank, N.A. | Automatically processing split payments in POS device |
| US10740749B2 (en)* | 2016-06-01 | 2020-08-11 | Mastercard International Incorporated | System and method for managing a protection mechanism using a digital wallet platform |
| US10685348B2 (en)* | 2016-12-14 | 2020-06-16 | Mastercard International Incorporated | System and method for secured tax refund for cross border transactions with mobile device wallet application |
| US20180191685A1 (en)* | 2016-12-31 | 2018-07-05 | The Western Union Company | Recurring transfer notifications and secure transfers |
| US11507935B1 (en) | 2017-02-14 | 2022-11-22 | Wells Fargo Bank, N.A. | Mobile wallet card control |
| SG10201701688PA (en)* | 2017-03-02 | 2018-10-30 | Mastercard International Inc | Electronic system and method for processing merchandise purchase transactions |
| KR101837168B1 (en)* | 2017-04-18 | 2018-03-09 | 주식회사 코인플러그 | Method for approving the use of credit card by using token id based on blockchain and server using the same |
| SG10201703331TA (en)* | 2017-04-24 | 2018-11-29 | Mastercard International Inc | A digital wallet payment system and process |
| US11449935B2 (en)* | 2017-05-30 | 2022-09-20 | Episode Six Inc. | System and method for value unit conversion mediated by multiple exchange querying and evaluation |
| US10909541B1 (en)* | 2017-06-21 | 2021-02-02 | Wells Fargo Bank, N.A. | Mobile wallet application with payment receipt support |
| US11061592B2 (en) | 2017-07-31 | 2021-07-13 | Visa International Service Association | Modular data processing and storage system |
| WO2019075162A1 (en)* | 2017-10-13 | 2019-04-18 | Walmart Apollo, Llc | Open mobile payment systems and methods |
| EP3743869A4 (en)* | 2018-01-22 | 2021-10-20 | Mastercard International Incorporated | Provisioning of payment acceptance to payment account holders |
| US11144906B2 (en) | 2018-02-20 | 2021-10-12 | Visa International Service Association | Key-pad centric payments |
| US11297001B2 (en) | 2018-10-08 | 2022-04-05 | Bank Of America Corporation | Closed loop resource distribution platform |
| US11257071B2 (en)* | 2018-10-08 | 2022-02-22 | Bank Of America Corporation | Closed loop platform for dynamic currency conversion |
| US10805234B2 (en) | 2018-10-08 | 2020-10-13 | Bank Of America Corporation | Closed loop resource distribution platform zone generation and deployment |
| US11127000B2 (en)* | 2018-12-17 | 2021-09-21 | Intel Corporation | Reducing blockchain transaction delay |
| US11580543B2 (en) | 2019-01-03 | 2023-02-14 | Mastercard International Incorporated | Methods, systems and computer program products for implementing pre-authorized payment transactions |
| WO2021154270A2 (en)* | 2019-01-30 | 2021-08-05 | Lolli, Inc. | Automating digital asset transfers based on historical transactions |
| US20220300952A1 (en) | 2019-01-30 | 2022-09-22 | Lolli, Inc. | Automating digital asset transfers based on historical transactions |
| US11797980B2 (en) | 2019-05-08 | 2023-10-24 | Visa International Service Association | System and method for a cross-platform key across digital wallet providers |
| US11769132B1 (en) | 2019-05-22 | 2023-09-26 | Wells Fargo Bank, N.A. | P2P payments via integrated 3rd party APIs |
| US11750625B1 (en)* | 2019-12-11 | 2023-09-05 | Wells Fargo Bank, N.A. | Data breach monitoring and remediation |
| SG10202000987TA (en) | 2020-02-04 | 2021-09-29 | Mastercard International Inc | Method and system for open-loop person-to-person payments |
| US20230079567A1 (en)* | 2021-09-13 | 2023-03-16 | Mastercard International Incorporated | Multi-wallet community services with integrated payment services |
| US11716290B1 (en) | 2022-05-12 | 2023-08-01 | Bank Of America Corporation | Electronic system for dynamic linking of resource data structures across distributed networks |
| US20240242199A1 (en)* | 2023-01-13 | 2024-07-18 | Capital One Services, Llc | Systems and methods for enabling transaction distribution |
Citations (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20050071423A1 (en)* | 2003-09-26 | 2005-03-31 | Jaakko Rajaniemi | System, apparatus, and method for providing Web services on mobile devices |
| WO2005048082A2 (en)* | 2003-11-12 | 2005-05-26 | Exsentrik Enterprises Inc. | Electronic commercial transaction system and method |
| US20060136554A1 (en)* | 2004-12-22 | 2006-06-22 | Nokia Corporation | Information server in a communication system |
| US20060165060A1 (en)* | 2005-01-21 | 2006-07-27 | Robin Dua | Method and apparatus for managing credentials through a wireless network |
| US20130013499A1 (en)* | 2011-07-05 | 2013-01-10 | Avinash Kalgi | Electronic wallet checkout platform apparatuses, methods and systems |
| US20140006278A1 (en)* | 2012-06-28 | 2014-01-02 | Ebay Inc. | Save to open wallet |
| US20140108247A1 (en)* | 2012-10-17 | 2014-04-17 | Groupon, Inc. | Peer-To-Peer Payment Processing |
| US20140149293A1 (en)* | 2010-04-09 | 2014-05-29 | Kevin Laracey | Transaction token issuing authorities |
| US20150081538A1 (en)* | 2013-09-13 | 2015-03-19 | Toro Development Limited | Systems and methods for providing secure digital identification |
| US20150120472A1 (en)* | 2013-10-29 | 2015-04-30 | Christian Aabye | Digital wallet system and method |
| US9626672B2 (en)* | 2005-12-31 | 2017-04-18 | Michelle Fisher | Using harvested power for NFC transactions |
Family Cites Families (36)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7155411B1 (en)* | 2000-09-28 | 2006-12-26 | Microsoft Corporation | Integrating payment accounts and an electronic wallet |
| JP2003016367A (en)* | 2001-06-29 | 2003-01-17 | Oki Electric Ind Co Ltd | Prepaid electronic money-associated system and its control program |
| US20030055909A1 (en)* | 2001-08-24 | 2003-03-20 | Stephan Hartwig | Pluggable server module for wireless remote controlling of devices |
| EP1446778A2 (en)* | 2001-11-14 | 2004-08-18 | Encorus Technologies GmbH | Payment protocol and data transmission method and data transmission device for conducting payment transactions |
| FR2837042B1 (en)* | 2002-03-05 | 2005-04-08 | Cegetel Groupe | METHOD FOR OPTIMIZING NETWORK TRAFFIC AND DEVICE FOR IMPLEMENTING SAID METHOD |
| US20040019564A1 (en) | 2002-07-26 | 2004-01-29 | Scott Goldthwaite | System and method for payment transaction authentication |
| US7784684B2 (en) | 2002-08-08 | 2010-08-31 | Fujitsu Limited | Wireless computer wallet for physical point of sale (POS) transactions |
| US12260396B2 (en)* | 2010-01-08 | 2025-03-25 | Blackhawk Network, Inc. | System for payment via electronic wallet |
| US8522025B2 (en)* | 2006-03-28 | 2013-08-27 | Nokia Corporation | Authenticating an application |
| US20070265984A1 (en)* | 2006-04-24 | 2007-11-15 | Prakash Santhana | Financial transaction using mobile devices |
| US20090094123A1 (en) | 2007-10-03 | 2009-04-09 | Patrick Killian | Payment services provider methods in connection with personalized payments system |
| US8447699B2 (en)* | 2009-10-13 | 2013-05-21 | Qualcomm Incorporated | Global secure service provider directory |
| WO2011060662A1 (en)* | 2009-11-20 | 2011-05-26 | 北京飞天诚信科技有限公司 | Method for earmarking two electronic purses |
| US9596237B2 (en) | 2010-12-14 | 2017-03-14 | Salt Technology, Inc. | System and method for initiating transactions on a mobile device |
| CN106803175B (en)* | 2011-02-16 | 2021-07-30 | 维萨国际服务协会 | Snap mobile payment device, method and system |
| US20130030828A1 (en) | 2011-03-04 | 2013-01-31 | Pourfallah Stacy S | Healthcare incentive apparatuses, methods and systems |
| US8523054B2 (en)* | 2011-03-17 | 2013-09-03 | Ebay Inc. | Gift card conversion and digital wallet |
| AU2012261904A1 (en) | 2011-06-03 | 2013-11-28 | Visa International Service Association | Virtual wallet card selection apparatuses, methods and systems |
| US9355393B2 (en)* | 2011-08-18 | 2016-05-31 | Visa International Service Association | Multi-directional wallet connector apparatuses, methods and systems |
| US20130054454A1 (en) | 2011-08-18 | 2013-02-28 | Thomas Purves | Wallet Service Enrollment Platform Apparatuses, Methods and Systems |
| US10825001B2 (en)* | 2011-08-18 | 2020-11-03 | Visa International Service Association | Multi-directional wallet connector apparatuses, methods and systems |
| CA2862020C (en) | 2012-01-19 | 2018-03-20 | Mastercard International Incorporated | System and method to enable a network of digital wallets |
| US20130212024A1 (en) | 2012-02-10 | 2013-08-15 | Protegrity Corporation | Tokenization in distributed payment environments |
| US8965800B2 (en) | 2012-03-09 | 2015-02-24 | Mastercard International Incorporated | Systems, methods, and computer readable media for conducting an electronic transaction via a backend server system |
| WO2014011454A2 (en)* | 2012-07-09 | 2014-01-16 | Jvl Ventures, Llc | Systems, methods, and computer program products for integrating third party services with a mobile wallet |
| US10192216B2 (en)* | 2012-09-11 | 2019-01-29 | Visa International Service Association | Cloud-based virtual wallet NFC apparatuses, methods and systems |
| US10789585B2 (en)* | 2012-09-11 | 2020-09-29 | First Data Corporation | Systems and methods for facilitating remote authorization and payment of goods via mobile commerce |
| EP2898456A1 (en)* | 2012-09-19 | 2015-07-29 | Greenchili B.V. | Method for configuring a mobile communication device, device thus configured, method, system for authorizing transactions on an online account, and method for obtaining, by an initiating party, a permission from an authorizing party to a service provider for performing a transaction on an account of the user |
| US20140136353A1 (en)* | 2012-11-15 | 2014-05-15 | Wallaby Financial Inc. | System and method for optimizing card usage in a payment transaction |
| EP2926306A4 (en)* | 2012-11-30 | 2016-08-10 | Xromb Inc | System and method of processing payment at a point-of-sale terminal using a mobile device |
| US11423371B2 (en)* | 2013-09-04 | 2022-08-23 | Raise Marketplace, Llc | Systems and methods for managing prepaid cards in a digital wallet, including transferring value from prepaid cards and managing user selected accounts |
| US20150254645A1 (en)* | 2014-03-04 | 2015-09-10 | Bank Of America Corporation | Providing supplemental account information in digital wallets |
| US9424572B2 (en)* | 2014-03-04 | 2016-08-23 | Bank Of America Corporation | Online banking digital wallet management |
| US10078835B2 (en)* | 2014-03-05 | 2018-09-18 | Mastercard International Incorporated | Authentication token for wallet based transactions |
| US20160092859A1 (en)* | 2014-09-26 | 2016-03-31 | Apriva, Llc | System and method for facilitating a purchase transaction using beacon equipped devices |
| US20160180319A1 (en)* | 2014-12-22 | 2016-06-23 | Apriva, Llc | System and method for facilitating an online transaction with a mobile device |
- 2014
- 2014-08-26USUS14/469,304patent/US10078835B2/enactiveActive
- 2014-08-26USUS14/469,380patent/US20150254662A1/ennot_activeAbandoned
- 2014-08-26USUS14/469,346patent/US10664833B2/enactiveActive
- 2015
- 2015-03-04EPEP15759056.3Apatent/EP3114635B1/enactiveActive
- 2015-03-04WOPCT/US2015/018740patent/WO2015134615A1/enactiveApplication Filing
- 2015-03-04WOPCT/US2015/018750patent/WO2015134623A1/enactiveApplication Filing
- 2015-03-04EPEP15758355.0Apatent/EP3114634B1/enactiveActive
- 2015-03-04WOPCT/US2015/018726patent/WO2015134604A1/enactiveApplication Filing
- 2015-03-04EPEP15758196.8Apatent/EP3114633B1/enactiveActive
- 2018
- 2018-08-14USUS16/103,214patent/US11216803B2/enactiveActive
Patent Citations (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20050071423A1 (en)* | 2003-09-26 | 2005-03-31 | Jaakko Rajaniemi | System, apparatus, and method for providing Web services on mobile devices |
| WO2005048082A2 (en)* | 2003-11-12 | 2005-05-26 | Exsentrik Enterprises Inc. | Electronic commercial transaction system and method |
| US20060136554A1 (en)* | 2004-12-22 | 2006-06-22 | Nokia Corporation | Information server in a communication system |
| US20060165060A1 (en)* | 2005-01-21 | 2006-07-27 | Robin Dua | Method and apparatus for managing credentials through a wireless network |
| US9626672B2 (en)* | 2005-12-31 | 2017-04-18 | Michelle Fisher | Using harvested power for NFC transactions |
| US20140149293A1 (en)* | 2010-04-09 | 2014-05-29 | Kevin Laracey | Transaction token issuing authorities |
| US20130013499A1 (en)* | 2011-07-05 | 2013-01-10 | Avinash Kalgi | Electronic wallet checkout platform apparatuses, methods and systems |
| US20140006278A1 (en)* | 2012-06-28 | 2014-01-02 | Ebay Inc. | Save to open wallet |
| US20140108247A1 (en)* | 2012-10-17 | 2014-04-17 | Groupon, Inc. | Peer-To-Peer Payment Processing |
| US20150081538A1 (en)* | 2013-09-13 | 2015-03-19 | Toro Development Limited | Systems and methods for providing secure digital identification |
| US20150120472A1 (en)* | 2013-10-29 | 2015-04-30 | Christian Aabye | Digital wallet system and method |
Cited By (45)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20140370879A1 (en)* | 2012-02-22 | 2014-12-18 | Qualcomm Incorporated | Proximity Application Discovery and Provisioning |
| US9544075B2 (en) | 2012-02-22 | 2017-01-10 | Qualcomm Incorporated | Platform for wireless identity transmitter and system using short range wireless broadcast |
| US10419907B2 (en)* | 2012-02-22 | 2019-09-17 | Qualcomm Incorporated | Proximity application discovery and provisioning |
| US10360593B2 (en) | 2012-04-24 | 2019-07-23 | Qualcomm Incorporated | Retail proximity marketing |
| US10078835B2 (en)* | 2014-03-05 | 2018-09-18 | Mastercard International Incorporated | Authentication token for wallet based transactions |
| US11216803B2 (en) | 2014-03-05 | 2022-01-04 | Mastercard International Incorporated | Authentication token for wallet based transactions |
| US10755264B2 (en) | 2014-10-10 | 2020-08-25 | Mastercard Asia Pacific Pte. Ltd. | Methods and systems for secure online payment |
| US11468419B2 (en) | 2014-10-28 | 2022-10-11 | Poynt Llc | Payment terminal system and method of use |
| US9721247B2 (en) | 2014-10-28 | 2017-08-01 | Poynt Co. | Payment terminal system and method of use |
| USD1053245S1 (en) | 2014-10-28 | 2024-12-03 | Poynt Llc | Electronic payment terminal |
| USD1049215S1 (en) | 2014-10-28 | 2024-10-29 | Poynt Llc | Electronic payment terminal |
| US10977637B2 (en) | 2014-10-28 | 2021-04-13 | Poynt Co. | Payment terminal system and method of use |
| US9721242B2 (en)* | 2014-10-28 | 2017-08-01 | Poynt Co. | Payment terminal operation method and system therefor |
| US10453048B2 (en) | 2014-10-28 | 2019-10-22 | Poynt Co. | Payment terminal system and method of use |
| US20160117659A1 (en)* | 2014-10-28 | 2016-04-28 | Poynt Co. | Payment terminal operation method and system therefor |
| US10528934B2 (en) | 2014-10-28 | 2020-01-07 | Poynt Co. | Payment terminal system and method of use |
| US10096012B2 (en) | 2014-10-28 | 2018-10-09 | Poynt Co. | Payment terminal system and method of use |
| USD1049216S1 (en) | 2014-10-28 | 2024-10-29 | Poynt Llc | Electronic payment terminal |
| USD1061701S1 (en) | 2014-10-28 | 2025-02-11 | Poynt Llc | Electronic payment terminal |
| US20230394482A1 (en)* | 2015-01-19 | 2023-12-07 | Royal Bank Of Canada | Secure processing of electronic payments |
| US12260406B2 (en)* | 2015-01-19 | 2025-03-25 | Royal Bank Of Canada | Secure processing of electronic payments |
| US20160364719A1 (en)* | 2015-06-11 | 2016-12-15 | Sk Planet Co., Ltd. | User equipment for reverse nfc payment, nfc payment terminal, reverse nfc payment system comprising the same, control method thereof and non-transitory computer readable storage medium having computer program recorded thereon |
| CN109564659A (en)* | 2016-07-29 | 2019-04-02 | 万事达卡国际公司 | Sharing data with a card issuer via a wallet application in a payment-enabled mobile device |
| US10572934B2 (en) | 2016-08-18 | 2020-02-25 | Mastercard International Incorporated | Method for making a transaction |
| WO2018034805A1 (en)* | 2016-08-18 | 2018-02-22 | Mastercard International Incorporated | Method for making a transaction |
| US10521046B2 (en) | 2016-10-03 | 2019-12-31 | Poynt Co. | System and method for disabled user assistance |
| US10891051B2 (en) | 2016-10-03 | 2021-01-12 | Poynt Co. | System and method for disabled user assistance |
| US12387212B2 (en)* | 2017-03-20 | 2025-08-12 | Block, Inc. | Configuring verification information at point-of-sale devices |
| US20200250673A1 (en)* | 2017-03-20 | 2020-08-06 | Square, Inc. | Configuring Verification Information At Point-of-Sale Devices |
| US20190108512A1 (en)* | 2017-10-11 | 2019-04-11 | Mastercard International Incorporated | Token-based web authorized split transactions |
| US11812262B2 (en)* | 2017-12-22 | 2023-11-07 | British Telecommunications Public Limited Company | Device authentication |
| US20210334800A1 (en)* | 2018-05-17 | 2021-10-28 | Standard Chartered Bank | Methods, systems, and devices for managing communication requests from a plurality of users |
| US20220029809A1 (en)* | 2018-10-25 | 2022-01-27 | Advanced New Technologies Co., Ltd. | Identity authentication, number saving and sending, and number binding method, apparatus and device |
| US11177956B2 (en)* | 2018-10-25 | 2021-11-16 | Advanced New Technologies Co., Ltd. | Identity authentication, number saving and sending, and number binding method, apparatus and device |
| US11677555B2 (en)* | 2018-10-25 | 2023-06-13 | Advanced New Technologies Co., Ltd. | Identity authentication, number saving and sending, and number binding method, apparatus and device |
| US10698704B1 (en) | 2019-06-10 | 2020-06-30 | Captial One Services, Llc | User interface common components and scalable integrable reusable isolated user interface |
| US11379835B2 (en)* | 2019-07-31 | 2022-07-05 | Visa International Service Association | System, method, and computer program product to ensure data integrity for conducting a payment transaction |
| US20220292502A1 (en)* | 2019-07-31 | 2022-09-15 | Visa International Service Association | System, Method, and Computer Program Product to Ensure Data Integrity for Conducting a Payment Transaction |
| US11875348B2 (en)* | 2019-07-31 | 2024-01-16 | Visa International Service Association | System, method, and computer program product to ensure data integrity for conducting a payment transaction |
| US10846436B1 (en) | 2019-11-19 | 2020-11-24 | Capital One Services, Llc | Swappable double layer barcode |
| US10909544B1 (en) | 2019-12-26 | 2021-02-02 | Capital One Services, Llc | Accessing and utilizing multiple loyalty point accounts |
| US11416594B2 (en)* | 2020-04-28 | 2022-08-16 | Daon Enterprises Limited | Methods and systems for ensuring a user is permitted to use an object to conduct an activity |
| TWI789972B (en)* | 2020-05-15 | 2023-01-11 | 華南商業銀行股份有限公司 | Transaction verification system and method capable of suspending connection |
| TWI789971B (en)* | 2020-05-15 | 2023-01-11 | 華南商業銀行股份有限公司 | Transaction verification system and method for cross validation |
| TWI747287B (en)* | 2020-05-15 | 2021-11-21 | 華南商業銀行股份有限公司 | Transaction verification system and method |
Also Published As
| Publication number | Publication date |
|---|---|
| US20150254649A1 (en) | 2015-09-10 |
| EP3114634A4 (en) | 2017-11-08 |
| US10078835B2 (en) | 2018-09-18 |
| EP3114633A1 (en) | 2017-01-11 |
| WO2015134623A1 (en) | 2015-09-11 |
| US10664833B2 (en) | 2020-05-26 |
| US11216803B2 (en) | 2022-01-04 |
| EP3114635B1 (en) | 2022-07-20 |
| WO2015134604A1 (en) | 2015-09-11 |
| EP3114635A1 (en) | 2017-01-11 |
| EP3114634A1 (en) | 2017-01-11 |
| EP3114633A4 (en) | 2017-11-08 |
| EP3114635A4 (en) | 2017-11-08 |
| US20180357637A1 (en) | 2018-12-13 |
| EP3114633B1 (en) | 2022-07-06 |
| US20150254639A1 (en) | 2015-09-10 |
| WO2015134615A1 (en) | 2015-09-11 |
| EP3114634B1 (en) | 2022-04-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11216803B2 (en) | Authentication token for wallet based transactions | |
| US11978051B2 (en) | Authenticating remote transactions using a mobile device | |
| US20240362609A1 (en) | Peer-to-peer payment processing | |
| US10268810B2 (en) | Methods, apparatus and systems for securely authenticating a person depending on context | |
| US20190385160A1 (en) | System and process for on-the-fly cardholder verification method selection | |
| JP6238971B2 (en) | Method and system for wallet membership | |
| US10902423B2 (en) | Method and apparatus for streamlined digital wallet transactions | |
| US20150278811A1 (en) | Systems and Methods for Facilitating Authorisation of Payment | |
| CN109564659B (en) | Sharing data with a card issuer via a wallet application in a payment-enabled mobile device | |
| CN108027925B (en) | Card-free payment method and system using two-dimensional code | |
| CA2819936A1 (en) | Secure payment system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| AS | Assignment | Owner name:MASTERCARD INTERNATIONAL INCORPORATED, NEW YORK Free format text:ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:RADU, CRISTIAN;REEL/FRAME:033614/0556 Effective date:20140825 | |
| STPP | Information on status: patent application and granting procedure in general | Free format text:NON FINAL ACTION MAILED | |
| STPP | Information on status: patent application and granting procedure in general | Free format text:RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER | |
| STPP | Information on status: patent application and granting procedure in general | Free format text:FINAL REJECTION MAILED | |
| STPP | Information on status: patent application and granting procedure in general | Free format text:RESPONSE AFTER FINAL ACTION FORWARDED TO EXAMINER | |
| STPP | Information on status: patent application and granting procedure in general | Free format text:DOCKETED NEW CASE - READY FOR EXAMINATION | |
| STPP | Information on status: patent application and granting procedure in general | Free format text:NON FINAL ACTION MAILED | |
| STCB | Information on status: application discontinuation | Free format text:ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |