JP2020030848A - Transaction token issuing authorities - Google Patents

Abstract

To provide systems, readable media and methods for allowing payment credentials of a consumer who wishes to pay for goods.SOLUTION: An embodiment executes the steps of: receiving an encoded token; decoding the encoded token to obtain identification of a server; providing the token data to a device of another person; after the server has received a process transaction request, receiving an electronic message for identifying one or more payment accounts of a user available for the transaction, the process transaction request including the token data captured by the device and associated with transaction information and also including the transaction information; selecting one of the one or more payment accounts on the basis of input from the user; and transmitting selected one of the one or more payment accounts to the server in order to complete the transaction.SELECTED DRAWING: Figure 1

Description

<Cross-reference to related applications>
This application is based on, and claims the benefit of, priority of US Provisional Patent Application No. 61 / 758,543, filed January 30, 2013.

  Recently, payment systems and payment methods have been proposed in which a user performs a transaction using a mobile device. In some methods, such as suggested by the assignee of the present invention, a user can perform a transaction using a mobile device equipped with a mobile payment application. In the proposed transaction, a "token" (such as a checkout token or an ATM token) can be captured or communicated to the portable device. The token is used by the transaction management system to facilitate the completion of a transaction between the mobile device user and the transaction location. For example, the transaction management system may use the information associated with the token to identify a merchant (or consumer) associated with the transaction location and identify in-flight transaction information associated with the transaction location. You can do it.

  As a related technology, the store terminal device sends the payment amount and the store terminal device ID to the payment mediation server to the payment mediation server, and the payment mediation server generates a transaction number for the payment amount. Send to the store terminal device, the store terminal device displays the received QR code indicating the transaction number on the display, the QR code includes the URL of the payment mediation server, the QR code is generated by the payment mediation server The user terminal device may read the QR code, access the settlement intermediation server using the URL, transmit the transaction number included in the QR code, and the settlement intermediation server may specify and use the transaction information from the transaction number. There is a payment system for transmitting to a user terminal device (for example, see Patent Document 1)

JP 2011-210171 A

  In some embodiments of the system introduced by the assignee of the present invention, a token is used to connect two entities that want to conduct a transaction. The described system, for example, in the case of a purchase transaction, at the store, with the proof of payment of the consumer who wants to pay the merchant of the goods associated with the transaction in progress, the purchase transaction being processed It can be used to replace the use of magnetic stripe cards and readers, which are used to couple together.

  The transaction can be a purchase transaction, an ATM transaction, a remittance transaction, or an authentication transaction, a check-in process, or any other transaction that requires information to be exchanged between two entities. In some embodiments, it may be that the merchant and the purchaser, in other cases, two people, and in other cases, the gasoline pump is automatically turned on, or People who want to let retailers know about their presence so that their bartenders can automatically know to prepare their favorite drinks.

  It would be desirable to provide a system and method in which multiple transaction management systems can be involved in a transaction. In addition, it would be desirable to allow multiple entities or systems to perform different transaction management functions while allowing the user of the portable device to efficiently and reliably execute transactions.

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

  One aspect of the system according to the present invention is a system comprising: a non-transitory memory for storing instructions; and one or more hardware processors coupled to the non-transitory memory, wherein the one or more hardware processors A ware processor receiving the encoded token; decoding the encoded token to obtain token data and obtain an identity of a server used to complete the transaction; Providing the token data to another party's device; and, from the server, one or more payments of a user available for the transaction after the server receives a processing transaction request based on the identification. Receiving an electronic message identifying an account, wherein the processing transaction request comprises: a. Receiving the electronic message including the token data captured by the device and associated with transaction information; and b) the one or more payments based on input from the user. The system includes an operation comprising: selecting one of the accounts; and transmitting the selected one of the one or more payment accounts to the server to complete the transaction. A system configured to execute the instructions for execution.

  One aspect of the present invention provides a non-transitory machine-readable medium for receiving an encoded token, obtaining token data, and obtaining an identification of a server used to complete a transaction. Decoding the encoded token, providing the token data to another party's device, and from the server, after the server receives a processing transaction request based on the identification, the transaction Receiving an electronic message confirming one or more payment accounts of a user available for use, wherein the processing transaction request comprises: a) the token data captured by the device and associated with transaction information; b) transmitting the electronic message including the transaction information; Trusting, selecting one of the one or more payment accounts based on input from the user, and selecting one or more of the one or more payment accounts to complete the transaction. Non-transitory machine-readable media having stored therein machine-readable instructions executable to perform operations including sending said one of said ones to said server.

A computer-implemented method according to one aspect of the present invention is a computer-implemented method for performing a transaction involving a plurality of parties, receiving an encoded token, obtaining token data, and completing the transaction. Decoding the encoded token to obtain the identity of the server used to do so, providing the token data for electronic capture by a merchant device; and After the server receives the processing transaction request based on the identification, receiving an electronic message confirming one or more payment accounts of a user available for the transaction, wherein the processing transaction request comprises: a) Transaction information captured by the merchant device Receiving one of the electronic messages including the associated token data and b) the transaction information; and selecting one of the one or more payment accounts based on input from the user. And transmitting the selected one of the one or more payment accounts to the server to complete the transaction.

FIG. 2 is a block diagram illustrating a portion of a system configured for some embodiments. FIG. 2 is a block diagram illustrating a portion of the system of FIG. 1 configured for some embodiments. FIG. 2 is a block diagram illustrating a portion of a system configured for some embodiments. FIG. 6 is a block diagram illustrating a process for some embodiments. FIG. 2 is a block diagram illustrating a portion of a system configured for some embodiments. FIG. 2 is a block diagram illustrating a portion of a system configured for some embodiments.

  Embodiments of the present invention relate to systems, methods, processes, computer program codes and means for performing transactions. More particularly, some embodiments relate to systems, methods, and processes for operating portable devices to perform transactions with merchants, service providers, and other devices (such as automated teller machines or "ATMs"). , Computer program code and means. For some embodiments, a system, method, process, computer program code, and means for operating a mobile device to perform a transaction may allow the mobile device to communicate with an appropriate entity to perform the transaction. Preferably, this involves determining the transaction token authority authorized by the merchant or the point of transaction. In general, embodiments may be used to perform a transaction by scanning, capturing, or entering code associated with the transaction, the mobile device may be used to perform the transaction, as referenced above, both under review and common Can be deployed with the system, as described by the inventor, in an application with a unique applicant. A feature of some embodiments is that the mobile device may be used with a payment system used to perform transactions at a merchant location or at an interacting location (or, in some embodiments, an ATM, kiosk, etc.). Will be explained.

In connection with some embodiments, multiple transaction management systems (or remote transaction managers) can be associated with or used in the payment system of the present invention. For example, a first merchant utilizes services of a first transaction management system to process a transaction, while a second merchant utilizes services of a second transaction management system to process a transaction. Can be used. A consumer holding a mobile payment device having a mobile payment application according to the present invention need not necessarily know which transaction management system each merchant uses. However, in connection with some embodiments, the mobile payment application on the mobile device must know which transaction management system to communicate with during the transactions associated with 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. Further, embodiments can also be used in situations where the merchant system needs to determine an 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. Further, as described further herein, there may be multiple layers or sets of systems or entities that each implement aspects of a transaction management system that reference other systems or entities.

  In connection with some embodiments, the functions of the transaction management system can be performed by multiple entities or systems. For example, one or more wallet issuers can perform functions such as user authentication and basic transaction management functions. One or more token issuing authorities can perform functions such as vendor authentication and basic transaction management functions. In such an embodiment, when the consumer operates the mobile device to perform a transaction with the merchant, the mobile device (and / or the mobile device working with the wallet issuer) may Must operate) to determine which token-issuing authority has issued tokens on behalf of the merchant so that transactions can be performed between the consumer and the merchant. Embodiments allow such transactions to be performed. Other features and advantages will become apparent from the following disclosure, where an initial description of a transaction is provided with reference to FIG. 1 (where multiple transaction management systems can participate in the transaction). Further transaction details will be provided in FIG. 2 (with multiple transaction management systems participating). In FIG. 3, the details of a transaction are described in which some of the functions of the transaction management system are performed by one or more token issuers and one or more wallet issuers. In FIG. 4, a wallet registration process (which can be performed between a user who wants to configure a mobile payment application on a mobile device and a transaction management system or wallet issuer) is described. In FIG. 5, further details of the transaction processing are described for the situation where one or more wallet issuers and one or more token issuing authorities participate in the transaction.

  Some phrases are used herein for convenience and ease of commentary. For example, the phrase "point of transaction" is commonly used to refer to an entity, device, or other object that a user operating a portable device wants to conduct a transaction with. For example, "point of transaction" may refer to a merchant's POS terminal, merchant's website, ATM, kiosk, other individuals, items with identifiers such as printed QR codes, wireless devices such as Bluetooth, or When working with a beacon, NFC chip, audio device, or other device, it can be an item or object, including other devices that can be used to initiate a transaction. Without limitation, as used herein, for convenience, "point of transaction" may also be referred to simply as "merchant".

