Method, customer device, and non-transitory machine-readable medium

Abstract

To provide a method, a customer device, and a non-transitory machine-readable medium that can certificate payment for a consumer wishing to pay for a commodity.SOLUTION: A method comprises the steps, by a customer terminal 102, of: determining a transaction between a customer associated with the terminal 102 and a business operator 108 associated with a business operator device; transmitting, in response to determining the transaction, a request for a token including characteristics of the transaction to a token issuing authority 250b; and displaying, upon receipt of a token including identification information identifying an access location for accessing a function of a transaction management system from the token issuing authority 250b, a quick response code encoding at least identification information for scanning by the business operator 108.SELECTED DRAWING: Figure 5

Description

[Technical field]

[0001] <CROSS REFERENCE TO RELATED APPLICATIONS> This application is based on and claims the benefit of priority to U.S. Provisional Patent Application No. 61 / 758,543, filed January 30, 2013. [Background technology]

[0002] Recently, payment systems and methods have been proposed whereby a user performs a transaction using a mobile device. In one method, as proposed by the applicant of the present invention, a user may perform a transaction using a mobile device that is equipped with a mobile payment application. In the proposed transaction, a "token" (such as a checkout token or ATM token) may be captured or communicated to the mobile device. The token is used by a transaction management system to facilitate the completion of the transaction between a user of the mobile device and a transaction location. For example, the transaction management system may use information associated with the token to identify a merchant (or consumer) associated with the transaction location and to identify in-process transaction information associated with the transaction location.

[0003] A related technology is a payment system in which a store terminal device transmits the input payment amount and store terminal device ID to a payment intermediary server, the payment intermediary server generates a transaction number for the payment amount and transmits it to the store terminal device, the store terminal device displays a Quick Response (QR) code (registered trademark) indicating the received transaction number on a display, the QR code includes the URL of the payment intermediary server and the QR code may be generated by the payment intermediary server, the user terminal device reads the QR code and accesses the payment intermediary server via the URL and transmits the transaction number contained in the QR code, and the payment intermediary server identifies transaction information from the transaction number and transmits it to the user terminal device (see, for example, Patent Document 1). [Prior art documents] [Patent documents]

[0004] [Patent Document 1] JP 2011-210171 A Summary of the Invention [Means for solving the problem]

[0005] In some embodiments of the system implemented by the applicant of the present invention, a token is used to connect two entities wishing to conduct a transaction. The described system can be used to replace the use of magnetic stripe cards and readers used in stores to tie together pending purchase transactions at checkout lines, for example in the case of purchase transactions, with proof of payment of a consumer wishing to make payment to a merchant for goods associated with the pending transaction.

[0006] The transaction may be a purchase transaction, an ATM transaction, a money transfer transaction, or an authentication transaction, a check-in process, or any other transaction that requires the exchange of information between two entities. In some embodiments, it may be a merchant and a purchaser, in other cases, it may be two people and in other cases, a person who wants to make their presence known to a retailer so that a gas pump can be automatically turned on, or so that a bartender at a bar can know to automatically prepare their favorite drink.

[0007] It would be desirable to provide a system and method in which multiple transaction management systems can be involved in a transaction. Further, it would be desirable to allow multiple entities or systems to perform different transaction management functions while still allowing users of mobile devices to perform transactions efficiently and reliably.

[0008] Additionally, it would be desirable for devices involved in a transaction to be able to easily identify, for each transaction, the appropriate transaction management system along with the correct path or communication channel to use to communicate with the appropriate transaction management system. For example, in a transaction where a mobile device captures a token associated with a point of transaction, the mobile device may perform processing to identify the appropriate transaction management system to use in the transaction based on information received from the token. As another example, in a transaction where a transaction terminal captures a checkout token from a mobile device, the transaction terminal may perform processing to identify the appropriate transaction management system to use in the transaction based on information received from the token.

[0009] A method according to one aspect of the invention includes determining, by a customer device, to initiate a transaction between a customer associated with the customer device and a merchant associated with a merchant device; in response to the determining to initiate the transaction, sending, by the customer device, a request for a token for the transaction to a transaction management system, the request including information indicative of characteristics of the transaction; receiving the token from the transaction management system, the token being generated by the transaction management system in response to the transaction management system receiving the request for the token, the token including identification information identifying an access location for accessing functionality of the transaction management system; and in response to receiving the token, displaying a Quick Response (QR) code encoding at least the identification information for scanning by the merchant device.

[0010] In one aspect of the present invention, a customer device includes a non-transitory memory storing instructions and a processor, the processor being configured to execute instructions to cause the customer device to: determine to initiate a transaction between a customer associated with the customer device and a merchant associated with a merchant device; in response to the determination of the initiation of the transaction, send a token request for a token for the transaction to a transaction management system, the token request including information about the transaction; receive the token from the transaction management system, the token being generated by the transaction management system in response to the transaction management system receiving the token request, the token including identification information indicative of a Uniform Resource Locator (URL) string or a Uniform Resource Identifier (URI) string for accessing functionality of the transaction management system; and in response to receiving the token, display a Quick Response (QR) code indicative of at least the identification information for scanning by the merchant device.

[0011]

[0013] One aspect of the present invention provides a non-transitory machine-readable medium having stored thereon machine-readable instructions for causing a processor of a customer device to perform operations including: determining to initiate a transaction between a customer associated with the customer device and a merchant associated with a merchant device; in response to determining the initiation of the transaction, sending a token request for a token for the transaction to a transaction management system, the token request including information about the transaction; receiving the token from the transaction management system, the token being generated by the transaction management system in response to the transaction management system receiving the token request, the token including identification information indicating a Uniform Resource Locator (URL) string or a Uniform Resource Identifier (URI) string for accessing functionality of the transaction management system; and in response to receiving the token, displaying a Quick Response (QR) code including at least the identification information for scanning by the merchant device. [Brief description of the drawings]

[0012] [Figure 1] FIG. 1 is a block diagram illustrating a portion of a system configured in accordance with some embodiments. [Diagram 2] 2 is a block diagram illustrating a portion of the system of FIG. 1 configured in accordance with some embodiments. [Diagram 3] FIG. 1 is a block diagram illustrating a portion of a system configured in accordance with some embodiments. [Figure 4] FIG. 2 is a block diagram illustrating a process according to some embodiments. [Diagram 5] FIG. 1 is a block diagram illustrating a portion of a system configured in accordance with some embodiments. [Figure 6] FIG. 1 is a block diagram illustrating a portion of a system configured in accordance with some embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] Embodiments of the present invention relate to systems, methods, processes, computer program codes, and means for conducting transactions. More particularly, some embodiments relate to systems, methods, processes, computer program codes, and means for operating a mobile device to conduct transactions with merchants, service providers, and other devices (such as automated teller machines or "ATMs"). For some embodiments, the systems, methods, processes, computer program codes, and means for operating a mobile device to conduct transactions include determining a transaction token issuing authority associated with a merchant or point of transaction so that the mobile device can communicate with an appropriate entity to conduct the transaction. In general, embodiments can be deployed in conjunction with systems such as those described by the inventors in the co-pending and commonly assigned applications referenced above, in which a mobile device can be used to conduct a transaction by scanning, capturing, or entering a code associated with the transaction. Features of some embodiments will be described in conjunction with a payment system in which a mobile device is used to conduct a transaction at a merchant's location or interaction location (or, in some embodiments, an ATM, kiosk, etc.).

[0014] In accordance with some embodiments, multiple transaction management systems (or remote transaction management devices) can be associated with or used in the payment system of the present invention. For example, a first merchant can utilize the services of a first transaction management system to process a transaction, while a second merchant can utilize the services of a second transaction management system to process a transaction. A consumer holding a mobile payment device having a mobile payment application in accordance with the present invention does not necessarily need to know which transaction management system each merchant uses. However, in accordance with some embodiments, the mobile payment application on the mobile device must know which transaction management system to communicate with during a transaction related to the present invention. The embodiments described herein provide techniques that allow a mobile payment application on a mobile device to determine which transaction management system to communicate with to perform a payment transaction. Furthermore, the embodiments can also be used in situations where a merchant system needs to determine the appropriate transaction management system to communicate with based on information received from the mobile device. The result is a system that allows multiple transaction management systems to participate in a payment system. Furthermore, as further described herein, there can be multiple tiers or collections of systems or entities that implement aspects of the transaction management system, each of which references other systems or entities.

[0015] In accordance with some embodiments, the functions of the transaction management system may be performed by multiple entities or systems. For example, one or more wallet issuers may perform functions such as user authentication and basic transaction management functions. One or more token issuing authorities may perform functions such as merchant authentication and basic transaction management functions. In such embodiments, when a consumer operates a mobile device to perform a transaction with a merchant, the mobile device (and / or the mobile device operating in conjunction with a wallet issuer) must determine which token issuing authority issued the token on behalf of the merchant so that the transaction can be performed between the consumer (operating the mobile device) and the merchant. Embodiments enable such transactions to be performed. Other features and advantages will become apparent from the disclosure below, in which an initial description of a transaction is provided with reference to FIG. 1 (where multiple transaction management systems may participate in the transaction). Further transaction details will be provided in FIG. 2 (where multiple transaction management systems participate). In FIG. 3, a transaction detail is described in which some of the functions of the transaction management system are performed by one or more token issuing authorities and one or more wallet issuers. A wallet registration process (which may be performed between a user wishing to configure a mobile payment application on a mobile device and a transaction management system or wallet issuer) is described in Figure 4. Further details of the transaction process are described in Figure 5 for the situation where one or more wallet issuers and one or more token issuing authorities participate in the transaction.

[0016] Several terms are used herein for convenience and ease of exposition. For example, the term "point of transaction" is generally used to refer to an entity, device, or other object with which a user operating a mobile device wishes to conduct a transaction. For example, a "point of transaction" can be an item or object, including a merchant's POS terminal, a merchant's website, an ATM, a kiosk, another individual, an item having an identifier such as a printed QR code, a wireless device such as a Bluetooth or beacon, an NFC chip, an audio device, or other device that can be used to initiate a transaction when operating in conjunction with another device, etc. Without limitation to the foregoing, for convenience as used herein, a "point of transaction" can also be referred to simply as a "merchant."