The phrase "token" will be used to refer to identifiers or information exchanged between devices participating in a transaction. For example, a token may be provided to a mobile device during or in connection with a transaction involving the merchant and the mobile device, depending on the location of the merchant's transaction. As another example, a token can be provided to a mobile device by an ATM during or in connection with a transaction involving the ATM and the mobile device. As yet another example, a token may be provided by a customer to an interaction location to initiate a transaction. The token can be provided in many different forms, as described further herein. Tokens can be issued for use in transactions in many different ways. For example, as described further herein, a token can be issued, generated, or provided by a transaction management system or "token issuing authority."

  The phrase "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). I can do it. The phrase “capture” (or “captured”) is not intended to be limiting, and the portable device can be configured to provide key input, image capture, RFID, BLE / Bluetooth, NFC reading, and other scanning, It is intended to include embodiments that are operated to read or receive a token (or data associated with a token) using the other wired or wireless technologies described herein. For some embodiments, the phrase “capturing” further includes any decoding or image processing of the token required to retrieve or obtain information from the token.

  As another example, the phrase "wireless" is wired, for example, using radio frequency or other electromagnetic radiation based communication technologies (including RFID, wifi, Bluetooth / BLE, ZigBee or other technologies). Used to refer to no telecommunications technology. Upon reading this disclosure, one of ordinary skill in the art would understand that the use of these phrases is not intended to be limiting but for illustrative purposes.

  As another example, the phrase "transaction management system" refers to a system operated by an entity to facilitate a transaction, including portable devices and merchants, ATMs or other devices. In general, the transaction management system can be a transaction management system as described in U.S. Patent Nos. 8,632,000 and 8,380,177. In general, a transaction management system may convert in-process transaction information received from one device associated with a first party (such as a transaction location, mobile device or item) to another device associated with a second party (such as a mobile device). System, location of the transaction, etc.). In connection with some embodiments, the transaction management system performs the matching process at least partially using a token (such as a checkout token or an ATM token). Once the transaction information being processed is matched with the user information, further processing is performed to enable selection or identification of an appropriate or desired payment account to be used to complete the transaction. I can do it. In some embodiments, the transaction management system can perform other functions. For example, the transaction management system can execute a user and mobile device authentication process. Transaction management systems can also be used to issue tokens used in performing transactions.

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 take action on its behalf. For example, a user's device may decide to advertise a token using the Bluetooth beacon feature and a particular retailer (the token may determine the user's location on its own or in conjunction with the user's device's positioning capabilities) Transaction management system, when located near an ATM or other interaction location, the user associated with a particular device at one or more of the interaction locations at that location. You can check in. 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 frequently purchased product and service preferences. In addition, the check-in process facilitates the gas station pump (interaction location) being ready to begin filling with gasoline or allowing the bartender to automatically prepare a particular drink, Alternatively, in order to allow the kitchen staff to prepare the user's favorite meal, the payment device is automatically given the authority of payment of a predetermined amount in advance, such as a place of interaction, or The clerk at the interaction location will execute the transaction on behalf of the user.

  In some embodiments, the functions performed by the transaction management system can be performed by different entities. For example, as used herein, a "wallet issuer" can perform certain transaction processing functions, as well as functions such as user and mobile device authentication. As used herein, a "token issuer" or "token issuer" may perform certain transaction processing functions, as well as perform functions such as communication and authentication with merchants, ATMs or other interaction locations. I can do it. As used herein, the phrase "directory service" refers to any service performed by or on behalf of any transaction management system, token issuing authority, and wallet issuer (or other entity). Can be used for reference. A "directory service" is executed (e.g., based on a token) to determine which entity and device (such as a mobile device or merchant) should communicate to perform the transaction processing described herein. It is possible to provide a service that enables investigation or mapping of the function to be performed. Details of such features will be provided further below.

  The features of the present invention are described assuming the use of the payment systems referred to above and in our co-pending application, the details of which are not repeated here in full. However, embodiments of the present invention are not limited to use in connection with the payment system described in our co-pending application.

  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 for some embodiments. More specifically, FIG. 1 is a block diagram of a system in which a plurality of transaction management systems 130a-n are used. Each transaction management system 130 may perform the functions described herein or other functions in which a mobile payment application transaction may be processed in situations where different transaction systems participate. In such a system, 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. There can be an environment that can require The embodiment illustrated in FIG. 1 allows for the use of multiple such transaction management systems. Before explaining how multiple transaction management systems, wallet issuers and / or token issuing authorities are used, an overview of how transactions can be processed will be provided. . Further details of different types of transactions and transaction processing can be obtained with reference to patents and applications granted to the same applicant, which are hereby incorporated by reference.

For convenience, various transactions will be described with reference to payment system 100 of FIG. 1, and for simplicity, the situation where a single transaction management system 130 is used will first be described. As shown, a payment account holder, purchaser, or other user or operator (here, a "customer") can hold or use the mobile device 102 (such as a mobile phone). The mobile device 102 has a display screen 136 and a data input device 138 (such as a keypad or touch screen). With respect to embodiments of the present invention, a customer may use mobile device 102 to perform a transaction (payment, loyalty, return, or other transaction) with merchant 108. Merchant 108 may be a physical over-the-counter, an electronic merchant, or a mail order and telephone ("MOTO") merchant (or other person or entity, or a customer and / or customer who can initiate a transaction). Any other object that can work with this device). Further, the merchant 108 need not be a "merchant", but may be another individual (in the case of a person-to-person transaction) or a kiosk or other unattended device (such as an automatic teller machine "ATM"). You can do it.

In a typical exemplary transaction, a customer first purchases a product or service at a point of sale (eg, a physical checkout counter, an electronic shopping cart, etc., generally here a "point of sale" or , "POS"), a product or service can be purchased from the trader 108. The merchant 108 initiates the checkout transaction as usual by providing a total of the items to be purchased (eg, by barcode scanner, keying in a product code, etc.). The merchant (operating through a clerk, display screen, POS terminal facing the customer, etc.) prompts the customer to select a payment option. In previous systems, merchants may have prompted customers to select "credit,""debit," or other payment options. In the context of the present invention, a merchant (operating through a clerk, display screen, POS terminal facing the customer, etc.) can prompt the customer for these 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.

  In some embodiments, rather than requiring the customer to select a mobile payment option by action (such as by pressing a button on a POS terminal or instructing a clerk to make a selection), the selection is: The checkout identifier or "token" (as described below) can be done by a customer action of scanning, capturing, or entering. For example, in such an embodiment, the act of capturing the token used in the present invention would cause the transaction to proceed in the context of the present invention.

  Once the mobile payment option has been selected and the purchase total has been generated, merchant 108 sends a merchant payment authorization request message to transaction management system 130 (via path 116). The Merchant Payment Authorization Request message can include one or more data or information about 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.

Several techniques can be used to generate or present a token. For example, in some embodiments, one or more tokens may be predefined or established for use with a given merchant 108 (eg, merchant 108 may display at a point of sale, Alternatively, you can have some checkout tokens that can be used to present). In such an embodiment, merchant 108 would select a token to use in a given transaction. In some embodiments, such tokens can be generated or presented using a standard format. In the illustrated example, the merchant 108 can be issued or provided in a range of tokens or predefined sequences or numbers. As a specific example, merchants may use a range of numbers (eg, "
00000 "to" 99999 ") (e.g., a particular checkout token can only be used for a single valid transaction). In such an embodiment, the POS system would 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 the merchant authorization request message. . One skilled in the art will appreciate that other techniques for issuing, using, and selecting tokens can be used. In some embodiments, the token is issued by a "token issuing authority", as described further below.

  In connection with some embodiments, the token is generated dynamically for each transaction. In some embodiments, the token may be used for individual checkout locations (e.g., a particular POS terminal or location, a particular ATM machine or other device, or a plumber without a particular checkout location). It is a static identifier associated with a small business person, such as an electrician, or an individual. The merchant 108 displays or presents the token 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 display near the point of sale.

  From the customer's point of view, the payment process of the present invention can begin with a customer performing an authentication process to confirm their identity and authority to perform a transaction using the present invention. The authentication process can be performed after the customer selects the mobile payment option at the point of sale, or, in some circumstances, before. In connection with some embodiments, the authentication process contributes to authenticating the customer to the transaction management system 130. The authentication process includes the customer launching a mobile payment application or 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. Can be done. 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 with the 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 has issued a mobile payment application for use by a consumer. Such an entity may be referred to herein as a "wallet issuer."

  The authentication process may, in some embodiments, also include storing one or more attributes of the mobile device 102 and attributes collected from the mobile device 102 during the registration process (such as the process of FIG. 3). Includes comparison with sets. For example, the attributes can include an identifier associated with the mobile device 102 that uniquely identifies the device. Thus, the customer is authenticated in two directions by something he knows (login credentials) and something he has (portable device). Upon successful authentication of the customer, the system has access to various attributes about the customer, including a list of payment accounts, previously identified by the customer 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.

After a successful authentication process, the customer is prompted to scan and capture (or enter) a token from a device associated with merchant 108 (shown as interaction 112 between portable device 102 and merchant 108). Has been). As described further herein, the token is used to associate messages from the portable device 102 with the merchant 108 and the transaction management system 130 such that a transaction in accordance with the present invention is accomplished. After capturing the token, the mobile device 102 sends the token (across the communication path 114) to the transaction management system 130 in a customer transaction retrieval request message. The customer transaction search request message includes the token captured by the mobile device 102.

  In connection with some embodiments, either a "static" token or a "dynamic" token is used. In embodiments where a “static” token is used (eg, 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 search request (received from the mobile device 102) with the information in the merchant payment authorization request (received from the merchant 108) to match the token information received in each message. By doing so. If there is a match, the transaction management system 130 sends a transaction detail message (via path 114) to the customer's mobile device 102. Information from the transaction detail message includes details about the transaction, including, but not limited to, payment amount, name, and merchant location (information included in or derived from the merchant payment authorization request), Alternatively, providing one or more marketing messages to the customer. In addition, the transaction management system 130 also sends the telephone a list of payment accounts that the customer has registered with the system, including credits, debits, checks, prepaid and other types of accounts. The list of accounts may include all of the accounts that the customer has registered with the system, or may include portions of the account based on rules established by the mobile payment network operator, merchant, issuer of each payment account, customer or other entity. A set may be included (eg, the list of accounts sent to the mobile device only includes accounts that can be used for the current transaction). In some embodiments, the list of accounts can include only a single account or multiple accounts. Further, the list of accounts does not include the actual payment proof, but rather the actual payment proof is provided to the transaction management system 130 (or, in some embodiments, the wallet issuer, as described below). Stored (or accessible). In this way, portable device 102 does not store important payment account information. For example, the list of accounts may simply include an identifier (such as a proxy) to enable the transaction management system 130 or the wallet issuer to identify the actual proof of payment associated with each customer account. I can do it. Here, the customer can see on the display 136 of the mobile device 102 the name of the merchant to pay, the amount paid, and a list of payment accounts that can be used to pay the merchant 108.

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 change the system to send a static token to the transaction management system 130, such derivation may be required by the merchant adopting a new payment method. No, reduce or even eliminate the need for equipment upgrades and software changes. The token can be derived using a mapping table that maps the merchant identifier, terminal identifier or other information (sent by the merchant system to the transaction management system 130) to the 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 may be used to match a transaction from the customer message queue at the transaction management system 130 (or, as described below, at the wallet issuer), at the transaction management system 130 ( Alternatively, it is associated with a transaction in the merchant transaction queue (at the token 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, the token is an identifier (from 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 portable device associated with the present invention. ).

  (E.g., a token is generated by either merchant 108, transaction management system 130, or a token issuing authority before being displayed on a display device associated with the merchant during a checkout transaction, and In embodiments using a "dynamic" token (where the token includes additional information about the transaction), the checkout process may proceed without having to send a customer transaction search request message to the transaction management system 130. I can do it. For example, in some embodiments, some or all of the transaction details are encoded in a dynamic token that provides the transaction details to the mobile device 102 when captured and processed by the mobile device 102. Rukoto can. Further details of embodiments of both "static" and "dynamic" tokens are described further below, or included in commonly assigned applications, incorporated herein by reference. . However, in each case, the token converts the message from the mobile device 102 and the message from the merchant 108 to the transaction management system 130 (or a combination of a wallet issuer and a token issuing authority, as described herein). ) Is used for matching processing.

  To complete the payment transaction, the customer interacts with the mobile device 102 to select a desired payment account to use in the current transaction, and the customer payment authorization request message is sent (via path 114). It is submitted to the management system 130. In some embodiments, the transaction management system 130 sends a payment authorization request message to the customer's mobile device, allowing the customer to be given the last opportunity to confirm or cancel the payment transaction, The steps are optional. The confirmation or cancellation of the customer is sent from the mobile device 102 to the transaction management system 130 via the path 114 as a customer payment authorization message.

Upon receipt of the payment authorization message from the customer's mobile device, the transaction management system 130 (or, in some embodiments, as described further below, the wallet issuer or other entity) may initiate the transaction. An authorization permission request message is generated for transmission over one or more payment processing networks (not shown in FIG. 1) to authorize, clear, and close the funds. The request message may be the transaction amount, or at least a pointer or reference to the relevant merchant payment authorization request (received from merchant 108), and may be selected by the customer, pre-stored in the transaction management system 130, and Includes information from the merchant payment authorization request, such as a payment account identifier identifying a payment account (identified by a proxy or other identifier received from the device). The authorization authorization process is a standard authentication process on one or more authentication networks (eg, VISANET operated by Visa, hereinafter referred to simply as “payment process” in FIGS. 2, 3, 5, and 6). (Registered trademark) network, automatic clearing house system such as National Automated Payment Association (NACHA), etc.). Once the available funds are confirmed, the transaction management system sends the merchant a payment authorization response message (via path 116) and the transaction can be completed at the point of sale. The customer payment authorization response message may also be displayed to the customer at the point of sale and / or sent to the customer's mobile device.

  For some embodiments, merchant 108 is not provided with any actual proof of payment of the customer during the checkout process, as described further below. Further, the portable device 102 never stores, sends or receives actual payment credentials. Rather, the mobile device 102 stores or has access to the proxy associated with the actual payment credentials, 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), and the transaction management system 130 (or, in some embodiments, the wallet issuer). Uses a proxy to retrieve or identify the actual proof of payment 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 proof of payment is not revealed or stored on the merchant 108 or the mobile device 102, embodiments can provide stronger account security and lower the likelihood of fraud or fraud. I will provide a.

In some embodiments, the mobile device 102 can access, display, or access the Internet, for example, an iPhone®, Android® phone, or web content. It can be a smartphone such as an arbitrary telephone or a portable device capable of browsing the web. In some embodiments, mobile device 102 communicates with transaction management system 130 using a mobile or wireless network. In some embodiments, the transaction management system 130 is a secure server (or network of servers). In some embodiments, the transaction management system 130 (or in some embodiments, a wallet issuer and / or a token issuing authority) is a VISANET network operated by Visa, Inc. One or more payment processing networks, such as the BANKNET® network operated by MasterCard International (not shown in FIG. 1, but shown in FIGS. 2, 3, 5, and 6 as "payment processing") Communication). The transaction management system 130 (or, in some embodiments, the wallet issuer and / or the token issuing authority) allows a customer operating the mobile device 102 to use a wide variety of different forms of payment devices and accounts. It can also communicate with other financial transaction networks (such as ACH and EFT networks, private label networks, and other payment systems such as PayPal®) so that transactions can be performed. The transaction management system 130 (or, in some embodiments, the wallet issuer and / or the authority to issue tokens) may further include Google (R), Apple (R), Yahoo (R), Microsoft (R) It can communicate with one or more advertising or provisioning management networks, such as those provided by TM. As described further below, data, including advertisements and offers, can be received from those networks and provided to customers via the mobile device 102.

  In some embodiments, other devices can obtain the token and / or initiate a transaction. For example, in some embodiments, a customer operating a mobile device 102 obtains a token for use in a transaction and allows other participants of the transaction (eg, merchants, other customers operating other mobile devices). Etc.) can be provided with that token. The flow of such a transaction can generally proceed as follows.

For some embodiments, a transaction (such as a payment, loyalty or other transaction) obtains a token from the transaction management system 130 and presents the token to the interaction location (merchant 108, other mobile device, etc.). To be performed by a consumer operating the portable device 102. For example, once the token is obtained by the mobile device 102, the mobile payment application may require that the token (or an encoded version of the token, such as a QR code) be read or captured at the location of the interaction. , May be displayed on the display screen of the portable device 102 and transmitted to the interaction location via a wireless communication link or the like. For example, the processing at merchant 108 can proceed as follows (although other processing flows can be used with favorable results).

Initially, the clerk associated with the merchant 108 scans the item at the POS terminal and creates an initial basket or collection of items to be purchased by the customer operating the mobile device 102 (scanning the item generates a token And scanning, and can occur after being captured, but in this illustrative embodiment, for convenience, scanning an item will be described as occurring first). Operate the mobile device 102 configured with the payment application associated with the present invention (e.g., one or more transactions management system 130 via a process as described below with reference to FIG. 4). The consumer (who has registered the payment account) decides to use the mobile device 102 to perform a payment transaction with the merchant 108 and communicates with the mobile device 102 to request a token for use in the transaction. Interact. This request causes the transaction management system 130 to send the message. The message also includes information that authenticates the consumer (as described above), along with the consumer's portable device, and the transaction management system 130 generates a token for use in the transaction and creates a token in the transaction queue. Use the data from the message to generate a transaction record in progress.

Transaction management system 130 causes mobile device 102 to send a message containing data related to the token for use in the transaction. The mobile device 102 (under the control of the payment application of the present invention) causes the token to be displayed on the display screen of the mobile device 102. The token can be displayed or presented in the form of a QR code, barcode, Bluetooth or RFID signal, etc., and the consumer presents the token to the merchant clerk or the merchant POS system for capture You will be prompted to do so. When the merchant system 108 captures the token from the mobile device 102, it associates the token with the details of the transaction being processed (which may include the full amount of the transaction and other details of the item scanned) and information about the transaction. A transaction transaction request message including the token information together with the transaction amount (among other information) can be transmitted to the transaction management system 130. For example, the message includes information identifying the token (received from the mobile device 102) and information identifying the cashier, POS terminal, merchant 108, location, transaction amount, item details of the purchased item. Can contain data elements. The transaction management system 130 uses information from the transaction request message to identify the transaction in process in the transaction queue and update the transaction queue.

A request message containing information about the transaction received from merchant 108, including the transaction amount, is sent from transaction management system 130 to portable device 102. Further, the message may be used by a customer in a particular transaction (eg, by applying one or more vendor-specific rules, one or more system-specific rules, and one or more customer account rules). It may include information identifying one or more customer available payment accounts identified by the management system 130. 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 transmit the selected account information and a transaction confirmation message.

  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. In other words, session control ensures that the same portable device 102 both requests a token, receives information about available payment accounts, and selects available payment accounts in a single transaction session. Started to guarantee. Thus, embodiments ensure that different customers or users cannot reuse or copy payment information for different users. Further, the method is such that the mobile device 102 that initiated the token request is the only device that can be used to pay for the transaction specified in the message sent from the merchant 108 to the transaction management system 130. Guarantee that there is.