[0017] The term "token" will be used to refer to an identifier or information exchanged between devices participating in a transaction. For example, a token may be provided to a portable device by a merchant transaction location during or in connection with a transaction involving the merchant and the portable device. As another example, a token may be provided to a portable device by an ATM during or in connection with a transaction involving the ATM and the portable device. As yet another example, a token may be provided to a location of interaction by a customer to initiate a transaction. Tokens may be provided in many different forms, as described further herein. Tokens may be issued for use in a transaction in many different ways. For example, tokens may be issued, generated, or provided by a transaction management system or "token issuing authority," as described further herein.

[0018] The term "capture" may be used to refer to the act of scanning, reading, or otherwise obtaining a "token" (an identifier used to facilitate a transaction for some embodiments). The term "capture" (or "captured") is not intended to be limiting and is intended to include embodiments in which a mobile device is operated to receive a token (or data associated with a token) by keystroke, by image capture, by RFID, BLE / Bluetooth, NFC reading, and other scanning, reading, or other wired or wireless technologies described herein. For some embodiments, the term "capture" may also include any decoding or image processing of the token that may be required to retrieve or obtain information from the token.

[0019] As another example, the term "wireless" is used to refer to non-wired remote communication technologies, such as using radio frequency or other electromagnetic radiation based communication technologies (including RFID, wifi, Bluetooth / BLE, ZigBee or other technologies). Upon reading this disclosure, those skilled in the art will understand that the use of these terms is not intended to be limiting, but is for illustrative purposes.

[0020] As another example, the phrase "transaction management system" refers to a system operated by an entity to facilitate a transaction, including a mobile device and a merchant, ATM, or other device. Generally, a transaction management system can be a transaction management system such as those described in U.S. Patents Nos. 8,632,000 and 8,380,177. Generally, a transaction management system can be a system that matches in-progress transaction information received from one device (e.g., a transaction location, a mobile device, or an item) associated with a first party with information received from another device (e.g., a mobile device, a transaction location, etc.) associated with a second party. In accordance with some embodiments, the transaction management system performs the matching process at least in part using a token (e.g., a checkout token or an ATM token). Once the in-progress transaction information is matched with user information, further processing can be performed to enable selection or identification of an appropriate or desired payment account to be used to complete the transaction. In some embodiments, the transaction management system can perform other functions. For example, the transaction management system can perform user and mobile device authentication processes. The transaction management system can also be used to issue tokens for use in completing a transaction.

[0021] As used herein, a "transaction management system" can also be used to detect the presence of a user or device at a particular location and perform actions on its behalf. For example, if a user's device decides to advertise a token using Bluetooth beacon capabilities and is located near a particular retailer (where the token can be used to determine the user's location by itself or in conjunction with the positioning capabilities of the user's device), ATM, or other interaction location, the transaction management system can check in the user associated with the particular device at one or more interaction locations at the location. Checking in means that the interaction location system has received certain profile information about the user, such as name, nickname, photo, loyalty program number, and preferences for frequently purchased goods and services. Additionally, the check-in process can result in the interaction location or interaction location attendants automatically performing a transaction on the user's behalf, such as pre-authorizing a payment device to pay a predetermined amount to prompt a gas station pump (the interaction location) to begin pumping gas, or to have a bartender automatically prepare a particular drink, or to have kitchen staff prepare the user's favorite meal.

[0022] In some embodiments, the functions performed by the transaction management system may be performed by different entities. For example, as used herein, a "wallet issuer" may perform functions such as authentication of the user and mobile device along with certain transaction processing functions. As used herein, a "token issuing authority" or "token issuer" may perform functions such as authentication and communication with a merchant, ATM, or other interaction point along with certain transaction processing functions. As used herein, the phrase "directory service" may be used to refer to a service performed by or on behalf of any transaction management system, token issuing authority, and wallet issuer (or other entity). A "directory service" may provide a service that allows for lookup or mapping of functions to be performed (e.g., based on a token) to determine which entities and devices (e.g., mobile devices or merchants) should communicate with to perform transaction processing as described herein. Details of such functions will be provided further below.

[0023] Features of the present invention are described assuming use with the payment systems described in our co-pending applications referenced above, and the details of those systems will not be repeated in full here, however, embodiments of the present invention are not limited to use in conjunction with the payment systems described in our co-pending applications.

[0024] Features of some embodiments of the present invention will be described with reference to FIG. 1, which is a block diagram of a system 100 according to some embodiments. More specifically, FIG. 1 is a block diagram of a system in which multiple transaction management systems 130a-n are used. Each transaction management system 130 may perform the functions described herein or other functions in which mobile payment application transactions may be processed in situations in which different transaction systems participate. In such a system, an environment may exist in which a transaction at a first merchant may require interaction with a first transaction management system and a transaction at a second merchant may require interaction with a second transaction management system. The embodiment illustrated in FIG. 1 may enable the use of such multiple transaction management systems. Before describing how multiple transaction management systems, wallet issuers and / or token issuing authorities may be used, an overview of how transactions may be processed will be provided. Further details of different types of transactions and transaction processing may be obtained by reference to commonly assigned patents and applications, which are incorporated herein by reference.