Upon receiving the payment account selection and the transaction confirmation, the transaction management system 130 sends a payment authorization request message to the payment processing system (not shown in FIG. 1 but shown in FIGS. 2, 3, 5, and 6). To send to. The payment authorization request message includes the actual proof of payment (identified based on the information received from the mobile device 102), the transaction amount, and merchant information. Transaction management system 130, upon receiving the authorization response from the payment processing system, causes an acknowledgment message to be sent to merchant 108 (the acknowledgment is also sent to mobile device 102). In-flight transactions are also removed from the transaction queue. Thus, a payment transaction is performed by allowing 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. I can do it. This transaction processing can also be used with royalties, discounts, and other types of transactions. Further, the process can be used to perform transactions at other types of merchant locations (including MOTO, Internet, etc.), ATM machines or kiosks, and in person-to-person transactions.

  Although the system shown in FIG. 1 (and elsewhere throughout this disclosure) shows only a single portable device 102 and merchant 108, those skilled in the art will recognize that there are many devices in use and that the system You will understand that there are many vendors to use. Further, with respect to some embodiments, multiple devices (in some embodiments, wallet issuers and token issuing authorities) of transaction management system 130 are active.

As described further below, transactions performed using embodiments of the present invention have several desirable advantages over existing payment methods. For example, customers can use mobile devices to perform payment transactions at a wide variety of merchant locations. Further, the mobile device can be used to access a variety of different payment accounts maintained by the customer, allowing the customer to select the most appropriate or desired payment account for each transaction. Make it possible. With features of the present invention, embodiments can utilize existing point-of-sale systems and hardware, eliminating the need for merchants to add or replace expensive hardware. Further, paying according to embodiments of the present invention is more secure than existing payment methods. That is, each transaction consists of two pieces of user information (user identifier and / or password or PIN) known to the customer, along with unique attributes associated with the mobile device used by the customer to initiate the transaction. This is because authentication can be requested using the item. Other benefits and advantages will become apparent to one of ordinary skill in the art upon reading this disclosure.

  For some embodiments, system 100 includes a plurality of transaction management systems 130a-130n. Each (or one) merchant 108 has an association or relationship with one or more transaction management systems 130a-130n, and a customer operating the mobile device 102 can determine which transaction management systems 130a-130n There is no need to know if you are participating in any given transaction. Similarly, each mobile device 102 can communicate with a number of different transaction management systems 130a-130n, and the merchant or location of the transaction is determined by which transaction management system 130a-n It is not necessary to know if you are participating (until such information is confirmed during the transaction, as described herein).

  As mentioned in the co-pending application, the purchase or other transaction processing involved in some embodiments involves generating, scanning, or capturing tokens associated with the transaction location. In some embodiments, this token can be dynamically generated at a particular merchant or location for use in individual transactions. Scanning or capturing the token by the mobile device 102 causes the information to be sent to the transaction management system 130 for use in completing the transaction. For some embodiments, data associated with the token can be used in connection with identifying or selecting an appropriate payment account for the transaction. As described herein, the data associated with the token can also be used by any transaction management system 130a- to retrieve information about the transaction at the merchant (eg, information identifying payment amounts, retailer names, etc.). n can be used to determine if the mobile device should communicate.

  For some embodiments, the mobile device 102 (or merchant 108, in the context of a token being provided from the mobile device 102 to the merchant system in the transaction), may determine which transaction management systems 130a-n during a given transaction. Any of a number of different methods can be used to determine if a contact should occur. For example, in some embodiments, when the mobile device 102 scans or captures a token at a point of sale, the token may be used by a mobile payment application to contact an appropriate transaction management system 130a-n. It can include an identifier or other information that can be used. The identifier, or other information, is, for example, a URI or URL encoded directly into the token and used by the mobile application on the mobile device 102 to determine a route to access the appropriate transaction management system 130a-n. It can be. As an illustrative example, the URL https://paydiant.com/tms/production can be included directly in the token, along with the token value itself. In such embodiments, the URL or URI is encoded using a URL encoding method so that the mobile payment application can efficiently and accurately decode the URL or URI from the token, along with the value of the token. Can be

As another illustrative example of information that can be included in a token, a formatted URL string can be encoded within the token for capture and processing by a mobile payment application (eg, the URL string is It can be encoded into a QR code etc.). The formatted URL string can have the following structure: https: // <hostname / ipaddress>: <port> / <tokenIssuingAuthorityIdentifiter> / <issuedToken> / <transactionMetaData>. An exemplary string according to this format may be https://176.64.73.134:8663/pydt/y7uyjhd7/USD/3400. Transaction metadata that can be carried in this string can be, for example (without limitation) such information: transaction currency, transaction amount, and merchant identifier.

As another illustrative example of information that can be included in a token, a URI-based identifier can be encoded within the token for capture and processing by mobile payment applications (eg, URI-based The identifier can be encoded as a QR code or the like). The token can be an alphanumeric token such as "3ab0f564-82b5-4846-83a0-604c44989c59". This string can be used to search for an appropriate transaction management system (or wallet issuer / token issuing authority) for interaction. Tokenized string identifiers can also be used. For example, a tokenized string can be formatted in a variety of ways, including as an illustrative (non-limiting) example: <tokenIssuingAuthorityIdentifier>: <issuedToken>: <transactionMetaData>.

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

In the illustrative example of Table 1, when the mobile device 102 interacts with the merchant 108 using the Paydiant transaction management system 130, the token captured by the mobile device 102 from the merchant 108 along with the value of the token , The identifier “ABC123”. When the mobile device 102 receives the token, the path used to communicate with the transaction management system is the path associated with the identifier ABC123 (for example, a suitable path is https://paydiant.com/tms/production A search is performed to determine that If the mobile device interacts with merchant 108 using Visa's transaction management system 130, the token captured by mobile device 102 from merchant 108 may include the identifier "XYZ567" along with the value of the token. . When the mobile device 102 receives the token, the path used to communicate with the transaction management system is the path associated with the identifier XYZ567 (eg, the path would be https://visa.com/tms/production A) to perform a search.

In some embodiments, rather than (or in addition to) using a look-up table stored on the mobile device 102, an external service can be used to find an appropriate route. For example, the mobile device 102 can interact with the merchant device 108 and scan or capture tokens presented by the merchant. The token can be encoded to include both the identifier and the token value, where the identifier is used to retrieve a route to the appropriate transaction management system 130a-n. Can be used as a parameter in. Thus, the portable device 102 does not need to store or maintain a look-up table, but will need to make a call to a given web service endpoint that will return routing information associated with the transaction management system identifier. Only. In some embodiments, a combination of a look-up table and a web service call can be used (e.g., the identifier is not obtained from or included in the look-up table stored on the mobile device 102). If not, the mobile device 102 can make a call to the web service endpoint to retrieve the appropriate route information to the transaction management system 130).

  In some embodiments, one entity or device (transaction management server, token issuing authority, etc.) can operate as a directory service. For example, a token may encode or include information including a URI or URL (or other address) to a directory service. When the directory service contacts the token value associated with the transaction, the directory service may retrieve the additional information associated with or available for the transaction by the device (portable device 102, merchant 108, other Operable to identify or provide one or more other URIs, URLs (or other addresses) that can be used by the transaction management system 130). As an illustrative, but non-limiting example, the directory service contacted for a particular transaction (identified by the token value) may have a first address from which merchant data associated with the transaction can be obtained; For example, a second address that can be obtained (after completion of the transaction) and a third address that can obtain authorization data associated with the transaction can be provided. Each of these additional addresses, along with a valid token value, can be obtained by the device or entity having the address of the directory server. In some embodiments, interaction with the directory server can be controlled (eg, such that only authorized entities or devices can obtain information from the directory service). Additional levels of relationship can also be used. For example, the token issuing authority may provide an address associated with the transaction details, which may refer to another device or entity for additional transaction details, and And additional information about the transaction.

  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 select any number, such as time of day, day of the week, current transaction volume at the interaction location, purchase price, or any other factors that determine which transaction management system 130 to use. , One or more rules can be observed. The mobile device 102 or merchant 108 may also set a default transaction management system 130 setting (defining a default transaction management system 130 to use if a particular transaction management system 130 is not specified in connection with the token). And the transaction management system 130 changes based on one or more rules that evaluate data that can include one or more data items from the token or data items from any other source. May be able to do it.

For a further embodiment, the token captured by the mobile device 102 includes an identifier that can be decrypted by a mobile payment application on the mobile device 102 to derive a path to the associated transaction management systems 130a-n. Can be included. For example, an algorithm could be used to translate the identifier received in the token into a path to the appropriate transaction management system 130. As an illustrative example, the simple identifier "V1P" can be used to construct the path https://visa.com/1/production, based on the following method: "V" in the position of the identifier maps to the domain "visa.com", "1" in the second position of the identifier maps to a directory with the same name, and "P" in the third position of the identifier , 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 route the correct path to communicate with the appropriate transaction management system 130. It is possible to specify. Those of skill in the art, upon reading this disclosure, will appreciate that other techniques can be used to determine the appropriate path to a transaction management system.

  In some embodiments, the functions performed by transaction management system 130 can 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. Along with several different token issuing authorities (e.g., interacting with different merchants facilitating transactions relating to the present invention), several different wallet issuers (e.g., issuing mobile wallets to multiple consumers and their For consumers, managing user related functions) can exist. Features of such an embodiment will be described with reference to FIG.

  Further details of certain aspects of the system, in accordance with some embodiments of the present invention, are described with reference to FIG. FIG. 2 is a block diagram of an exemplary payment system network environment illustrating communication paths between the mobile device 202, the merchant 208, one or more transaction management systems 230, and the payment processing system 232. The mobile device 202 can be, for example, a mobile phone, a PDA, a personal computer, or the like. For example, the mobile device 202 can be an iPhone (registered trademark) of Apple Inc., a BlackBerry (registered trademark) of RIM Inc., a mobile phone using a Google Android (registered trademark) operating system, or the like. For some embodiments, the mobile device 202 can drive a payment application and cause the mobile device 202 to operate as a payment device, as described herein. In some embodiments, the mobile device 202 allows a customer operating the mobile device 202 to interact with one or more transaction management systems 230 to initiate a transaction via a web interface. , Access and display web content, or access the Internet.

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 may be a cellular network (represented by cell transmitter 215). The mobile device 202 can communicate over a mobile or other wireless network via the gateway 216 and can communicate with a network 214 (eg, the Internet or other public or private network, etc.). An access point, such as access point 218, can be provided to facilitate data and other communication access to network 214. Access point 218 may, for example, comply with the 802.11g (or other) communication standard. For example, in an embodiment where the mobile device 202 drives a payment application that allows the mobile device 202 to function as a payment device in accordance with the present invention, the payment application connects the network 201 to one or more transaction management systems 230. Data communication can be generated or controlled.

In some embodiments, the portable device 202 can perform both voice and data communications over the wireless network 214 via the access point 218. For example, the mobile device 202 can make or receive telephone calls, send and receive e-mail, and receive short message service ("SMS") messages over the wireless network via the access point 218. It can send and receive, send and receive email messages, access electronic documents, send and receive streaming media, and so on. Similar communication can take place via the network 215.

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

The mobile device 202 has a display screen 236 and a data input device 238 (such as a keypad or touch screen or voice interface). For embodiments of the present invention, the customer uses the mobile device 202 to perform a purchase transaction with the merchant 208 (or an ATM transaction with an ATM or any other transaction supported by the system of the present invention). You can do it. The merchant 208 can be a physical storefront, an electronic trader, or a MOTO merchant (or other person or entity). The mobile device 202, in some embodiments, also includes a camera (not shown) or other image capture device that allows the mobile device 202 to capture an image or representation of the token 210. The mobile device 202 may, in some embodiments, also include a wireless receiver (not shown) or other wireless signal receiving device, such that the mobile device 202 can capture a wireless signal representation of the token 210. Having. For example, a customer may use the present invention to take a digital picture of a token displayed on or at a merchant's point of sale device or to capture an image to initiate a payment transaction, The mobile device 202 can be operated. The captured image is shown on display screen 236 as item 237. As described further below, the token 210 can be used to initiate and execute a transaction with a merchant.

Merchant 208 may process payments and transactions, including payment transactions (along with "traditional" or standard payment transactions, including cash, standard payment cards, etc.) in accordance with the present invention, as described. One or more trader systems 209 can be operated. Merchant system 209 can be a networked point of sale system (for physical retailer locations) or a shopping cart system (for electronic trading or Internet retailer locations). . If the “trader” is an ATM device, the vendor system 209 can further be an ATM network or the like. Merchant system 209 can also be a combination of systems designed to allow merchants to pay for merchants and services. In some embodiments, merchant system 209 can communicate with one or more point of sale devices 212 that have a display device 213 for presenting and receiving information from customers. For example, if merchant 208 is a physical retailer location, merchant systems 209 may each be located at a different checkout lane or location within the store (or in a different store at a different geographic location). ), Can communicate with several different point of sale devices 212. Each of the point-of-sale devices 212 has a point-of-sale (or “POS”) so that the customer can authorize or authorize the purchase and submit payment for the purchase.
)), The transaction information can be presented, displayed, or communicated to the customer.

  As another example, where merchant 208 is the Internet or another electronic trader, merchant system 209 may include a web server (or some with Internet access) configured to process purchase transactions associated with merchant 208. Server network). The point-of-sale device 212 may interact with the merchant system 209 via a network such as the Internet in such an example, and may interact with the merchant system 209, for example, a personal computer, a portable device, etc. , Some remote terminals. Embodiments of the present invention can initiate and execute transactions with both physical and remote types of merchants, so the point of sale, the place of purchase, or the interaction between the buyer and the merchant, Here, it can be referred to as a “sale location” or “interaction location”.

  For embodiments 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 static tokens are used, the tokens should be located near the location of the point of sale (on a sticker or placard so that customers can easily see, read, or capture the token). Printed, displayed or provided. The static token 210 can be printed as a barcode image, as an alphanumeric identifier, or in other forms. In some embodiments, the token may be presented using the portable device 202 in a form that is easily discernible by a human, such as for both keying and capturing. In embodiments where static tokens are used, additional processing steps can be performed (as described further below) to provide mobile device 202 with detailed information about the transaction.

In embodiments where a dynamic token is used, the token may 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 (eg, a purchase amount, for example), and in some embodiments, the mobile device 202 and the transaction management system 230 between the payment transaction. It can include fewer messages in between. The token 210 may be captured by the token 210 as a barcode image, as an alphanumeric identifier, as a wireless signal, or as an image (e.g., using a camera or scanner associated with the mobile device 202). It can be encoded or displayed. The token 210 can also be keyed in by a customer of the mobile device 202 or captured by a wireless receiver associated with the mobile device 202. In some embodiments, the mobile device can be operated with multiple types of tokens 210 (e.g., the mobile application can use image capture, The token 210 can be captured using wireless reception or key input.)

The display device 213 can be an LCD (or other display technology) display (such as one currently available from many vendors on the system, such as a Hypercom 4150 terminal or a Verifone MX870 terminal). . The use of token 210 in a transaction according to the present invention will be further described below. However, in general, the token 210 is stored in the transaction management system 230 or, using the accessible information, to combine the payment request from the mobile device with a payment authorization request from the merchant 208 to complete the payment transaction. Used by the transaction management system 230 for matching processing. In embodiments where 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.

  In a typical exemplary transaction, the customer first selects mobile payment as the payment option and authenticates with the payment application on the mobile device 202 (or via a web browser interacting with the transaction management system 230). Processing, capturing the token 210 from a device associated with the merchant 208 (such as from the display 213 of the point-of-sale device 212) and providing transaction details and suitable or usage information from the payment account list or transaction management system 230. Receiving a list of possible accounts, selecting a payment option on the mobile device 202, and submitting a customer payment authorization request to the transaction management system 230 over the network 201, from the merchant 208. It is possible to purchase the goods or services.

  Selecting a payment option includes receiving information identifying one or more payment accounts available to the customer. Available payment accounts may be specified by the customer during a registration process, such as the process further described below in connection with FIG. In connection with some embodiments, the presentation of the different payment account options may be such that the customer is presented with a list of available payment accounts so as to be offered the most suitable or available account for the current transaction. And applying one or more rules or options. The customer selects the payment account (or account, in the case of a combined transaction registration transaction) to use, and the information is sent to the transaction management system 230. In some embodiments, all of the customer's available payment accounts can be displayed to the customer after the customer has been authenticated.

In some embodiments, the list of accounts later received from the transaction management system 230 (after processing the customer transaction search request) may include additional metadata or information associated with each payment account (eg, The balance of available accounts, any special offers available if the account was used in the current transaction, etc.). In some embodiments, the list of accounts later received from transaction management system 230 is based on the application of rules at transaction management system 230 (eg, one or more customers, merchants, or application of system rules, etc.). , Can include fewer accounts. For example, a rule may specify that a particular payment account should not be used for small amount transactions. In such a case, that particular payment account will not be included in the list of accounts sent from the transaction management system in response to the customer transaction search request. In other words, after processing the customer transaction search request, the list of payment accounts received from transaction management system 230 may be a subset of all accounts registered by the customer.

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

  In some embodiments, where a dynamic token 210 is used, the transaction details need not be received by the mobile device 202 from the transaction management system 230, but rather some or all of the transaction details may be received. , Can be provided to the mobile device 202 via data encoded or contained 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.

  In some embodiments, the transaction management system 230 sends a customer payment confirmation request message to the customer's mobile device 202, and the customer may be given a last chance to confirm or cancel the payment transaction. Make it possible. For example, a customer may be prompted to "confirm" or "cancel" a payment transaction. The promotion can provide additional information about the transaction and the selected payment account, and the customer can have detailed 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, a customer may be given the opportunity to receive (or not receive) a customer payment confirmation request message.