[0025] For convenience, various transactions will be described with reference to the payment system 100 of FIG. 1 and, for simplicity, a situation in which a single transaction management system 130 is used will be described first. As shown, a payment account holder, merchant, or other user or operator (herein, a "customer") may hold or use a mobile device 102 (such as a mobile phone). The mobile device 102 has a display screen 136 and a data entry device 138 (such as a keypad or touch screen). In accordance with an embodiment of the present invention, the customer may use the mobile device 102 to conduct a transaction (such as a payment, loyalty, return, or other transaction) with a merchant 108. The merchant 108 may be a physical storefront, an electronic merchant, or a mail order and telephone ("MOTO") merchant (or any other person, entity, or object capable of initiating a transaction and / or operating with the customer and / or the customer's device). Additionally, the merchant 108 need not be a "merchant" but can be another individual (in the case of a person-to-person transaction) or a kiosk or other unattended device (such as an automated teller machine "ATM"), etc.

[0026] In a typical illustrative transaction, a customer may first purchase goods or services from a merchant 108 by bringing the goods or services to a point of sale (e.g., a physical checkout counter, an electronic shopping cart, etc., generally referred to herein as a "point of sale" or "POS"). The merchant 108 initiates the checkout transaction as normal by providing a total for the items to be purchased (e.g., by a barcode scanner, keying in item codes, etc.). The merchant (operating via a store clerk, a display screen, a customer-facing POS terminal, etc.) prompts the customer to select a payment option. In previous systems, the merchant might have prompted the customer to select "credit," "debit," or other payment options. In conjunction with the present invention, the merchant (operating via a store clerk, a display screen, a customer-facing POS terminal, etc.) can prompt the customer with those options along with mobile payment options. If the customer selects the mobile payment option, features of the present invention are utilized to process the transaction.

[0027] In some embodiments, rather than requiring the customer to select the mobile payment option by an action (such as by pressing a button on a POS terminal or by informing a store associate of the selection), the selection may be made by the customer's action of scanning, capturing, or entering a checkout identifier or "token" (as described below). For example, in such an embodiment, the act of capturing a token used in accordance with the present invention would allow the transaction to proceed in accordance with the present invention.

[0028] Once the mobile payment option is selected and a purchase total is generated, the merchant 108 sends (via path 116) a merchant payment authorization request message to the transaction management system 130. The merchant payment authorization request message may include one or more data or information related to the transaction. For example, the message may include one or more of a merchant identifier, a payment amount, and a token used to identify the merchant and the transaction for further processing, as described further herein.

[0029] A number of techniques can be used to generate or present a token. For example, in some embodiments, one or more tokens can be predefined or established for use with a given merchant 108 (e.g., the merchant 108 can have several checkout tokens available for display or presentation at the point of sale). In such embodiments, the merchant 108 will select the token to use in a given transaction. In some embodiments, such tokens can be generated or presented using a standard format. In an illustrative example, the merchant 108 can be issued or provided with a token or a predefined number sequence or range of number sequences. As a specific example, the merchant can be instructed to use a range of numbers (e.g., "00000" to "99999") along with a number sequence or usage pattern (e.g., a particular checkout token can only be used for a single valid transaction). In such embodiments, the POS system will provide the selected token to the transaction management system 130. In other embodiments, however, the token is issued or selected by the transaction management system 130 (as described further below) and provided to the merchant 108 in response to a merchant authorization request message. Those skilled in the art will appreciate that other techniques for issuing, using, and selecting tokens may be used. In some embodiments, the token is issued by a "token issuing authority," as described further below.

[0030] In accordance with some embodiments, the token is dynamically generated for each transaction. In some embodiments, the token is a static identifier associated with an individual checkout location (e.g., a particular POS terminal or location, a particular ATM machine or other device, or a small business person such as a plumber or electrician who does not have a particular checkout location, or an individual). The merchant 108 causes the token to be displayed or presented to the customer. For example, the token can be displayed on a display device associated with the merchant or pre-printed on a placard or other sign near the point of sale.

[0031] From the customer's perspective, the payment process of the present invention may begin with the customer performing an authentication process to verify his / her identity and authority to perform a transaction using the present invention. The authentication process may be performed after the customer selects a mobile payment option at the point of sale, or in some circumstances, before that. In accordance with some embodiments, the authentication process serves to authenticate the customer to the transaction management system 130. The authentication process may include the customer launching a mobile payment application or a web browser on the mobile device 102 and providing one or more credentials or items of information to the transaction management system 130 via the communication path 114. For example, the authentication process may include entering a user identifier, password, or other credentials into a login screen or other user interface displayed on the display device 136 of the mobile device 102. The transaction management system 130 compares the received information to stored information to authenticate the customer. As further described herein, different transaction management systems 130a-n may be included and different mobile devices may interact with different transaction management systems 130a-n to perform this authentication process. Further, in some embodiments, the function of performing authentication may be performed by an entity that issued the mobile payment application used by the consumer. Such an entity may be referred to herein as a "wallet issuer."

[0032] The authentication process, in some embodiments, also involves comparing one or more attributes of the mobile device 102 to a stored set of attributes collected from the mobile device 102 during a registration process (such as the process of FIG. 3). For example, the attributes can include an identifier associated with the mobile device 102 that uniquely identifies the device. In this manner, the customer is authenticated two ways: by something they know (their login credentials) and by something they have (their mobile device). Once the customer is successfully authenticated, the system has access to various attributes about the customer, including a list of payment accounts that the customer previously specified in the transaction management system 130 as part of the registration process. In some embodiments, the authentication process is performed between the mobile device 102 and the wallet issuer, as described further herein.

[0033] After a successful authentication process, the customer is prompted to scan and capture (or enter) the token from a device associated with the merchant 108 (illustrated as interaction 112 between the mobile device 102 and the merchant 108). As described further herein, the token is used to associate messages from the mobile device 102 and the merchant 108 and the transaction management system 130 so that transactions related to the present invention may be accomplished. After capturing the token, the mobile device 102 transmits the token (over communication path 114) to the transaction management system 130 in a customer transaction lookup request message. The customer transaction lookup request message includes the token captured by the mobile device 102.

[0034] In accordance with some embodiments, either a "static" token or a "dynamic" token is used. In embodiments where a "static" token is used (e.g., one that is assigned for use by a particular transaction location and does not include any variable information for each transaction), the transaction management system 130 matches the information in the customer transaction lookup request (received from the mobile device 102) with the information in the merchant payment authorization request (received from the merchant 108) by matching the token information received in each message. When a match is found, the transaction management system 130 sends a transaction details message (via path 114) to the customer's mobile device 102. The information from the transaction details message provides the customer with details about the transaction, including but not limited to the payment amount, name, and location of the merchant (information contained in or derived from the merchant payment authorization request), and / or one or more marketing messages. In addition, the transaction management system 130 also sends to the phone a list of the payment accounts the customer has registered with the system, including credit, debit, check, prepaid, and other types of accounts. The list of accounts may include all of the accounts the customer has registered with the system, or may include a subset of the accounts based on rules established by the mobile payment network operator, the merchant, the issuer of each payment account, the customer, or other entity (e.g., the list of accounts sent to the mobile device may only include accounts that can be used for the current transaction). In accordance with some embodiments, the list of accounts may include only a single account or multiple accounts. Furthermore, the list of accounts does not include the actual payment proof; rather, the actual payment proof is stored (or accessible to) the transaction management system 130 (or, in some embodiments, the wallet issuer, as described below). In this manner, the mobile device 102 does not store any critical payment account information.For example, the list of accounts may simply include an identifier (such as a proxy) that allows the transaction management system 130 or wallet issuer to identify the actual payment credentials associated with each customer's account. The customer can then see on the display 136 of the mobile device 102 the name of the merchant to which the payment is being made, the payment amount, and a list of payment accounts that can be used to make payments to the merchant 108.

[0035] In some embodiments, the merchant token can be derived from a unique identifier in the merchant payment authorization request. For example, if the merchant cannot easily modify their system to send a static token to the transaction management system 130, such derivation reduces or even eliminates the need for equipment upgrades and software changes that may be required by the merchant adopting a new payment method. The token can be derived using a mapping table that maps a merchant identifier, terminal identifier, or other information (sent by the merchant's system to the transaction management system 130) to a token. Based on the received identifier, a mapping process occurs to identify the appropriate token to be used in the payment transaction. The selected token is associated with a transaction in a merchant transaction queue at the transaction management system 130 (or at a token issuing authority, as described further below) that can be used to match transactions from a customer message queue at the transaction management system 130 (or at a wallet issuer, as described further below). One skilled in the art will appreciate that other matching and mapping techniques can also be used. In any event, a token is an identifier (consisting of a combination of letters, numbers, and / or symbols) used to associate a merchant payment authorization request with a payment authorization request received from a customer operating a mobile device associated with the present invention.

[0036] In embodiments using a “dynamic” token (e.g., the token is generated by either the merchant 108, the transaction management system 130, or a token issuing authority prior to being displayed on a display device associated with the merchant during a checkout transaction, and the token contains additional information about the transaction), the checkout process can proceed without having to send a customer transaction lookup request message to the transaction management system 130. For example, in some embodiments, some or all of the transaction details can be captured by the mobile device 102 and encoded into a dynamic token that, when processed, provides the transaction details to the mobile device 102. Further details of both “static” and “dynamic” token embodiments are described further below or included in commonly assigned applications that are incorporated herein by reference. In either case, however, the token is used to match messages from the mobile device 102 and messages from the merchant 108 in the transaction management system 130 (or a combination of a wallet issuer and token issuing authority, as described herein).

[0037] To complete a payment transaction, the customer interacts with the mobile device 102 to select the desired payment account to use in the current transaction, causing a customer payment authorization request message to be submitted to the transaction management system 130 (via path 114). In some embodiments, the transaction management system 130 sends the payment authorization request message to the customer's mobile device to allow the customer a final opportunity to confirm or cancel the payment transaction, although this step is optional. The customer's confirmation or cancellation is sent as a customer payment authorization message from the mobile device 102 to the transaction management system 130 via path 114.

[0038] Once the payment authorization message is received from the customer's mobile device, the transaction management system 130 (or, in some embodiments, a wallet issuer or other entity, as described further below) generates an authorization request message for transmission across one or more payment processing networks (not shown in FIG. 1 ) to authorize, clear, and settle the funds of the transaction. This request message includes information from the merchant payment authorization request, such as the amount of the transaction, or at least a pointer or reference to the associated merchant payment authorization request (received from the merchant 108), and a payment account identifier that identifies the payment account selected by the customer and pre-stored in the transaction management system 130 (and identified by a proxy or other identifier received from the mobile device). The authorization process is performed using standard authentication processes over one or more authentication networks (e.g., the VISANET® network operated by Visa, Inc., an automated clearing house system such as the National Automated Clearing Association (NACHA), etc., referred to simply as "payment processing" below in FIGS. 2, 3, 5, and 6). Once available funds are verified, the transaction management system sends a merchant payment authorization response message (via path 116) to the merchant and the transaction can be completed at the point of sale. The customer payment authorization response message can also be displayed to the customer at the point of sale and / or sent to the customer's mobile device.

[0039] For some embodiments, as described further below, the merchant 108 is not provided with any actual payment proof of the customer during the checkout process. Furthermore, the mobile device 102 never stores, transmits, or receives the actual payment proof. Rather, the mobile device 102 stores or has access to a proxy associated with the actual payment proof, which is used to identify the desired payment account for use in a particular transaction. The proxy is sent in a customer payment authorization request message to the transaction management system 130 (or, in some embodiments, the wallet issuer), which uses the proxy to retrieve or identify the actual payment proof associated with the selected account. The actual payment proof is sent from the transaction management system 130 (or, in some embodiments, the wallet issuer) to the account issuer or authorization agent. By ensuring that the actual payment proof is not revealed to or stored by the merchant 108 or the mobile device 102, embodiments provide greater account security and a lower likelihood of fraud or misuse.

[0040] In accordance with some embodiments, the mobile device 102 may be a smartphone or web-enabled mobile device, such as an iPhone, an Android phone, or any phone capable of accessing and displaying web content or accessing the Internet. In some embodiments, the mobile device 102 communicates with the transaction management system 130 using a cellular or wireless network. In some embodiments, the transaction management system 130 is a secure server (or a network of servers). In some embodiments, the transaction management system 130 (or, in some embodiments, a wallet issuer and / or a token issuing authority) communicates with one or more payment processing networks (not shown in FIG. 1, but shown as “Payment Processing” in FIGS. 2, 3, 5, and 6), such as the VISANET® network operated by Visa, Inc., the BANKNET® network operated by MasterCard International, Inc. The transaction management system 130 (or, in some embodiments, a wallet issuer and / or a token issuing authority) may also communicate with other financial transaction networks (e.g., ACH and EFT networks, private label networks, other payment systems such as PayPal®, etc.) so that a customer operating a mobile device 102 may perform transactions using a wide variety of different payment instruments and accounts. The transaction management system 130 (or, in some embodiments, a wallet issuer and / or a token issuing authority) may further communicate with one or more advertising or offer management networks, such as those provided by Google®, Apple®, Yahoo®, Microsoft®, etc. As described further below, data including advertisements and offers may be received from these networks and provided to customers via the mobile device 102.

[0041] In some embodiments, other devices may obtain the token and / or initiate a transaction. For example, in some embodiments, a customer operating a mobile device 102 may obtain a token and provide the token to other participants in the transaction (such as a merchant, another customer operating another mobile device, etc.) for use in a transaction. The flow of such a transaction may generally proceed as follows:

[0042] For some embodiments, a transaction (such as a payment, loyalty, or other transaction) can be performed by a consumer operating a mobile device 102 to obtain a token from the transaction management system 130 and present the token at a location of interaction (such as a merchant 108, another mobile device, etc.). For example, once the token is obtained by the mobile device 102, a mobile payment application can cause the token (or an encoded version of the token, such as a QR code) to be displayed on a display screen of the mobile device 102 and transmitted to the location of interaction, such as via a wireless communication link, for reading or capture at the location of interaction. For example, processing at the merchant 108 can proceed as follows (although other process flows can be used with preferred results):

[0043] Initially, a store associate associated with the merchant 108 scans items at a POS terminal to generate an initial basket or collection of items to be purchased by a customer operating the mobile device 102 (scanning the items can occur after a token is generated and captured, but for convenience in this illustrated embodiment, scanning the items is described as occurring first). A consumer operating a mobile device 102 configured with a payment application associated with the present invention (e.g., having registered one or more payment accounts with the transaction management system 130 via a process such as that described below with reference to FIG. 4 ) decides to use the mobile device 102 to perform a payment transaction with the merchant 108 and interacts with the mobile device 102 to request a token for use in the transaction. This request causes a message to be sent to the transaction management system 130. The message also includes information authenticating the consumer along with the consumer's mobile device (as described above), and the transaction management system 130 uses data from the message to generate a token for use in the transaction and to generate an in-flight transaction record in a transaction queue.

[0044] The transaction management system 130 causes a message to be sent to the mobile device 102 including data related to the token for use in the transaction. The mobile device 102 (under control of the payment application of the present invention) causes the token to be displayed on a display screen of the mobile device 102. The token can be displayed or presented in the form of a QR code, bar code, Bluetooth or RFID signal, etc., and the consumer is prompted to present the token to a merchant clerk or the merchant's POS system for capture. When the merchant system 108 captures the token from the mobile device 102, it associates the token with details of the transaction being processed (which can include the full amount of the transaction and other details of the items scanned) and sends a process transaction request message to the transaction management system 130 including the token information along with information about the transaction (which can include the amount of the transaction, among other information). For example, the message can include data elements including information identifying the token (received from the mobile device 102) and information identifying the cash register, POS terminal, merchant 108, location, amount of the transaction, and item details of the item purchased. The transaction management system 130 uses information from the process transaction request message to identify pending transactions in the transaction queue and to update the transaction queue.

[0045] A request message containing information about the transaction received from the merchant 108, including the amount of the transaction, is sent from the transaction management system 130 to the mobile device 102. In addition, the message may include information identifying one or more of the customer's available payment accounts that have been identified by the transaction management system 130 as available for use by the customer in the particular transaction (e.g., by applying one or more merchant-specific rules, one or more system-specific rules, and one or more customer account rules). The customer interacting with the mobile device 102 selects an available payment account from the information received from the transaction management system 130 and causes the transaction management system 130 to send a transaction confirmation message with the selected account information.

[0046] For some embodiments, some or all of these messages between the mobile device 102 and the transaction management system 130 may be sent in one or more transaction sessions. That is, session control is initiated to ensure that the same mobile device 102 both requests a token, receives information about available payment accounts, and selects the available payment accounts in a single transaction session. In this manner, embodiments ensure that different customers or users cannot reuse or copy different users' payment information. Additionally, this method ensures that the mobile device 102 that initiated the token request is the only device that can be used to make a payment for the transaction specified in the message sent from the merchant 108 to the transaction management system 130.

[0047] Upon receiving the payment account selection and confirmation of the transaction, the transaction management system 130 causes a payment authorization request message to be sent to the payment processing system (not shown in FIG. 1, but shown in FIGS. 2, 3, 5, and 6). The payment authorization request message includes the actual payment proof (identified based on information received from the mobile device 102), the amount of the transaction, and the merchant information. Upon receiving an authorization response from the payment processing system, the transaction management system 130 causes an acknowledgement message to be sent to the merchant 108 (which is also sent to the mobile device 102). The transaction in progress is also removed from the transaction queue. In this manner, a payment transaction can be performed by enabling the mobile device 102 to obtain a token for use in the transaction and provide the token to the merchant 108 for use in the transaction. This transaction process can also be used with loyalty, discount, and other types of transactions. Additionally, the process can be used to perform transactions at other types of merchant locations (including MOTO, Internet, etc.), ATM machines or kiosks, etc., and in person-to-person transactions.

[0048] 1 (and elsewhere throughout this disclosure) shows only a single mobile device 102 and merchant 108, those skilled in the art will appreciate that there may be many devices in use and many merchants using the system. Additionally, in connection with some embodiments, multiple devices of transaction management system 130 (in some embodiments, wallet issuers and token issuing authorities) are operational.

[0049] As described further below, transactions performed using embodiments of the present invention have several desirable advantages over existing payment methods. For example, a customer can use a mobile device to perform payment transactions at a wide variety of merchant locations. Additionally, a mobile device can be used to access a variety of different payment accounts held by the customer, allowing the customer to select the most appropriate or desired payment account for each transaction. Using features of the present invention, embodiments can utilize existing point of sale systems and hardware, so merchants do not need to retrofit or replace expensive hardware. Additionally, paying with embodiments of the present invention is more secure than existing payment methods, because each transaction can require authentication using two items: user information known to the customer (a user identifier and / or password or PIN) along with a unique attribute associated with the mobile device used by the customer to initiate the transaction. Other benefits and advantages will be apparent to those of skill in the art upon reading this disclosure.

[0050] For some embodiments, the system 100 includes multiple transaction management systems 130a-130n. Each (or some) merchant 108 has an association or relationship with one or more transaction management systems 130a-130n, and a customer operating a mobile device 102 need not know which transaction management system 130a-130n is participating in any given transaction. Similarly, each mobile device 102 may be in communication with several different transaction management systems 130a-130n, and a merchant or transaction location need not necessarily know which transaction management system 130a-130n was participating in any given previous transaction (until such information is ascertained during the transaction, as described herein).

[0051] As described in the co-pending application, in accordance with some embodiments, processing a purchase or other transaction involves generating, scanning, or capturing a token associated with the location of the transaction. In some embodiments, this token may be dynamically generated for use with an individual transaction at a particular merchant or location. Scanning or capturing the token by the mobile device 102 causes information to be transmitted to the transaction management system 130 for use in completing the transaction. For some embodiments, data associated with the token may be used in connection with identifying or selecting an appropriate payment account for the transaction. As described herein, data associated with the token may also be used to determine which transaction management system 130a-n the mobile device should communicate with to retrieve information about the transaction at the merchant (e.g., information identifying the payment amount, the retailer name, etc.).

[0052] For some embodiments, the mobile device 102 (or the merchant 108, in situations where a token is provided from the mobile device 102 to the merchant system during a transaction) can use any of several different methods to determine which transaction management system 130a-n should be contacted during a given transaction. For example, in some embodiments, when the mobile device 102 scans or captures the token at the point of sale, the token can include an identifier or other information that can be used by a mobile payment application to contact the appropriate transaction management system 130a-n. The identifier or other information can be, for example, a URI or URL that is encoded directly into the token and used by the mobile application on the mobile device 102 to determine the path to access the appropriate transaction management system 130a-n. As an illustrative example, the URL https: / / paydiant.com / tms / production can be included directly within the token along with the token value itself. In such embodiments, the URL or URI can be encoded using a URL encoding method such that the mobile payment application can efficiently and accurately decode the URL or URI from the token along with the token value.

[0053] As another illustrative example of information that may be included in a token, a formatted URL string may be encoded within the token for capture and processing by a mobile payment application (e.g., the URL string may be encoded into a QR code, etc.). A formatted URL string may have a structure such as: https: / / <hostname ipaddress> : <port> / <tokenissuingauthorityidentifiter> / <issuedtoken> / <transactionmetadata>An example string following this format could be: https: / / 176.64.73.134:8663 / pydt / y7uyjhd7 / USD / 3400. Transaction metadata that may be carried in this string could be, for example, (without limitation) such information: the currency of the transaction, the amount of the transaction, and a merchant identifier.

[0054] As another illustrative example of information that may be included in a token, a URI-based identifier may be encoded within the token for capture and processing by a mobile payment application (e.g., the URI-based identifier may be encoded as a QR code, etc.). The token may be an alphanumeric token such as "3ab0f564-82b5-4846-83a0-604c44989c59". This string may be used to locate the appropriate transaction management system (or wallet issuer / token issuing authority) for interaction. Identifiers in the tokenized string may also be used. For example, the tokenized string may be, as an illustrative (non-limiting) example: <tokenissuingauthorityidentifier> : <issuedtoken> : <transactionmetadata>The text can be formatted in a variety of ways, including:

[0055] In further embodiments, the token can include an identifier that is used to look up the appropriate route to reach or communicate with the appropriate transaction management system 130a-n. For example, a mobile payment application installed on the mobile device 102 can be provided with one or more identifier / route pairs in a lookup table (which can be updated or changed from time to time). For example, the mobile payment application can be stored in a table such as the following exemplary Table 1: [Table 1]

[0056] In the illustrated example of Table 1, if the mobile device 102 interacts with a merchant 108 that uses a Paydiant transaction management system 130, the token captured by the mobile device 102 from the merchant 108 may include an identifier "ABC123" along with the value of the token. When the mobile device 102 receives the token, it performs a lookup to determine that the path to use to communicate with the transaction management system is the path associated with identifier ABC123 (e.g., the appropriate path would be https: / / paydiant.com / tms / production). When the mobile device interacts with a merchant 108 that uses a Visa transaction management system 130, the token captured by the mobile device 102 from the merchant 108 may include an identifier "XYZ567" along with the value of the token. When the mobile device 102 receives the token, it performs a lookup to determine that the path to use to communicate with the transaction management system is the path associated with identifier XYZ567 (e.g., the path would be https: / / visa.com / tms / production).

[0057] In some embodiments, instead of (or in addition to) using a lookup table stored on the mobile device 102, an external service can be used to look up the appropriate route. For example, the mobile device 102 can interact with the merchant device 108 and scan or capture a token presented by the merchant. The token can be encoded to include both an identifier and a token value, and the identifier can be used as a parameter in a web service call made by the mobile device 102 to look up the route to the appropriate transaction management system 130a-n. In this manner, the mobile device 102 does not need to store or maintain a lookup table, but only needs to make a call to a predefined web service endpoint that will return route information associated with the transaction management system identifier. In some embodiments, a combination of lookup tables and web service calls can be used (e.g., if the identifier is not available or included in a lookup table stored on the mobile device 102, the mobile device 102 can make a call to a web service endpoint to look up the appropriate route information to the transaction management system 130).

[0058] In some embodiments, an entity or device (e.g., a transaction management server, a token issuing authority, etc.) can act as a directory service. For example, a token can encode or include information including a URI or URL (or other address) to a directory service. When a directory service contacts a token value associated with a transaction, the directory service can operate to identify or provide one or more other URIs, URLs (or other addresses) that can be used by a device (e.g., a mobile device 102, a merchant 108, another transaction management system 130, etc.) to obtain additional information related to or usable for the transaction. As an illustrative, but non-limiting example, a directory service contacted for a particular transaction (identified by a token value) can provide a first address from which merchant data related to the transaction can be obtained, a second address from which transaction receipt data can be obtained (e.g., after completion of the transaction), and a third address from which authorization data related to the transaction can be obtained. Each of these additional addresses can be obtained by a device or entity that has the address of a directory server along with a valid token value. In some embodiments, interactions with the directory server can be controlled (e.g., only authorized entities or devices can retrieve information from the directory service). Additional levels of relationships can also be used. For example, a token issuing authority can provide an address associated with transaction details, which can refer to other devices or entities for additional transaction details, and which can refer to additional information about the transaction.

[0059] In some embodiments, values ​​from the token itself may not be necessary to determine the appropriate transaction management system 130 to use. For example, the mobile device 102 or merchant 108 may adhere to one or more rules based on any number of factors, such as the time of day, the day of the week, the current transaction volume at the interaction location, the purchase amount, or any other factor that determines which transaction management system 130 to use. The mobile device 102 or merchant 108 may also have a default transaction management system 130 setting (which defines a default transaction management system 130 to use if a specific transaction management system 130 is not specified in association with the token), which the transaction management system 130 may be able to change based on one or more rules that evaluate data, which may include one or more data items from the token or data items from any other source.

[0060] For further embodiments, the token captured by the mobile device 102 can include an identifier that can be decoded by a mobile payment application on the mobile device 102 to derive a route to the relevant transaction management system 130a-n. For example, an algorithm could be used to convert the identifier received in the token into a route to the appropriate transaction management system 130. As an illustrative example, a simple identifier "V1P" can be used to construct a route for https: / / visa.com / 1 / production based on the following method: the "V" in the first position of the identifier maps to the domain "visa.com", the "1" in the second position of the identifier maps to a directory with the same name, and the "P" in the third position of the identifier maps to the "production" subdirectory. Similar methods and mappings can be used to generate a wide variety of URL / URI schemes, allowing the mobile payment application on the mobile device 102 to efficiently identify the correct route to communicate with the appropriate transaction management system 130. Those skilled in the art will understand, upon reading this disclosure, that other techniques can also be used to determine the appropriate path to the transaction management system.

[0061] In some embodiments, the functions performed by the transaction management system 130 may be performed by one or more entities. For example, in some embodiments, the functions performed by the transaction management system 130 may be performed by a wallet issuer and a token issuing authority. In some embodiments, the functions performed by the wallet issuer may include, for example, user management, user authentication, and some basic transaction management related functions. The functions performed by the token issuing authority may include, for example, merchant management, merchant authentication, and some basic transaction management related functions. There may be several different wallet issuers (e.g., issuing mobile wallets to multiple consumers and managing user related functions for those consumers) along with several different token issuing authorities (e.g., interacting with different merchants facilitating transactions related to the present invention). Features of such an embodiment will be described with reference to FIG. 2.

[0062] Further details of certain aspects of a system according to some embodiments of the present invention are described with reference to FIG. 2. FIG. 2 is a block diagram of an exemplary payment system network environment showing communication paths between a mobile device 202, a merchant 208, one or more transaction management systems 230, and a payment processing system 232. The mobile device 202 can be, for example, a mobile phone, a PDA, a personal computer, etc. For example, the mobile device 202 can be an Apple iPhone, a RIM BlackBerry, a mobile phone using the Google Android operating system, etc. For some embodiments, the mobile device 202 can run a payment application, causing the mobile device 202 to operate as a payment device, as described herein. In some embodiments, the mobile device 202 can access and display web content or access the Internet, such that a customer operating the mobile device 202 can interact with one or more transaction management systems 230 to initiate a transaction via a web interface.

[0063] The mobile device 202 of FIG. 2 can communicate over one or more wired and / or wireless networks 201, for example. By way of example, the wireless network can be a cellular network (represented by cell transmitter 215). The mobile device 202 can communicate over a cellular or other wireless network through a gateway 216, which can communicate with a network 214 (e.g., the Internet or other public or private network). An access point, such as access point 218, can be provided to facilitate data and other communication access to the network 214. The access point 218 can follow, for example, 802.11g (or other) communications standards. For example, in an embodiment in which the mobile device 202 runs a payment application that enables the mobile device 202 to function as a payment device in accordance with the present invention, the payment application can generate or control the communication of data over the network 201 to one or more transaction management systems 230.

[0064] In some embodiments, mobile device 202 can perform both voice and data communications over wireless network 214 via access point 218. For example, mobile device 202 can make or receive telephone calls, send and receive email, send and receive short message service ("SMS") messages, send and receive email messages, access electronic documents, send and receive streaming media, etc. over the wireless network via access point 218. Similar communications can occur over network 215.

[0065] In some embodiments, the mobile device 202 may establish communications by other means, such as, for example, a wired connection to a network, peer-to-peer communications with other devices (e.g., using a Bluetooth network, etc.). The mobile device 202 may communicate with one or more services on the network 201, such as, for example, one or more transaction management systems 230 (to create, edit, view, or change payment account settings and preferences, to make payment transactions, etc.), web 240, and other services 242. The mobile device 202 may also access other data on one or more of the wired and / or wireless networks 201. For example, content providers such as news sites, RSS feeds, websites, blogs, social networking sites, developer networks, etc. may be accessed by the mobile device 202. Such access may be provided by invocation of a web browsing function or application (e.g., a browser) in response to a customer launching a web browser application installed on the mobile device 202. In some embodiments, a user can utilize a web browser to interact with one or more transaction management systems 230 to register payment accounts, establish account preferences, conduct payment transactions, etc.

[0066] The portable device 202 has a display screen 236 and a data input device 238 (such as a keypad or touch screen or voice interface). In accordance with an embodiment of the present invention, a customer can use the portable device 202 to conduct a purchase transaction with a merchant 208 (or an ATM transaction with an ATM or any other transaction supported by the system of the present invention). The merchant 208 can be a physical storefront, an electronic transaction merchant, or a MOTO merchant (or any other person or entity). The portable device 202, in some embodiments, also has a camera (not shown) or other image capture device such that the portable device 202 can capture an image or representation of the token 210. The portable device 202, in some embodiments, also has a wireless receiver (not shown) or other wireless signal receiving device such that the portable device 202 can capture a wireless signal representation of the token 210. For example, a customer can operate the portable device 202 to take a digital photograph or capture an image of a token displayed on or at a merchant's point of sale device to initiate a payment transaction using the present invention. The captured image is shown on the display screen 236 as item 237. As explained further below, the token 210 can be used to initiate and conduct transactions with merchants.

[0067] The merchant 208 may operate one or more merchant systems 209 to process payments and transactions, including payment transactions related to the present invention (as well as "traditional" or standard payment transactions involving cash, standard payment cards, etc.), as described. The merchant system 209 may be a networked point of sale system (for a physical retailer location) or a shopping cart system (for an electronic commerce or Internet retailer location, etc.). If the "merchant" is an ATM device, the merchant system 209 may also be an ATM network, etc. The merchant system 209 may also be a combination of systems designed to allow the merchant to accept payments for merchants or services. In some embodiments, the merchant system 209 may communicate with one or more point of sale devices 212 having a display device 213 for presenting and receiving information from customers. For example, if the merchant 208 is a physical retailer location, the merchant system 209 may communicate with several different point of sale devices 212, each located at a different checkout lane or location within the store (or in different stores in different geographic locations). Each point of sale device 212 can present, display, or communicate transaction information to a customer at the point of sale (or "POS") so that the customer can authorize or approve a purchase and submit payment for the purchase.

[0068] In another example where the merchant 208 is an Internet or other electronic trading venue, the merchant system 209 can be a web server (or a network of servers, some of which are Internet accessible) configured to process purchase transactions related to the merchant 208. The point of sale device 212, in such an example, can be any number of remote terminals, such as personal computers, mobile devices, etc., that can interact with the merchant system 209 over a network, such as the Internet, that interact with the merchant system 209. Because embodiments of the present invention can initiate and conduct transactions with merchants of both physical and remote types, a point of sale, a place of purchase, or an interaction between a purchaser and a merchant can be referred to herein as a "point of sale" or "place of interaction."

[0069] In accordance with an embodiment of the present invention, the token 210 is displayed at or near the point of sale. The token can be either a "static" token or a "dynamic" token. In situations where a static token is used, the token is printed, displayed, or provided near the location of the point of sale (on a sticker or placard so that the customer can easily see, read, or capture the token). The static token 210 can be printed as a barcode image, an alphanumeric identifier, or in other forms. In some embodiments, the token can be presented in a form that is easily readable by a human so that it can both be keyed in or captured using the portable device 202. In embodiments where a static token is used, additional processing steps can be performed (as described further below) to provide the portable device 202 with detailed information regarding the transaction.

[0070] In embodiments where a dynamic token is used, the token can be displayed on a display device 213 associated with the point of sale device 212. A dynamic token can be generated to include transaction information (e.g., purchase amount) and in some embodiments can involve fewer messages between the mobile device 202 and the transaction management system 230 during a payment transaction. The token 210 can be encoded or displayed in other forms such that the token 210 can be captured as a bar code image, an alphanumeric identifier, a radio signal, or an image (e.g., using a camera or scanner associated with the mobile device 202). The token 210 can also be keyed in by the customer on the mobile device 202 or captured by a radio receiver associated with the mobile device 202. In some embodiments, a mobile device can operate with multiple types of tokens 210 (e.g., a mobile application can capture the token 210 using image capture, radio reception, or key entry depending on how the token 210 is presented at the point of sale).

[0071] The display device 213 can be an LCD (or other display technology) display (e.g., such as those currently available from many merchants on the system, such as a Hypercom 4150 terminal or a Verifone MX870 terminal). The use of the token 210 in transactions related to the present invention will be described further below. In general, however, the token 210 will be used by the transaction management system 230 to match payment requests from the mobile device with payment authorization requests from the merchant 208 to complete a payment transaction, using information stored in or accessible to the transaction management system 230. In embodiments in which the token 210 is a dynamic token, the token can also be used to communicate transaction details from the merchant 208 to the mobile device 202.

[0072] In a typical illustrative transaction, a customer may purchase goods or services from a merchant 208 by first selecting mobile payment as a payment option, completing an authentication process with a payment application on the mobile device 202 (or via a web browser interacting with the transaction management system 230), capturing a token 210 from a device associated with the merchant 208 (such as from the display 213 of the point of sale device 212), receiving transaction details and a list of payment accounts or a list of preferred or available accounts from the transaction management system 230, selecting a payment option on the mobile device 202, and submitting a customer payment authorization request over the network 201 to the transaction management system 230.

[0073] Selection of a payment option includes receiving information identifying one or more payment accounts available to the customer. The available payment accounts may be specified by the customer during a registration process, such as the process described further below in connection with FIG. 4. In some embodiments, presentation of different payment account options may include applying one or more rules or selections to the list of available payment accounts, such that the customer is presented with the accounts most suitable or available for the current transaction. The customer selects the payment account (or accounts, in the case of a compound transaction registration transaction) to use, and the information is transmitted to the transaction management system 230. In some embodiments, all of the customer's available payment accounts may be displayed to the customer after the customer is authenticated.

[0074] In some embodiments, the list of accounts subsequently received from the transaction management system 230 (after processing the customer transaction lookup request) may include additional metadata or information associated with each payment account (e.g., the currently available account balance, any special offers available if the account is used in the current transaction, etc.). In some embodiments, the list of accounts subsequently received from the transaction management system 230 may include fewer accounts based on the application of rules in the transaction management system 230 (e.g., the application of one or more customer, merchant, or system rules). For example, a rule may specify that a particular payment account should not be used for low-value transactions. In such a case, that particular payment account would not be included in the list of accounts sent from the transaction management system in response to the customer transaction lookup request. In other words, the list of payment accounts received from the transaction management system 230 after processing the customer transaction lookup request may be a subset of all accounts the customer has registered.

[0075] At substantially the same time, the merchant 208 transmits a merchant payment authorization request message across the network to the transaction management system 230. The transaction management system 230 uses the token 210 to match the customer payment authorization request (received from the mobile device 202 via network 201) with the merchant payment authorization request (received from the merchant 208 via network 220).

[0076] In some embodiments in which a dynamic token 210 is used, the transaction details need not be received by the mobile device 202 from the transaction management system 230; rather, some or all of the transaction details can be provided to the mobile device 202 via data encoded or included in the dynamic token 210. In some embodiments, the mobile device 202 requests or receives some or all of the transaction details from the transaction management system even when a dynamic token is used.

[0077] In some embodiments, the transaction management system 230 sends a customer payment confirmation request message to the customer's mobile device 202 so that the customer may be given a final opportunity to confirm or cancel the payment transaction. For example, the customer may be prompted to "confirm" or "cancel" the payment transaction. The prompt may provide additional information about the transaction and the selected payment account so that the customer has more information about the transaction before selecting "confirm" or "cancel." In some embodiments, the customer may be given the opportunity to set preferences or configure the mobile payment application to enable or disable certain messages or transaction steps. As a specific example, the customer may be given the opportunity to receive (or not receive) the customer payment confirmation request message.

[0078] Once final confirmation to proceed with payment is received from the customer's mobile device 202, the transaction management system 230 generates an authorization request message for transmission via one or more payment processing networks 232 to authorize, clear, and settle funds for the transaction. This request message includes transaction details such as the transaction amount and other information from the merchant payment authorization request (received from the merchant 208) and the actual payment proof associated with the payment account selected by the customer. The actual payment proof can be obtained by using the payment account selection information to perform a lookup of the actual payment account proof previously stored in a database or location accessible to the transaction management system 230. The authorization process can be performed using standard financial authorization processes via one or more payment processing networks 232 (e.g., the VISANET® network operated by Visa, Inc., automated clearing house systems such as NACHA, etc.). Once the availability of funds is confirmed, the transaction management system sends a merchant payment authorization response message to the merchant 208, the transaction is completed at the point of sale 212, and a customer payment authorization response message is sent to the customer's mobile device 202.

[0079] A similar process can occur as described above in a situation where the mobile device 202 is used to obtain a token from the transaction management system 230 and the merchant 208 (or another mobile device, or other interaction location device) captures the token from the mobile device 108.

[0080] In some embodiments, a payment system associated with the present invention may include multiple entities performing different processing functions typically provided by one or more of the transaction management systems described above. For example, in some situations, it may be desirable for multiple entities (referred to herein as "wallet issuers") to issue and manage mobile payment applications associated with the present invention. For example, a financial institution or other entity may choose to issue and manage the task and functionality of providing mobile payment applications to customers. This would result in multiple wallet issuers participating in the payment system of the present invention. Similarly, a financial institution or other entity may choose to provide token issuance functionality on behalf of one or more merchants. That is, the entity may have an existing relationship with the merchant and may already be integrated with or have access to the merchant's points of sale and other merchant systems. The entity may wish to provide token issuance functionality to the merchant. This would result in multiple token issuing authorities participating in the payment system of the present invention.

[0081] An exemplary system is shown in FIG. 3 similar to the system shown in FIG. 2, except that one or more token issuing authorities 250 and one or more wallet issuers 260 are shown instead of a transaction management system 230 (although in some embodiments, one or more transaction management systems 230 may still be used in the system to operate with one or more wallet issuers 260 and one or more token issuing authorities 250). As shown in FIG. 3, the wallet issuer 260 may communicate with the mobile device 202 via one or more network paths. In general, the wallet issuer 260 and each mobile device 202 operating a mobile payment application issued by the wallet issuer 260 may communicate (e.g., the mobile payment application may be coded to ensure trusted interactions and communications between the mobile device 202 and the associated wallet issuer 260). Additionally, the token issuing authority 250 may communicate with one or more merchants 208 via one or more network paths. In certain transaction embodiments and scenarios, there may also be communication between the wallet issuer 260 and the token issuing authority 250 (e.g., to complete a transaction involving both entities). Additionally, while the wallet issuer 260 is shown as communicating with one or more payment processing networks 232, in some embodiments the token issuing authority may also be in communication with one or more payment processing networks 232. Further details of transactions involving these entities will be provided below in conjunction with the description of FIG. 5.

[0082] In accordance with some embodiments, before a customer can use a mobile device (such as mobile device 202 of FIG. 3) to conduct a purchase transaction using the present invention, the customer must complete a registration process, such as the process described in connection with FIG. 4. Data collected or provided in connection with process 400 may be stored in or made accessible to one or more databases associated with a transaction management system, such as system 230. Additionally, in accordance with some embodiments, a separate wallet issuer 260 may store data collected or provided in connection with process 400.

[0083] The registration process 400 of FIG. 4 begins when a customer first interacts with a registration server (which may be a component of or associated with the transaction management system 230 of FIG. 2 or the wallet issuer of FIG. 3) to initiate the registration process. For example, the customer may operate an Internet browser (either on a mobile device or other computing device) to access a registration web page associated with the registration server or use a mobile application feature to complete the registration process. The registration web page may request the customer to provide certain information to initiate the account creation process. For example, the customer may provide name, address, other contact information, as well as contact information including one or more email addresses and phone numbers. A customer identifier or other unique record (or records) may be established in a database associated with or accessible to the transaction management system 230 or wallet issuer 260. The customer identifier may be used to uniquely identify the customer. The customer identifier may be an alphanumeric identifier assigned by the transaction management system 230 (depending on the embodiment, such as the wallet issuer 260) or information based on or provided by the customer (e.g., a mobile phone number or an identifier associated with the mobile device 202).

[0084] Processing continues at 404 where the customer establishes an account relationship with the transaction management system 230 (or wallet issuer 260, depending on the embodiment). In some embodiments, account creation includes providing contact information and identifying information associated with the customer, along with information identifying one or more mobile devices on which the customer wishes to make transactions. Each mobile device 202 is identified, for example, by a phone number and / or other unique identifier (such as a hardware serial number, an Amazon Standard Identification Number (ASIN), an advertising identifier in the case of an iPhone, a component serial number such as a CPU serial number, etc.). The customer registers from a browser on the mobile device or by first downloading a payment application having a registration module onto the mobile device. In some embodiments, the system can capture the unique identifying information associated with the mobile device (such as a hardware serial number, an ASIN, an advertising identifier, or other device identifier, etc.).

[0085] Processing continues at 406 where the customer provides information about one or more payment instruments or payment accounts that the customer wishes to associate with the payment system of the present invention. In other words, the customer provides information about one or more payment accounts with which the customer wishes to associate the customer's account relationship with the transaction management system 230 (or wallet issuer 260, depending on the embodiment). For example, the customer may enter information about one or more credit cards, debit cards, gift cards, bank accounts, checking accounts, etc. The information about each account may include actual proof of payment or sufficient information to process a transaction using that account. For example, for a credit or debit card, the information may include a primary account number (or Permanent Account Number (PAN)), an expiration date, and a verification code. For a bank account, the information may include a routing number and an account number. Other information, such as bank or issuer information, may also be entered at 406.

[0086] As an illustrative example, a customer called "Jane" has entered details for four of her payment accounts which she wishes to use in connection with the present invention. These include a Chase Credit Card with a primary account number (or PAN) of ####### and a card expiry date of 05 / 12, a Webster Bank checking account with an ABA number of ####### and an account number of ########, a Webster Bank Visa debit card with a PAN of ######## and a card expiry date of 06 / 11, and a Starbucks gift card with a PAN of ###### and an expiry date of 8 / 10. Additional account specific information may be provided as required (e.g., in some embodiments, for payment cards, a card verification number may also be provided). Data obtained during process 400 may be securely stored, for example in a PCI compliant database. In some embodiments, by securely storing payment card data (including expiry dates, verification codes), payments made using the present invention may be eligible for discount redemption as a "card present" transaction. For some embodiments, customers may be able to add, remove, or update account information as needed.

[0087] Processing continues at 408 where the customer can optionally establish one or more preferences or rules associated with the use of one or more of the accounts entered at 406. For example, the customer can designate one account as a "primary" or default account. Other rules and preferences can also be configured so that accounts are selected and used efficiently and logically. For example, the customer can specify priorities or rules based on other accounts that indicate how a particular payment account should be treated with respect to other payment accounts. The customer can also optionally specify spending limits or balance conditions that govern how and when the payment accounts should be presented. The customer can also specify the order in which accounts are displayed on the mobile phone based on which merchants they purchase from, the funds available in each account, or the rewards they receive for using each account.

[0088] In some embodiments, rules (e.g., customer-specified rules) can cause the payment process to proceed faster or with fewer customer steps. For example, a customer can specify that a default payment account should be used when making purchases at a particular merchant (certain types of purchases, such as purchases below a certain amount). In such a situation, a purchase transaction using the present invention can proceed without the customer having to select or confirm a payment account option, which is done automatically by application of the customer-specified rules.

[0089] Those skilled in the art will understand, upon reading this disclosure, that a wide variety of account-level rules can be specified to enable control of how (and when) payment accounts are presented to customers as payment options.

[0090] In the illustrative embodiment introduced above, a customer called "Jane" specified the following account preferences: (i) she wants to use less credit, and (ii) she wants to incur less transaction fees. Jane also specified rules that should be applied when a particular payment account is analyzed for use in a given transaction: (i) her Starbucks gift card balance should be used when possible (assigned the highest priority), (ii) her checking account or a debit card associated with a checking account should be used with the second highest priority (although she would prefer not to use her checking account if the transaction would reduce her balance to less than $1,000), and (iii) her credit card should be the final payment option, with the lowest priority.

[0091] When Jane uses her mobile device to perform a transaction using the present invention, the transaction management system 230 (or wallet issuer 260) will compare the transaction details to Jane's specified rules and preferences to recommend which payment accounts can be used for the transaction. For example, if Jane uses her mobile device to purchase a cup of coffee at Starbucks, the transaction management system will inform her that she can use her Starbucks gift card for the purchase. In this manner, customers with various payment accounts can be presented with a selection of payment options based on overall preferences and intended use. Furthermore, payment accounts that are not usable or suitable for a particular transaction will be identified as such by the transaction management system 230 (or wallet issuer 260) such that the customer need not be presented with such payment accounts as options (e.g., if Jane purchases gas at a gas station, she will not be presented with a Starbucks gift card as a payment account for that transaction).

[0092] In some embodiments, processing can continue at 410 if the customer operates or uses a mobile device (such as an iPhone or Android phone) capable of operating an application associated with the present invention. At 410, the customer is prompted to download and install the application onto their mobile device. The application enables the customer to operate their mobile device to quickly and easily perform payment transactions associated with the present invention. In the case of phones or devices not capable of running such applications, a link or web page can be generated or provided to the customer that can be accessed via a mobile phone browser to enable the customer to perform payment transactions associated with the present invention.

[0093] Once a customer has established an account relationship with the transaction management system 230 (or wallet issuer 260, depending on the embodiment) and registered one or more payment accounts with the transaction management system 230 (or wallet issuer 260), the customer can use the system of the present invention to perform purchase transactions at merchants that support the transactions of the present invention.

[0094] In some embodiments, such as the embodiment illustrated in FIG. 3, different entities, systems, or devices perform different transaction management functions. For example, in some embodiments, there can be multiple wallet issuers 260 and multiple token issuing authorities 250 that interact with multiple transactions involving multiple mobile devices 202 and multiple merchants 208 (or other points of interaction, such as ATMs, other mobile devices, etc.). For example, some consumers may obtain a mobile payment application on their mobile device 202 from their financial institution or other entity, which may act as a wallet issuer 260 (or use an agent that performs the functions of a wallet issuer) for these consumers. Some merchants 208 may choose to interact with some token issuing authorities 250 but not others. Alternatively, the merchant 208 may use a single token issuing authority. Each of these choices results in a combination of entities participating in a given transaction between a consumer and a merchant 208, and presents the technical challenge of ensuring that all participants are able to successfully participate in the transaction. Embodiments provide systems and methods that allow transactions to occur despite a potentially large and diverse number of participants.

[0095] Reference is now made to FIG. 5, which shows a further system diagram illustrating a portion of a system 500 in which a consumer operating a mobile device 102 performs a transaction with a merchant 108. In the illustrated system 500, the mobile device 102 operates a payment application (installed and configured via a process as shown in FIG. 4) provided by a wallet issuer 260. In the illustrated system, the merchant 108 has a relationship or interacts with one or more issuing authorities 250a-250n. For example, the merchant 108 may have a relationship with one or more entities (such as financial institutions, merchant acquirers, point of sale system vendors, etc.) that it trusts to provide tokens for transactions performed in connection with the present invention. In such a system, it would be technically difficult to enable a transaction to be performed without the features of the present invention. Details of some embodiments of enabling a transaction to be performed will be described by following the process steps shown in FIG. 5 and labeled "1" through "6". In some embodiments, although only six major interactions are shown, each interaction may include multiple messages or communications between the devices. For convenience and ease of exposition, only the high-level interactions are shown in Figure 5. However, various implementation options will be described below.

[0096] As shown, a consumer operating a mobile device 102 wishes to conduct a transaction with a merchant 108. For example, the customer is at a checkout lane of a merchant where an item they wish to purchase is being cashed by a clerk, and the customer can indicate that they wish to pay with his mobile application. Selection of the mobile payment option causes the merchant system to request a token for the transaction. In the example, the merchant 108 uses several different token issuing authorities 250a-n (e.g., the merchant 108 may use token issuing authority 250a for some types of transactions and token issuing authorities 250b and 250n for others). This is shown for illustrative purposes only. Those skilled in the art will understand after reading this disclosure that many merchants may only interact with a single token issuing authority 250.

[0097] In the illustrative embodiment depicted in FIG. 5, the merchant 108 has several relationships and in the illustrated transaction (the interaction labeled as “1”) requests issuance of a token from the token issuing authority 250b. The request can be made in a message as a merchant payment authorization request message that transmits information related to the in-progress transaction to the token issuing authority 250b. Upon receiving the merchant payment authorization request message, the token issuing authority 250b generates or identifies a token for use in the transaction. The token issuing authority 250b can also generate an in-progress transaction record associated with the token. In some embodiments, the in-progress transaction record can include information including a merchant identifier, a terminal identifier, a transaction amount, and other data related to the in-progress transaction. For some embodiments, the token generated or obtained by the token issuing authority 250b includes information that can be used to identify the token issuing authority 250b. As noted above, such information may include a formatted URL string (which in some embodiments provides the token issuing authority 250b with a URL along with other transaction related information), a URI-based identifier, a tokenized string identifier, etc. The token (including the token identifier and information identifying the token issuing authority) is sent back to the merchant 108 for presentation or communication to the mobile device 102.

[0098] Those skilled in the art will understand after reading this disclosure that in some embodiments, the tokens and information identifying the token issuing authority may also be pre-stored or made available locally at the merchant 108.

[0099] The merchant 108 can display or present the token as a QR code or via other means, and the customer can be prompted to capture the token using their mobile device 102 (shown as interaction "2"). Once captured, the mobile payment application on the mobile device 102 can be operated to decode the token to obtain the information contained therein (shown as interaction "3"). In some embodiments, token decryption can involve a collaborative process between the mobile device 102, the mobile payment application, and the wallet issuer 260 that issued the mobile payment application or another device. Token decryption can include any or all of the following: identification of the particular token issuing authority 250b that issued the token, the actual token value, and any metadata provided with the token value.

[0100] At this point in the transaction, the token issuing authority 250b has an in-progress transaction record received from the merchant 108, including details of the transaction. The in-progress transaction record can be identified using the token issued or provided by the token issuing authority 250b. However, the token issuing authority 250b may not know information about the customer or the payment mechanism used by the customer at this point. The customer (via the mobile payment application on the mobile device 102) may have information about the in-progress transaction as provided in the metadata decoded in "3" and may have the token value along with information that can be used to identify the token issuing authority 250b. The wallet issuer 260 authenticates the customer and the mobile device 102 and also has information associated with the token received or captured by the mobile device 102. Typically, at this point, the wallet issuer 260 also knows the identity of the token issuing authority 250b. The wallet issuer 260 also knows certain items of metadata associated with the transaction (if those items were provided with the token). For example, consider the illustrative example in which a token is encoded in a formatted URL string having the following format: https: / / <hostname ipaddress> : <port> / <tokenissuingauthorityidentifiter> / <issuedtoken> / <transationmetadata>The string received by the mobile device 102 at "2" and decoded at "3" may reveal a URL string formatted as follows: https: / / 176.64.73.134:8663 / pydt / y7uyjhd7 / USD / 34000 / MID01001, which allows the mobile device 102, the mobile payment application, and the wallet issuer 260 to determine that the appropriate token issuing authority 250b to interact with is accessible at https: / / 176.64.73.134:8663 and is the token issuing authority identified as "pydt". The token used to identify the transaction record being processed is "y7uyjhd7" and the transaction is for the amount of $3,400 in United States dollars at the merchant identified as "MID01001". Additionally, the wallet issuer 260 may have location and other data received from the mobile device 102.

[0101] In some embodiments, the process at "3" may not result in the mobile device 102 having transaction information. For example, in some embodiments, the token obtained at "2" from the merchant 108 may not include metadata (such as data identifying the transaction amount). In such a situation, one or more further interactions are necessary. For example, one such further interaction is shown as interaction "4" in which the mobile device 102 interacts with the wallet issuer 260 in a request for transaction details. The process at "4" may include the mobile device 102 providing the wallet issuer 260 with the token value along with information used to identify the token issuing authority 250b. The wallet issuer 260 may issue a request to the token issuing authority 250b requesting transaction details associated with the in-process transaction record associated with the token value obtained by the mobile device 102 at "2". Processing may continue at "4" (if the token obtained in "2" does not have or has insufficient metadata about the transaction) or at "3" (if the token obtained in "2" has sufficient metadata about the transaction) as described below.

[0102] On the mobile device 102, the wallet issuer 260, interacting with the mobile payment application, can proceed to perform a process to determine which of the customer's payment accounts can be used for the transaction. For example, the wallet issuer 260, storing the customer's preferences and rules, can determine that only certain of the customer's payment accounts are available for use at the merchant identified by "MID01001" (or based on the merchant type and location). The wallet issuer 260 can also determine that only certain payment accounts are available for use to complete a transaction in the amount of $3,400 in United States dollars. The wallet issuer 260 can interact with the mobile payment application to inform the customer which payment accounts are available for use in the pending transaction and to obtain the customer's selection of one or more payment accounts to use to complete the transaction.

[0103] Once the customer has selected the desired account and confirmed or accepted the transaction on the mobile device 102, processing can proceed to interaction "5" where either the mobile device 102, the wallet issuer 260, or a combination of the mobile device 102 and the wallet issuer 260 obtains transaction authorization from one or more payment processing networks 280 for the transaction and provides transaction authorization to the appropriate token issuing authority 250b. Such an interaction at "5" can include several messages. For example, once the customer has selected a desired payment account to use to complete the transaction, a message is sent to the wallet issuer 260 identifying the desired payment account (in some embodiments, the message does not include the actual payment account credentials, but rather a proxy or identifier that the wallet issuer 260 can use to look up or identify the actual payment account credentials). The wallet issuer 260 constructs a payment authorization request message with information including the actual payment account credentials (PAN, account number, verification or validation data, expiration date, etc.), the amount of the transaction, and the merchant identifier. The payment authorization request message is sent to one or more payment networks for authorization processing. If the transaction is authorized, the wallet issuer 260 may receive an authorization code and authorization response message along with the token, which is sent to the appropriate token issuing authority 250b.

[0104] Upon receiving the authorization code and authorization response, the token issuing authority 250b uses the received token to identify the transaction record in progress and performs a process (at "6") to interact with the merchant 108 to complete the transaction. For example, in the situation where a payment is authorized, the token issuing authority 250b may send information confirming that the transaction was successfully completed and the merchant 108 may cause a transaction receipt to be printed at the point of interaction. The wallet issuer 260 may also cause a transaction receipt or other information to be sent to the mobile device 106.

[0105] In some circumstances, it may be impossible for the wallet issuer 260 to obtain payment authorization from the payment processing network 280 based on the information available to the wallet issuer 260. For example, in some embodiments, the token issuing authority 250 may not provide additional metadata associated with the transaction (such as a merchant identifier and / or the transaction amount). In such cases, embodiments may be provided in which further communication between the wallet issuer 260 and the token issuing authority 250 is required. For example, in some embodiments, once the wallet issuer 260 obtains the token from the mobile device 102, the wallet issuer 260 may establish communication with the token issuing authority 250 to obtain the missing metadata (including, for example, the merchant identifier and the transaction amount). The wallet issuer 260 may proceed as described above to obtain payment authorization from the payment processing network 280.

[0106] In yet another embodiment, in a situation where the wallet issuer 260 is unable to obtain payment authorization from the payment processing network 280 based on information available to the wallet issuer 260, the token issuing authority 250 can obtain payment authorization. For example, in some embodiments, when the wallet issuer 260 identifies appropriate payment account credentials to use for a transaction, it can pass those payment account credentials to the token issuing authority 250 (along with the token), allowing the token issuing authority to construct a payment authorization message with information from the transaction record being processed along with the payment account credentials received from the wallet issuer 260. In either situation, the ability to complete the transaction is based on providing the mobile device 102 and wallet issuer 260 with information used to identify the transaction (the token) along with information used to identify the token issuing authority 250 (such as a URL, URI, or other data provided with the token).

[0107] As noted above, in some embodiments, the mobile device 102 can be operated to obtain a token, which can then be provided to the merchant 108 (or other device or participant in the transaction). In such embodiments, different entities, systems or devices can perform different transaction management functions. See FIG. 6, where one illustrative system is described. As with FIG. 5 and the embodiments above, there can be multiple wallet issuers 260 and multiple token issuing authorities 250 interacting with multiple transactions involving multiple mobile devices 202 and multiple merchants 208 (or other locations of interaction, such as ATMs, other mobile devices, etc.).

[0108] A further system diagram is shown in FIG. 6, which illustrates a portion of a system 600 in which a consumer operating a mobile device configures a transaction with a merchant 108. In the illustrated system 600, the mobile device 102 operates a payment application (installed and configured via a process as shown in FIG. 4) provided by a wallet issuer 260. In the illustrated system, the mobile device 102 obtains a token from the token issuing authority 250b (in a transaction labeled as item "1"). In some embodiments, a user and device authentication process occurs in conjunction with or prior to interaction "1" (e.g., the user and device are authenticated by the wallet issuer 260). In some embodiments, when the mobile device 102 requests a token from the token issuing authority 250b, it may also provide information that can be used by the token issuing authority 250b to communicate with the mobile device 102 (this may enable the token issuing authority 250b to send transaction details to the mobile device 102 in a message, described below and labeled as item "4") to the mobile device 102. Upon receiving the request for a token, the token issuing authority 250b can generate an in-flight transaction record associated with the token. In some embodiments, the in-flight transaction record can include information including a wallet issuer identifier (used to identify the wallet issuer 260 associated with the mobile payment application on the mobile device 102), a customer identifier, and other data associated with the in-flight transaction. In accordance with some embodiments, the token generated or obtained by the token issuing authority 250b includes information used to identify the token issuing authority 250b. As noted above, such information can include a formatted URL string (which in some embodiments provides the URL to the token issuing authority 250b along with other transaction related information), a URI-based identifier, a tokenized string identifier, etc.The token (including the token value, information identifying the token issuing authority, and in some embodiments, some additional metadata) is sent back to the mobile device 102 for presentation to or communication with the merchant 108.

[0109] The mobile device 102 can display or present the token as a QR code (or present via wireless signals such as Bluetooth, NFC, etc.), and the merchant 108 can be prompted to capture the token (e.g., with a scanner or other reader) (shown as interaction "2"). Once captured, the merchant 108 can decode the token to obtain the information contained therein (shown as interaction "3"). In some embodiments, token decoding can involve a collaborative process between the merchant 108 and another entity. The result of token decoding can be any or all of the following: Identification of the particular token issuing authority 250b that issued the token, the actual token value, and any metadata provided with the token value.

[0110] The merchant 108 may perform processing to generate and send a merchant payment authorization request message to the token issuing authority 250b identified in the token (e.g., via interaction “4”). The merchant payment authorization request message may send information related to the in-progress transaction to the token issuing authority 250b along with the token value obtained from interactions “2” and “3”. The information may include a merchant identifier, a terminal identifier, the amount of the transaction, and other data related to the in-progress transaction.

[0111] At this point in the transaction, the token issuing authority 250b has an in-progress transaction record, including information received from the mobile device 102, and in-progress transaction data, including information received from the merchant 108. The in-progress transaction record can be identified using a token value issued and provided to the mobile device 102 by the token issuing authority 250b (and communicated to the merchant 108). The token issuing authority 250b can also have information that can be used to communicate information to the mobile device 102 (e.g., including information that can communicate directly with the mobile device 102 and / or information that can communicate with the mobile device 102 via a wallet issuer 260 associated with the mobile device 102, any or all of which can be obtained through the interaction labeled as item "1"). However, the token issuing authority 250b may not have any information regarding the payment mechanism to be used by the customer at this point. Further, at this point, the mobile device 102 may not know any transaction details at all (including information related to the merchant, transaction amount, etc.). In some embodiments, the token issuing authority 250b generates a further message associated with interaction "4". The further message is a message between the token issuing authority 250b and the mobile device 102. In some embodiments, this message may be routed through the wallet issuer 260 associated with the mobile device 102 as shown in FIG. 6, while other embodiments may allow direct communication between the token issuing authority 250b and the mobile device 102.

[0112] Once the mobile device 102 (and, in some embodiments, the wallet issuer 260) has information related to the transaction being processed (including, for example, information identifying the merchant 108, the amount of the transaction, etc.), processing can continue at the interaction labeled "5."

[0113] In a process during the interaction shown as item "5," the wallet issuer 260 interacting with the mobile payment application on the mobile device 102 can proceed to perform a process to determine which of the customer's payment accounts can be used in the transaction. For example, the wallet issuer 260, storing the customer's preferences and rules, can determine that only some of the customer's payment accounts are available for use by the merchant (or based on merchant type or location). The wallet issuer 260 can interact with the mobile payment application to inform the customer which payment accounts are available for use in the transaction being processed, and can obtain the customer's selection of one or more payment accounts to use to complete the transaction.

[0114] Once the customer has selected the desired account and confirmed or accepted the transaction on the mobile device 102, interaction "5" may proceed where either the mobile device 102, the wallet issuer 260, or a combination of the mobile device 102 and the wallet issuer 260 may obtain transaction authorization for the transaction from one or more payment processing networks 280 and communicate to provide transaction authorization to the appropriate token issuing authority 250b. Such interaction at "5" may include several messages. For example, once the customer has selected the desired payment account to use to complete the transaction, a message may be sent to the wallet issuer 260 identifying the desired payment account (in some embodiments, the message does not include the actual payment account credentials, but rather a proxy or identifier that can be used by the wallet issuer 260 to look up or identify the actual payment account credentials). The wallet issuer 260 constructs a payment authorization request message with information including the actual payment account credentials (e.g., PAN, account number, confirmation or validation data, expiration date, etc.), the amount of the transaction, and the merchant identifier. The payment authorization request message is sent to one or more payment networks for authorization processing. If the transaction is authorized, the wallet issuer 260 receives an authorization code and authorization response message, which it sends along with the token to the appropriate token issuing authority 250b.

[0115] Upon receiving the authorization code and authorization response, the token issuing authority 250b performs an operation (at "6") to identify the transaction record in progress using the received token and interact with the merchant 108 to complete the transaction. For example, in the situation where a payment is authorized, the token issuing authority 250b can send information to confirm that the transaction was properly completed and the merchant 108 can cause a transaction receipt to be printed at the location of the interaction. The wallet issuer 260 can also cause a transaction receipt or other information to be sent to the mobile device 106.

[0116] In some circumstances, the wallet issuer 260 may be unable to obtain payment authorization from the payment processing network 280 based on the information available to the wallet issuer 260. For example, in some embodiments, the token issuing authority 250 may not have provided additional metadata associated with the transaction (such as the merchant identifier and / or the transaction amount) and may not have provided additional transaction information to the mobile device 102 and the wallet issuer 260 for interaction “4”. In that case, an embodiment may be provided in which further communication between the wallet issuer 260 and the token issuing authority 250 is required. For example, in some embodiments, once the wallet issuer 260 has obtained the token from the mobile device 102, the wallet issuer 260 may establish communication with the token issuing authority 250 to obtain the missing metadata (including, for example, the merchant identifier and the transaction amount). The wallet issuer 260 may then proceed as described above to obtain payment authorization from the payment processing network 280.

[0117] In yet another embodiment, for situations in which the wallet issuer 260 is unable to obtain payment authorization from the payment processing network 280 based on information available to the wallet issuer 260, the token issuing authority 250 can obtain payment authorization. For example, in some embodiments, once the wallet issuer 260 has identified the appropriate payment account credentials to use in a transaction, it passes those payment account credentials (along with the token) to the token issuing authority 250, allowing the token issuing authority to construct a payment authorization message with information from the transaction record being processed along with the payment account credentials received from the wallet issuer 260. In either situation, the ability to complete the transaction is based on providing the mobile device 102 and wallet issuer 260 with information that can be used to identify the token issuing authority 250 (such as a URL, URI, or other data provided with the token) along with information that can be used to identify the token issuing authority 250.

[0118] Embodiments allow processing to occur in systems having multiple transaction management systems, and even in systems having multiple entities performing different aspects of transaction management (such as wallet issuer and token issuance), and for a mobile device to easily and efficiently identify which transaction management system (or other device or entity) to communicate with for each particular transaction, along with a pathway or communication channel to use to interact with the associated transaction management system.

[0119] In this manner, embodiments enable a wide variety of different transaction management systems and other entities and devices to be used in the payment system of the present invention, and enable portable devices participating in the payment system to correctly identify and determine which transaction system (or other device or entity) to communicate with in order to complete a transaction related to the present invention based on information captured in the checkout token obtained at the transaction location.

[0120] The above description of the processes herein should not be construed as implying a fixed order for performing the process steps. Rather, the process steps can be performed in any order practical, including simultaneous performance of at least some steps. Although the present invention has been described in conjunction 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.< / transationmetadata> < / issuedtoken> < / tokenissuingauthorityidentifiter> < / port> < / hostname> < / transactionmetadata> < / issuedtoken> < / tokenissuingauthorityidentifier> < / transactionmetadata> < / issuedtoken> < / tokenissuingauthorityidentifiter> < / port> < / hostname>

Claims

[Claim 1] determining, by a customer device, a transaction between a customer associated with the customer device and a merchant associated with a merchant device; in response to determining the transaction, sending, by the customer device, to a transaction management system a request for a token for the transaction, the request including information indicative of a characteristic of the transaction; receiving the token from the transaction management system, the token including identification information identifying an access location for accessing functionality of the transaction management system; in response to receiving the token, displaying a quick response (QR) code encoding at least the identification information for scanning by the merchant device; The method includes:

Images