When a final confirmation to proceed with payment is received from the customer's mobile device 202, the transaction management system 230 configures one or more payment processing networks 232 to authorize, clear, and close funds for the transaction. Generate an authorization permission request message for transmission via The request message includes transaction details such as the transaction amount or other information from the merchant payment authorization request (received from merchant 208) and the actual proof of payment associated with the payment account selected by the customer. . The actual payment credentials can be obtained by using the payment account selection information and performing a search for the actual payment account credentials pre-stored in a database or location accessible to the transaction management system 230. The authorization authorization process may involve a standard financial authorization process via one or more payment processing networks 232 (eg, a VISANET network operated by Visa, Inc., an automatic clearing house system such as NACHA, etc.). Can be implemented using Once the availability of funds is confirmed, the transaction management system sends a merchant payment authorization response message to merchant 208, the transaction is completed at point of sale 212, and the customer payment authorization response message is sent to customer's mobile device 202. Sent.

  The mobile device 202 is used to obtain a token from the transaction management system 230 and the merchant 208 (or other mobile device or other interaction location device) captures the token from the mobile device 108. , Similar processing can occur as described above.

  In some embodiments, a payment system in accordance with the present invention can include multiple entities that perform different processing functions typically provided by one or more transaction management systems described above. For example, in some situations, it may be desirable for multiple entities (herein referred to as "wallet issuers") to issue and manage mobile payment applications in accordance with the present invention. For example, a financial institution or other entity may choose to issue and manage tasks and functions that provide a mobile payment application to a customer. This will 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 a token issuing function 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 point of sale and other merchant systems. An entity may wish to provide a merchant with a token issuing function. This may result in multiple token issuing authorities participating in the payment system of the present invention.

  One exemplary system is similar to the system shown in FIG. 2, except that one or more token issuers 250 and one or more wallet issuers 260 are shown instead of the transaction management system 230. This is shown in FIG. 3 (but in some embodiments, one or more transaction management systems 230 may be implemented in a system operating with one or more wallet issuers 260 and one or more token issuing authorities 250. , Still available). As shown in FIG. 3, the wallet issuer 260 can communicate with the mobile device 202 via one or more network paths. In general, the wallet issuer 260 and each mobile device 202 that operates the mobile payment application issued by the wallet issuer 260 can communicate (eg, the mobile payment application may have a wallet issuer associated with the mobile device 202). 260 can be encoded to ensure reliable interaction and communication with H.260). Further, the token issuing authority 250 communicates with one or more merchants 208 via one or more network paths. In certain transaction embodiments and scenarios, there is also communication between the wallet issuer 260 and the token issuing authority 250 (eg, to complete a transaction involving both parties). Further, while the wallet issuer 260 is shown to communicate with one or more payment processing networks 232, in some embodiments, the token issuing authority also has one or more payment processing networks 232. Can communicate. Further details of the transaction involving these entities will be provided below, together with the description of FIG.

  In connection with some embodiments, before a customer can use a mobile device (such as the mobile device 202 of FIG. 3) to perform a purchase transaction using the present invention, the customer may enter into FIG. A registration process, such as a process described in connection therewith, must be performed. The data collected or provided in connection with process 400 may be stored in or accessible to one or more databases associated with a transaction management system, such as system 230. Further, for some embodiments, a separate wallet issuer 260 can store data collected or provided in connection with process 400.

The registration process 400 of FIG. 4 shows that the customer first registers with the registration server (which can be, or can be associated with, the transaction management system 230 of FIG. 2 or a component of the wallet issuer of FIG. 3). Triggered when interacting to initiate processing. For example, a customer may access a registration web page associated with a registration server or use the features of a mobile application to complete the registration process (either on a mobile device or other computing device). ) Can operate Internet browser. The registration web page may request the customer to provide a particular method to initiate the account creation process. For example, a customer may provide a name, address, and other contact information, as well as contact information including one or more email addresses and telephone numbers. The customer identifier or other unique record (or records) may be established in a database associated with or accessible to transaction management system 230 or wallet issuer 260. The customer identifier can be used to uniquely identify a customer. The customer identifier may be an alphanumeric identifier assigned by the transaction management system 230 (depending on the embodiment or the wallet issuer 260, for example) or information based on or provided by the customer (eg, a mobile phone number). Alternatively, the identifier can be an identifier associated with the portable device 202).

Processing continues at 404 where the customer establishes an account relationship with the transaction management system 230 (or, depending on the embodiment, the wallet issuer 260). 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 with which the customer wishes to transact. Each mobile device 202 may have, for example, a phone number and / or other unique identifiers (hardware serial numbers, ASINs (Amazon Standard Identification Numbers), advertising identifiers for iPhones, component serial numbers such as CPU serial numbers, etc.). ). In some embodiments, the customer registers by downloading a payment application having a registration module from a browser on the mobile device or first on the mobile device. In some embodiments, the system is associated with the mobile device. , Unique identifying information (e.g., hardware serial number, ASIN, advertising identifier, or other device identifier).

Processing continues at 406, where the customer provides information about one or more payment devices or 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 that the customer wants to associate with the transaction management system 230 (or, depending on the embodiment, the wallet issuer 260), the customer's account relationship. For example, a customer may enter information about one or more credit cards, debit cards, gift cards, bank accounts, check accounts, and the like. The information for each account includes the actual proof of payment or sufficient information to process the transaction using that account. For example, for a credit or debit card, the information includes the primary account number (or Permanent Account Number (PAN)), the expiration date, and
A verification code can be included. For a bank account, the information can include a routing number and an account number. Other information, such as bank or issuer information, can also be entered at 406.

As an illustrative example, a customer called "Jane" has entered details for four of her payment accounts she would like to use in connection with the present invention. These are: ####### Primary Account Number (or PAN), Chase Credit Card with 05/12 Card Expiration Date, ABA Number of ####### and ###### Webster Bank check account with account number ##, PAN with ######## and WebsterBank Visa debit card with card expiration date 06/11, PAN with ###### and 8/10 Includes Starbucks gift cards with expiration dates of: Additional account identification information may be provided as needed (eg, in some embodiments, for a payment card, a card verification number may also be provided). The data obtained during process 400 can be securely stored, for example, in a PCI-compliant database. In some embodiments, by securely storing payment card data (including expiration date, verification code), payments made using the present invention are eligible for a discount exchange as a "card present" transaction. You can do it. For some embodiments, the customer can add, remove, or update account information as needed.

  Processing continues at 408, where the customer may optionally establish one or more selections or rules in connection with the use of the one or more accounts entered at 406. For example, the customer can designate one account as the "primary" or default account. Other rules and selections can also be set up so that accounts are efficiently and logically selected and used. For example, a customer can specify a priority or other account-based rule that indicates how a particular payment account should be treated for other payment accounts. The customer can also optionally specify usage restrictions or balance conditions governing when and how the payment account should be presented. The customer may also specify the order of the accounts displayed on the mobile phone based on which merchant to purchase from, or the funds available in each account, or the rewards received for using each account. I can do it.

  In some embodiments, rules (such as customer-specific rules) can cause the payment process to proceed faster or with fewer customer steps. For example, a customer may specify that when purchasing at a particular merchant (a type of purchase, such as a purchase that is less than a certain amount), a default payment account should be used. 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 automatically performed by the application of customer specified rules. It is performed.

  Those of skill in the art, upon reading this disclosure, will be able to specify a wide variety of account-level rules to allow their customers to control how (and when) payment accounts are presented as payment options. Will understand what can be done.

In the illustrative embodiment introduced above, a customer called "Jane" has specified the following account selections. (I) she wants to use less credit, and (ii) she wants to lower transaction fees. Jane also specified the rules that should be applied when a particular payment account is parsed for use in a given transaction. (I) her Starbucks gift card balance should be used when possible (assigned the highest priority); (ii) her check account or the debit card associated with the check account is the second Should be used at a high priority (although she would prefer not to use a check account if the transaction reduces her balance to less than $ 1,000) and (iii) her credit card Should be the last payment option, with the lowest priority.

When Jane uses her mobile device to perform a transaction with the present invention, the transaction management system 230 (or wallet issuer 260) asks which payment account is available for the transaction. Would recommend comparing the rules and selections specified by Jane with the details of the transaction. For example, if Jane uses her mobile device to buy a cup of coffee at Starbucks, the transaction management system will tell her that she can use her Starbucks gift card for the purchase. Will let her know. In this way, customers with various payment accounts can be presented with options for payment options based on overall selection and intended use. In addition, payment accounts that are unavailable or unsuitable for a particular transaction may be transferred to the transaction management system 230 (or wallet issuer 260) so that the customer does not have to optionally be presented with such a payment account. ) Would be so identified (eg, if Jane purchases gas at a gas station, she would not be presented with a Starbucks gift card as the payment account for the transaction).

In some embodiments, the process can continue at 410 if the customer operates or uses a mobile device (iPhone or Android phone) that can operate the applications associated with the present invention. At 410, the customer is prompted to download and install the application on their mobile device. The application enables customers to operate their mobile devices to perform payment transactions related to the present invention quickly and easily. In the case of a phone or device that does not have the ability to execute such an application, a link or web page may be provided to the customer accessible via the mobile phone browser so that the customer can perform the payment transaction associated with the present invention. , Generated or provided.

  Once the customer has established an account relationship with the transaction management system 230 (or wallet issuer 260, depending on the embodiment), the customer registers one or more payment accounts with the transaction management system 230 (or wallet issuer 260). The customer can then use the system of the present invention to execute a purchase transaction at a merchant that supports the transaction of the present invention.

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, multiple mobile devices 202 and multiple merchants 208 (or other interaction locations, such as ATMs, other mobile devices, etc.) interact with multiple transactions. There may be a wallet issuer 260 and multiple token issuers 250. For example, one consumer may obtain a mobile payment application on their mobile device 202 from their financial institution or other entity, and the financial institution or other entity may provide these consumers with a wallet issuer 260 (Or use an agent to perform the function of the wallet issuer). One merchant 208 may choose to interact with one token issuing authority 250 but not with another. Alternatively, the merchant 208 can use a single token issuing authority. Each of these choices is a combination of the actors participating in a given transaction between the consumer and the merchant 208, and presents the technical challenge of ensuring that all participants can successfully engage in the transaction. provide. Embodiments provide systems and methods that allow transactions to occur despite potentially large and varied numbers of participants.

  Reference is 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 the wallet issuer 260. In the illustrated system, merchant 108 has an association or interaction with one or more issuing authorities 250a-250n. For example, merchant 108 may have relationships with one or more entities (such as financial institutions, merchants, vendors of point-of-sale systems, etc.) that rely on providing tokens for transactions performed in connection with the present invention. . In such a system, it would be technically difficult to perform a transaction without the features of the present invention. The details of some embodiments that allow a transaction to be performed are shown in FIG. 5 and will be described following the processing steps indicated as “1”-“6”. In some embodiments, only six major interactions are shown, but each interaction can include multiple messages or communications between devices. For convenience and ease of commentary, only the high-level interactions are shown in FIG. However, various implementation options will be described below.

As shown, a consumer operating portable device 102 desires to perform a transaction with merchant 108. For example, a customer may be on the merchant's checkout lane, where the item he wants to purchase is recorded at a cash register by a clerk, and the customer may indicate that he wants to pay with his mobile application. Selecting a mobile payment option causes the merchant system to request a token for the transaction. In the example, merchant 108 uses several different token issuing authorities 250a-n (e.g., merchant 108 uses token issuing authority 250a for certain types of transactions, and other token issuing authorities 250a-n). 250b and 250n can be used). This is shown for illustration purposes only. Those skilled in the art, upon reading this disclosure, will appreciate that many merchants can only interact with a single token issuing authority 250.

In the illustrative embodiment illustrated in FIG. 5, merchant 108 has several relationships, in the transaction shown (in the interaction labeled "1"). , A request to issue a token from the token issuing authority 250b. The request can be requested in a message as a Merchant Payment Authorization Request message that sends information related to the transaction being processed to the token issuing authority 250b. Upon receiving the merchant payment authorization request message, token issuing authority 250b generates or specifies a token for use in the transaction. The token issuing authority 250b can also generate a transaction record in process related to the token. In some embodiments, the transaction record in progress may include information including a merchant identifier, a terminal identifier, a transaction amount, and other data associated with the transaction being processed. For some embodiments, the token generated or obtained by the token issuer 250b includes information that can be used to identify the token issuer 250b. As noted above, such information may include a formatted URL string (in some embodiments, providing the token issuer 250b with a URL, along with information related to other transactions), a URI, Based identifiers, tokenized string identifiers, and the like. The token (including the token identifier and information identifying the token issuing authority) is returned to merchant 108 for presentation or communication to portable device 102.

  Those skilled in the art, having read this disclosure, will note that in some embodiments, the information identifying the token and the authority to issue the token may also be pre-stored or locally available at merchant 108. You will understand that it can be done.

  The merchant 108 can display or present the token as a QR code or via other means, and the customer is prompted to capture the token using their mobile device 102 (Shown as an interaction of "2"). Once captured, the mobile payment application on the mobile device 102 can be manipulated to decrypt the token to obtain the information contained therein (shown as an interaction of "3"). There). In some embodiments, decrypting the token may include cooperative processing between the mobile device 102, the mobile payment application, and the wallet issuer 260 that issued the mobile payment application, or another device. . Decryption of the token can be any or all of the following: the identity of the particular token issuing authority 250b that issued the token, the actual token value, and any metadata provided with the token value.

At this point in the transaction, the token issuer 250b has a transaction record in process, including transaction details, received from the merchant. The transaction record being processed can be identified using a token issued or provided by the token issuing authority 250b. However, the token issuing authority 250b may not know at this point information about the customer or the payment mechanism used by the customer. The customer (via the mobile payment application on the mobile device 102) can have information about the transaction in progress, as provided in the metadata decrypted at "3", and have the token issuing authority Can have a token value along with information that can be used to identify the party 250b. The wallet issuer 260 authenticates the customer and the mobile device 102 and has information related to the token received or captured by the mobile device 102. Generally, in this regard, wallet issuer 260 also knows the identity of token issuing authority 250b. 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 where the token is encoded with a formatted URL string having the following format: https: // <hostname / ipaddress>: <port> / <tokenIssuingAuthorityIdentifiter> / <issuedToken> / <transationMetaData>. "2"
The string received at 3 and decrypted at 3 can reveal a URL string formatted as follows: https://176.64.73.134:8663/pydt/y7uyjhd7/USD/ 34000 / MID01001,
This allows the appropriate token issuing authority 250b to interact with the mobile device 102, mobile payment application and wallet issuer 260 to be accessed at https://176.64.73.134:8663 and identified as "pydt". The token issuing authority. The token used to identify the transaction record being processed is “y7uyjhd7”, and the transaction is US $ 3,400 in US dollars at a merchant identified as “MID01001”. Further, wallet issuer 260 may have location and other data received from mobile device 102.

  In some embodiments, processing at "3" may not result in portable device 102 having transaction information. For example, in some embodiments, the token obtained at “2” from merchant 108 may not include metadata (such as data identifying the transaction amount). In such situations, one or more additional interactions are required. For example, one such further interaction is shown as interaction "4" where the mobile device 102 interacts with the wallet issuer 260 in the request for transaction details. The process at "4" can include the portable device 102 providing the wallet issuer 260 with a token value along with information used to identify the token issuer 250b. Wallet issuer 260 issues a request to token issuance authority 250b, requesting transaction details, relating to the transaction value being processed, relating to the token value obtained by mobile device 102 at "2". Can be done. (If the token acquired in “2” does not have or does not have sufficient metadata about the transaction), it is processed in “4” or (if the token acquired in “2” is If there is any such metadata, processing at "3", processing can continue as described below.

On the mobile device 102, interacting with the mobile payment application, the wallet issuer 260 can proceed to perform a process to determine which customer's payment account can be used for the transaction. For example, a wallet issuer 260 that stores customer preferences and rules may be used by a merchant where only some of the customer's payment accounts are identified by “MID01001” (or based on merchant type and location). You can determine what you can do. Wallet issuer 260 can also determine that only certain payment accounts are available to use to complete a $ 3,400 transaction in US dollars. Wallet issuer 260 informs the customer which payment accounts are available for use in the transaction being processed and obtains a customer selection of one or more payment accounts to use to complete the transaction. To interact with mobile payment applications.

If the customer selects the desired account and confirms or accepts the transaction on the mobile device 102, the process will proceed to either the mobile device 102, the wallet issuer 260, or a combination of the mobile device 102 and the wallet issuer 260. May obtain authorization for the transaction from one or more payment processing networks 280 for the transaction and proceed to interaction "5" to provide authorization for the transaction to the appropriate token issuing authority 250b. Such an interaction at "5" may include several messages. For example, when a customer selects a desired payment account to use to complete a transaction, a message is sent, and the wallet issuer 260 identifies the desired payment account (in some embodiments, the message is It does not include the payment account credentials, but rather includes a proxy or identifier that the wallet issuer 260 can use to retrieve or identify the actual payment account credentials). The wallet issuer 260 composes a payment authorization request message with information including the actual payment account credentials (PAN, account number, confirmation or confirmation data, expiration date, etc.), transaction amount, and merchant identifier. The payment authorization request message is sent to one or more payment networks for authorization processing. Once the transaction is authorized, the wallet issuer 260 can receive the authorization code and authorization response message sent to the appropriate token issuing authority 250b along with the token.

  Upon receiving the authorization code and the authorization response, the token issuing authority 250b identifies the transaction record being processed using the received token, and interacts with the trader 108 to complete the transaction ("6"). At). For example, in a situation where payment has been authorized, the token issuing authority 250b may send information confirming that the transaction has been completed successfully, and the merchant 108 may have the transaction receipt printed at the location of the interaction. Wallet issuer 260 can also cause transaction receipts or other information to be sent to portable device 106.

  In some situations, it may not be possible for the wallet issuer 260 to obtain a 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 issuer 250 may not provide additional metadata associated with the transaction (such as a merchant identifier and / or transaction amount). In such a 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, when the wallet issuer 260 obtains a token from the mobile device 102, the wallet issuer 260 establishes communication with the token issuing authority 250 and missing metadata (eg, , Vendor identifiers, and transaction amounts). Wallet issuer 260 can proceed as described above and obtain payment authorization from payment processing network 280.

In yet another embodiment of the situation where the wallet issuer 260 cannot obtain a payment authorization from the payment processing network 280 based on information available to the wallet issuer 260, the token issuing authority 250 obtains the payment authorization. I can do it. For example, in some embodiments, when identifying the appropriate payment account credentials for use in a transaction, the wallet issuer 260 may provide those payment account credentials to the token issuing authority 250 (along with the token). It can be passed and allows the token issuing authority to compose 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 requires the mobile device 102 and the wallet issuer 260 to provide the information used to identify the token issuing authority 250 (URL, URI or other data provided with the token). Along with the information used to identify the transaction (token).

As noted above, in some embodiments, the mobile device 102 can be operated to obtain a token, which can be sent to the merchant 108 (or to another device or transaction participant). ) Can be provided. In such embodiments, different entities, systems or devices may perform different transaction management functions. Reference is made to FIG. 6, where one illustrative system is described. In conjunction with FIG. 5, interact with multiple transactions, including multiple mobile devices 202 and multiple merchants 208 (or other interaction locations such as ATMs, other mobile devices, etc.), as in the embodiment above. , There can be multiple wallet issuers 260 and multiple token issuing authorities 250.

In FIG. 6, a further system diagram is shown, illustrating 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 the 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 with or before interaction "1" (eg, the user and device are authenticated by wallet issuer 260). In some embodiments, when the mobile device 102 requests a token from the token issuing authority 250b, it can also provide information that can be used by the token issuing authority 250b to communicate with the mobile device 102. (This will allow the token issuer 250b to send the transaction details to the mobile device 102 in a message described below and labeled as item "4"). Upon receiving the token request, the token issuing authority 250b can generate a transaction record in progress associated with the token. In some embodiments, the transaction record being processed includes 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 a transaction. It can include information including other data associated with the transaction in which it resides. In some embodiments, the token generated or obtained by the token issuer 250b includes information used to identify the token issuer 250b. As noted above, such information is included in a formatted URL string, URI (in some embodiments, providing a URL to token issuer 250b along with information related to other transactions). Based identifiers, tokenized string identifiers, and the like.
The token (including the token value and information identifying the authority to issue the token and, in some embodiments, some additional metadata), is presented to the merchant 108 for communication or Returned to portable device 102.

The mobile device 102 can display or present the token as a QR code (or present via a wireless signal such as Bluetooth, NFC, etc.) and the merchant 108
Can be prompted to capture the token (shown as a "2" interaction) (e.g., using a scanner or other reader). Once captured, merchant 108 can decrypt the token (shown as a "3" interaction) to obtain the information contained therein. In some embodiments, decrypting the token may include cooperative processing between the merchant 108 and another entity. The result of decrypting the token can be any or all of the following: The identity of the specific token issuing authority 250b that issued the token, the actual token value, and any metadata provided with the token value.

  Merchant 108 may perform processing to generate a merchant payment authorization request message and send it to token issuing authority 250b identified in the token (eg, via interaction "4"). . The Merchant Payment Authorization Request message can send information related to the transaction being processed to the token issuing authority 250b, along with a token value obtainable from the interaction of "2" and "3". The information may include a merchant identifier, a terminal identifier, a transaction amount, and other data associated with the transaction being processed.

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

  When the mobile device 102 (and in some embodiments, the wallet issuer 260) has information associated with the transaction being processed (including, for example, information identifying the merchant 108, the transaction amount, etc.) Processing can continue at the interaction labeled as “5”.

  In the process during the interaction shown as item "5", the wallet issuer 260 interacting with the mobile payment application on the mobile device 102 determines which customer's payment account can be used in the transaction. Can be performed. For example, a wallet issuer 260 that stores customer preferences and rules determines that only some of the customer's payment accounts are available for merchant use (or based on merchant type or location). I can do it. The wallet issuer 260 can interact with the mobile payment application to notify the customer which payment accounts are available for use in the transaction in progress, and to complete the transaction A customer selection of one or more payment accounts to use can be obtained.

If the customer selects the desired account and confirms or accepts the transaction on the mobile device 102, the process of interaction "5" proceeds and the mobile device 102, the wallet issuer 260 or the mobile device 102 and the wallet issuance. Any combination of parties 260 can obtain transaction authorization from one or more payment processing networks 280 for a transaction and communicate to the appropriate token issuing authority 250b to provide the transaction authorization. Such an interaction at "5" may include several messages. For example, when a customer selects a desired payment account to use to complete a transaction, a message is sent, and the wallet issuer 260 identifies the desired payment account (in some embodiments, the message is: It does not include the actual payment account credentials, but rather includes a proxy or identifier that can be used by the wallet issuer 260 to retrieve or identify the actual payment account credentials). The wallet issuer 260 composes a payment authorization request message with information including the actual payment account credentials (PAN, account number, verification or verification data, expiration date, etc.), transaction amount, and merchant identifier. The payment authorization request message is sent to one or more payment networks for authorization processing. Once the transaction is authorized, the wallet issuer 260 receives the authorization code and the authorization response message and sends it along with the token to the appropriate token issuing authority 250b.

  Upon receiving the authorization code and the authorization response, the token issuing authority 250b uses the received token to identify the transaction record being processed and to interact with the merchant 108 to complete the transaction ("" 6)). For example, in a situation where the payment is authorized, the token issuing authority 250b can send the information and confirm that the transaction was completed successfully, and the merchant 108 can print the transaction receipt at the location of the interaction. Can be done. Wallet issuer 260 also causes mobile device 106 to send a transaction receipt or other information.

  In some situations, wallet issuer 260 may not be able to obtain payment authorization from payment processing network 280 based on information available to wallet issuer 260. For example, in some embodiments, the token issuer 250 does not provide additional metadata (merchant identifier and / or transaction amount) associated with the transaction, and May have not provided the mobile device 102 and the wallet issuer 260 with additional transaction information. 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, when the wallet issuer 260 obtains the token from the mobile device 102, the wallet issuer 260 obtains the missing metadata (eg, including the merchant identifier and the transaction amount). In order to do so, communication with the token issuing authority 250 can be established. Wallet issuer 260 can proceed as described above and obtain payment authorization from payment processing network 280.

  In yet another embodiment, for situations in which it is not possible to obtain a payment authorization from payment processing network 280 based on information available to wallet issuer 260, token issuer 250 , You can get payment authorization. For example, in some embodiments, once the wallet issuer 260 has identified the appropriate payment account credentials to use in the transaction, the wallet issuer 260 passes those payment account credentials (along with the token) to the token issuer 250 In addition, information from the transaction record being processed, along with the payment account credentials received from the wallet issuer 260, allows the payment authorization message to be composed. In any situation, the ability to complete the transaction provides the mobile device 102 and the wallet issuer 260 with information (such as a URL, URI, or other information provided with the token that can be used to identify the token issuing authority 250). Information such as the data of the transaction) as well as information used to identify the transaction (token).

  Embodiments provide for processing to occur in a system having multiple transaction management systems, and further to generate processing in a system having multiple entities that perform different aspects of transaction management (such as wallet issuers and token issuance). The device communicates with which transaction management system (or other device or entity) for each particular transaction, as well as the path or communication channel to use to interact with the associated transaction management system. Can be specified easily and efficiently.

  Thus, 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 provide a mobile device participating in the payment system with any transaction system ( Or other device or entity) and at the transaction location, based on the information captured in the obtained checkout token, to correctly identify and determine whether to communicate to complete the transaction for the present invention. It is possible to do.

  The above description of the process should not be taken as indicating a fixed order in which the processing steps are performed. Rather, the processing steps may be performed in any practical order, including the simultaneous execution of at least some steps. While the present invention will be described in connection with specific exemplary embodiments, various changes, substitutions, and modifications obvious to those skilled in the art will depart from the spirit and scope of the invention as set forth in the appended claims. It should be understood that embodiments of the disclosure can be made without departing from the invention.

Claims (10)

Non-temporary memory for storing instructions;
A system comprising one or more hardware processors coupled to said non-transitory memory,
The one or more hardware processors include:
Receiving the encoded token;
Decoding the encoded token to obtain token data and obtain the identity of the server used to complete the transaction;
Providing the token data to another person's device;
Receiving, from the server, an electronic message identifying one or more payment accounts of a user available for the transaction after the server receives a processing transaction request based on the identification; Receiving the electronic message, wherein a processing transaction request comprises: a) the token data captured by the device and associated with transaction information; and b) the transaction information.
Selecting one of the one or more payment accounts based on input from the user;
Executing the instructions to cause the system to perform an operation comprising sending the selected one of the one or more payment accounts to the server to complete the transaction. The system to be composed.   The system according to claim 1, wherein the identification is based on a uniform resource locator (URL) or a uniform resource indicator (URI) in the encoded token. The receiving, decoding, providing, receiving, selecting, and transmitting the electronic message of the encoded token is performed by the mobile terminal of the user. And
The system of claim 1, wherein the transaction is completed without storing the one or more payment accounts on the mobile terminal.   The method of claim 1, wherein the encoded token includes an address of the server, and causes the another party's device to send the token data to the server via the address to complete the transaction. System.   The system of claim 1, wherein the token data further comprises a token value associated with the transaction.   The system of claim 1, wherein the server is associated with one of a plurality of different providers that perform transaction processing.   The system of claim 1, wherein the encoded token is generated as part of initiating the transaction between two parties.   The system of claim 1, wherein different encoded tokens are generated for different transactions. Receiving the encoded token;
Decoding the encoded token to obtain token data and obtain the identity of the server used to complete the transaction;
Providing the token data to another person's device;
Receiving, from the server, an electronic message confirming one or more payment accounts of a user available for the transaction after the server receives a processing transaction request based on the identification; Receiving the electronic message, wherein a processing transaction request comprises: a) the token data captured by the device and associated with transaction information; and b) the transaction information.
Selecting one of the one or more payment accounts based on input from the user;
Storing machine readable instructions executable to perform an operation including sending the selected one of the one or more payment accounts to the server to complete the transaction.
Non-transitory machine-readable medium. A computer-implemented method for performing a transaction involving multiple parties, the method comprising:
Receiving the encoded token;
Decoding the encoded token to obtain token data and obtain the identity of the server used to complete the transaction;
Providing the token data for electronic capture by a merchant device;
Receiving, from the server, an electronic message confirming one or more payment accounts of a user available for the transaction after the server receives a processing transaction request based on the identification; Receiving the electronic message, wherein a processing transaction request includes: a) the token data captured by the merchant device and associated with transaction information; and b) the transaction information.
Selecting one of the one or more payment accounts based on input from the user;
Sending the selected one of the one or more payment accounts to the server to complete the transaction.