JP2023030024A - Method, customer device, and non-transitory machine-readable medium - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a method, a customer device, and a non-transitory machine-readable medium that can certificate payment for a consumer wishing to pay for a commodity.

SOLUTION: A method comprises the steps, by a customer terminal 102, of: determining a transaction between a customer associated with the terminal 102 and a business operator 108 associated with a business operator device; transmitting, in response to determining the transaction, a request for a token including characteristics of the transaction to a token issuing authority 250b; and displaying, upon receipt of a token including identification information identifying an access location for accessing a function of a transaction management system from the token issuing authority 250b, a quick response code encoding at least identification information for scanning by the business operator 108.

SELECTED DRAWING: Figure 5

COPYRIGHT: (C)2023,JPO&INPIT

Description

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

Recently, payment systems and methods have been proposed that allow users to conduct transactions using mobile devices. In one method, such as proposed by the assignee of the present invention, a user can perform transactions using a mobile device that has a mobile payment application installed. In the proposed transaction, a "token" (such as a checkout token or ATM token) can be captured or communicated to the mobile device. Tokens are used by the transaction management system to facilitate the completion of transactions between the user of the mobile device and the transaction location. For example, the transaction management system uses information associated with the token to identify the merchant (or consumer) associated with the transaction location and identify pending transaction information associated with the transaction location. can do

As a related technology, a store terminal device in a settlement system transmits the payment amount and the store terminal device ID received as input to a settlement mediation server, and the settlement mediation server generates a transaction number for the payment amount, to the store terminal, and the store terminal displays the QR code (registered trademark) indicating the received transaction number on the display, the QR code includes the URL of the settlement mediation server, and the QR code The server may generate the QR code, the user terminal device reads the QR code, accesses the payment intermediation server with the URL, transmits the transaction number included in the QR code, and the payment intermediation server receives the transaction information from the transaction number is specified and transmitted to the user terminal device (for example, see Patent Document 1).

Japanese Unexamined Patent Application Publication No. 2011-210171

In some embodiments of the system introduced by the assignee of the present invention, tokens are used to connect two parties wishing to conduct a transaction. For example, in the case of a purchase transaction, the system described can be used to mark a pending purchase transaction in the checkout queue at a store with proof of payment for the consumer wishing to pay the merchant for the goods associated with the pending transaction. It can be used to replace the use of magnetic stripe cards and readers used to bond together.

A transaction can be a purchase transaction, an ATM transaction, a money transfer transaction, or an authorization transaction, a check-in process, or any other transaction that requires information to be exchanged between two entities. In some embodiments, it is the merchant and the purchaser, in other cases, two people, and in other cases, the gas pump is automatically turned on (ON) or the bar. bartenders who wish to make their presence known to retailers so that they can automatically know to prepare their favorite drink.

It would be desirable to provide a system and method by which multiple transaction management systems can participate in a transaction. Further, it would be desirable to allow multiple entities or systems to perform different transaction management functions while allowing mobile device users to efficiently and reliably perform transactions.

Additionally, it would be desirable for devices involved in a transaction to be able to easily identify the 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 the point of transaction, the mobile device identifies the appropriate transaction management system to use in the transaction based on the information received from the token. Therefore, processing can be performed. As another example, in a transaction in which a transaction terminal captures a checkout token from a mobile device, the transaction terminal uses information received from the token to identify the appropriate transaction management system for use in the transaction. can be done.

A method according to one aspect of the invention includes determining, by a customer device, a transaction between a customer associated with the customer device and a merchant associated with the merchant device; in response to determining the transaction, sending, by the customer device, to a transaction management system a request for a token for the transaction, the request including information characterizing the transaction; and receiving the token from the transaction management system. wherein the token includes identification information identifying an access location for accessing functionality of the transaction management system; and for scanning by the merchant device in response to receiving the token. and displaying a quick response (QR) code encoding at least said identification information.

A customer device according to one aspect of the present invention is a customer device including a non-transitory memory storing instructions and a processor, the processor being associated with the customer and merchant devices associated with the customer device. determining the initiation of a transaction with a merchant; and, in response to determining the initiation of the transaction, sending a token request for a token for the transaction to a transaction management system, wherein the token a request including information about the transaction; and receiving the token from the transaction management system, the token being a uniform resource locator (URL) string for accessing functionality of the transaction management system; including identification information indicative of a resource identifier (URI) string; and a quick response (QR) code indicative of at least said identification information for scanning by said merchant device in response to receiving said token. displaying, and executing instructions to cause the customer device to:

According to one aspect of the invention, a non-transitory machine-readable medium is provided for determining initiation of a transaction between a customer associated with a customer device and a merchant associated with a merchant device; In response, sending a token request for a token for the transaction to a transaction management system, the token request including information about the transaction and receiving the token from the transaction management system. wherein the token includes identification information indicating a uniform resource locator (URL) string or a uniform resource identifier (URI) string for accessing functionality of the transaction management system; and receiving the token. displaying a quick response (QR) code including at least said identifying information for scanning by said merchant device in response to storing machine readable instructions for causing a machine to perform an operation. , is a non-transitory machine-readable medium.

1 is a block diagram illustrating part of a system configured in accordance with some embodiments; FIG. 2 is a block diagram illustrating a portion of the system of FIG. 1, configured for some embodiments; FIG. 1 is a block diagram illustrating part of a system configured in accordance with some embodiments; FIG. FIG. 4 is a block diagram illustrating processing for some embodiments; 1 is a block diagram illustrating part of a system configured in accordance with some embodiments; FIG. 1 is a block diagram illustrating part of a system configured in accordance with some embodiments; FIG.

Embodiments of the present invention relate to systems, methods, processes, computer program code and means for performing transactions. More particularly, some embodiments provide systems, methods, and processes for operating mobile devices to conduct transactions with merchants, service providers, and other devices (such as automatic teller machines or "ATMs"). , to computer program code and means. For some embodiments, systems, methods, processes, computer program code and means for operating a mobile device to conduct transactions are provided to enable the mobile device to communicate with appropriate entities to conduct transactions. Possible, including determining the transaction token issuing authority associated with the merchant or point of transaction. In general, embodiments include the above-referenced both pending and common mobile devices that can be used to conduct transactions by scanning, capturing, or entering codes associated with the transactions. can be deployed with the system as described by the inventor in an application having the same assignee. A feature of some embodiments is that mobile devices are used in conjunction with payment systems to conduct transactions at merchant locations or interaction locations (or, in some embodiments, ATMs, kiosks, 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 uses the services of a first transaction management system to process transactions, while a second merchant uses the services of a second transaction management system to process transactions. can be used. A consumer holding a mobile payment device with a mobile payment application according to the present invention does not necessarily need to 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 transactions related to the present invention. 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 conduct payment transactions. Additionally, embodiments can also be used in situations where a merchant system needs to determine the appropriate transaction management system to communicate with based on information received from the mobile device. The result is a system that allows multiple transaction management systems to participate in a payment system. Additionally, as further described herein, multiple tiers or collections of systems or entities can be provided that implement aspects of the transaction management system, each of which references 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 merchant authentication and basic transaction management functions. In such embodiments, when the consumer operates the mobile device to conduct a transaction with the merchant, the mobile device (and/or the mobile device working with the wallet issuer) ) must determine which token issuing authority has issued the token on behalf of the merchant so that the transaction 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, in which an initial description of transactions is provided with reference to FIG. 1 (where multiple transaction management systems can participate in a transaction). Further transaction details will be provided in FIG. 2 (in which multiple transaction management systems participate). In FIG. 3, transaction details are described in which some of the functions of the transaction management system are performed by one or more token issuing authorities and one or more wallet issuers. In FIG. 4, the wallet registration process (which can be performed between a user wishing to configure a mobile payment application on a mobile device and a transaction management system or wallet issuer) is described. In FIG. 5, further details of transaction processing are described for situations where one or more wallet issuers and one or more token issuing authorities participate in the transaction.

Some terms are used here for convenience and ease of explanation. For example, the phrase "point of transaction" is commonly used to refer to an entity, device or other object with which a user operating a mobile device wishes to conduct a transaction. For example, a "point of transaction" may be a merchant's POS terminal, merchant's website, ATM, kiosk, other individual, item with an identifier such as a printed QR code, Bluetooth®, etc. items or objects, including wireless devices or beacons, NFC chips, audio devices, or other devices that can be used to initiate transactions when working with other devices. As used herein without the foregoing limitation, 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 can be provided to the mobile device during or in connection with a transaction involving the merchant and the mobile device, depending on the merchant's location of the transaction. As another example, the token can be provided by the ATM to the mobile device during or in connection with a transaction involving the ATM and the mobile device. As yet another example, a token can be provided by a customer to an interaction location to initiate a transaction. Tokens can be provided in many different forms, as further described herein. Tokens can be issued for use in transactions in many different ways. For example, as further described herein, a token can be issued, generated, or otherwise provided by a transaction management system or a "token issuing authority."

The phrase "capturing" may be used to refer to the act of scanning, reading, or otherwise obtaining a "token" (an identifier used to facilitate transactions for some embodiments). You can. The phrase "capturing" (or "captured") is not intended to be limiting, as the mobile device can capture by keystrokes, by image capture, by RFID, BLE/Bluetooth, NFC reading, and other scanning, It is intended to include embodiments that operate to receive tokens (or data associated with tokens) using reading or other wired or wireless techniques 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 term "wireless" may refer to wired, e.g., using radio frequency or other electromagnetic radiation-based communication technology (including RFID, wifi, Bluetooth/BLE, ZigBee, or other technology). used to refer to telecommunication technologies that do not exist. Upon reading this disclosure, those skilled in the art will understand that the use of these terms is not intended to be limiting and is for descriptive purposes.

As another example, the phrase "transaction management system" refers to systems operated by entities to facilitate transactions, including mobile devices and merchants, ATMs or other devices. Generally, the transaction management system can be a transaction management system such as that described in US Pat. Nos. 8,632,000 and 8,380,177. In general, a transaction management system may transfer pending transaction information received from one device (such as a transaction location, mobile device or item) associated with a first party to another device (mobile device or item) associated with a second party. device, transaction location, etc.). In connection with some embodiments, the transaction management system uses tokens (such as checkout tokens or ATM tokens) at least in part to perform matching operations. Once the transaction information being processed is matched with the user information, further processing is performed to enable selection or identification of a suitable or desired payment account to be used to complete the transaction. can do In some embodiments, the transaction management system can perform other functions. For example, the transaction management system can perform user and mobile device authentication processes. A transaction management system can also be used to issue tokens that are used in conducting 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 Bluetooth beacon functionality to identify a particular retailer (the token may, by itself or in conjunction with the positioning functionality of the user's device, determine the user's location). (which can be used for purposes), ATMs, or other interaction locations, the transaction management system can be used to identify users associated with a particular device at one or more interaction locations at that location. can be checked in. Checking in means that the interactive location system has received certain profile information about the user, such as name, nickname, photo, loyalty program number, and preferences for frequently purchased goods and services. In addition, the check-in process facilitates that a gas station pump (interaction location) is ready to start pumping gasoline or has the bartender automatically prepare a particular drink; Alternatively, a place of interaction, such as automatically performing pre-authorization of a payment device to pre-authorize payment of a predetermined amount in order to have kitchen staff prepare a meal of the user's choice; A clerk at the interaction location will carry out 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” may perform functions such as user and mobile device authentication, as well as certain transaction processing functions. As used herein, a "token issuing authority" or "token issuer" may perform certain transaction processing functions as well as functions such as communication and authentication with merchants, ATMs or other places of interaction. I can. As used herein, the phrase "directory service" refers to services 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 implemented (e.g., based on tokens) to determine which entities and devices (such as mobile devices or merchants) should communicate in order to perform transaction processing as described herein. A service can be provided that allows for the investigation or mapping of functions to be performed. Details of such functionality will be provided further below.

Features of the present invention are described assuming use of the payment systems described in our co-pending applications referenced above, and the details of those systems are not fully repeated here. However, embodiments of the present invention are not limited to use in connection with the payment systems 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 system 100 for some embodiments. More particularly, FIG. 1 is a block diagram of a system in which multiple transaction management systems 130a-n are employed. Each transaction management system 130 may perform the functions described herein or other functions that allow mobile payment application transactions to be processed in situations involving different transaction systems. In such systems, transactions at a first merchant can require interaction with a first transaction management system, and transactions at a second merchant can require interaction with a second transaction management system. There can be an environment that can require The embodiment illustrated in FIG. 1 may enable the use of such multiple 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 the different types of transactions and transaction processing can be obtained by reference to commonly assigned patents and applications which are incorporated herein by reference.

For convenience, the various transactions will be described with reference to the payment system 100 of FIG. 1, and for convenience will first describe the situation in which a single transaction management system 130 is used. As shown, a payment account holder, purchaser, or other user or operator (herein, a "customer") may possess or use a mobile device 102 (such as a mobile phone). Portable 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 conduct transactions (payment, loyalty, returns or other transactions) with merchant 108 . Merchants 108 may be physical storefronts, electronic merchants, or mail order and telephone (“MOTO”) merchants (or other persons or entities, or customers and/or customers who may initiate transactions). any other object that can work with the device). Further, Merchant 108 need not be a "merchant", but can be another individual (for person-to-person transactions) or a kiosk or other unmanned device (such as an automatic teller machine "ATM"). It is possible.

In a typical exemplary transaction, a customer first places a product or service at a point of sale (e.g., physical checkout counter, electronic shopping cart, etc.), generally referred to herein as a "point of sale" or , referred to as "POS"), the goods or services can be purchased from the vendor 108. FIG. Merchant 108 initiates the checkout transaction in the usual manner by tallying the items to be purchased (eg, by bar code scanner, keying in merchandise code, etc.). A merchant (operating via a store clerk, display screen, customer-facing POS terminal, etc.) prompts the customer to select a payment option. In previous systems, merchants might prompt customers to select "credit," "debit," or other payment options. In the context of the present invention, merchants (operating via store clerks, display screens, customer-facing POS terminals, etc.) can prompt customers for those options along with mobile payment options. If the customer selects the mobile payment option, features of the present invention are utilized to process the transaction.

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 teaching the selection to a store clerk), the selection is It can be done by the customer's action of scanning, capturing, or entering a checkout identifier or "token" (as described below). For example, in such embodiments, the act of capturing a token used in the present invention will cause the transaction to proceed in relation to the present invention.

Once the mobile payment option has been selected and a purchase total generated, merchant 108 sends a merchant payment authorization request message to transaction management system 130 (via path 116). The Merchant Payment Authorization Request message may contain one or more data or information regarding the transaction. For example, this message can include one or more of a merchant identifier, payment amount, and tokens used to identify the transaction with the merchant for further processing, as further described herein.

Several techniques can be used to generate or present tokens. For example, in some embodiments, one or more tokens can be predefined or established for use with a given merchant 108 (e.g., merchant 108 displays at points of sale, Alternatively, you may have some checkout token that you can use to present). In such embodiments, merchant 108 would select the token to use in a given transaction. In some embodiments, such tokens can be generated or presented using standard formats. In the illustrative example, the merchant 108 can be issued or provided with tokens or a range of predefined numbers or series of numbers. As a specific example, merchants can be instructed to use a number range (eg, "00000" to "99999") along with a number sequence or usage pattern (eg, a particular checkout token can be can only be used for one valid transaction). In such embodiments, the POS system would provide the selected token to transaction management system 130 . In other embodiments, however, the token is issued or selected by the transaction management system 130 (as described further below) and provided to the merchant 108 in response to a merchant authorization request message. . Those skilled in the art will appreciate that other techniques for issuing, using and selecting tokens can be used. In some embodiments, tokens are issued by a "token issuing authority," as further described below.

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

From the customer's perspective, the payment process of the present invention can begin with the customer performing an authentication process to confirm their identity and authority to conduct transactions using the present invention. The authentication process can be performed after the customer has selected the mobile payment option at the point of sale, or in some situations 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 mobile device 102 and providing one or more credentials or items of information to transaction management system 130 via communication path 114 . can be done. For example, the authentication process can include entering a user identifier, password, or other credentials into a login screen or other user interface displayed on display device 136 of mobile device 102 . Transaction management system 130 compares the received information with stored information to authenticate the customer. Further, as described herein, different transaction management systems 130a-n can be included, and different mobile devices can interact with different transaction management systems 130a-n to perform this authentication process. . Further, in some embodiments, the function of performing authentication can be performed by the entity that issued the mobile payment application used by the consumer. Such entities may be referred to herein as "wallet issuers".

The authentication process, in some embodiments, also includes one or more attributes of the mobile device 102 and stored attributes of attributes collected from the mobile device 102 during the enrollment process (such as the process of FIG. 3). Includes comparisons with sets. For example, attributes can include an identifier associated with mobile device 102 that uniquely identifies the device. Thus, the customer is authenticated two-way by something they know (login credentials) and something they have (mobile 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 to the transaction management system 130 as part of the registration process. In some embodiments, the authentication process is performed between the mobile device 102 and the wallet issuer, as further described herein.

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

Either "static" tokens or "dynamic" tokens are used in connection with some embodiments. In embodiments where "static" tokens are used (e.g., those that are assigned for use by the location of a particular transaction and do not contain any variable information for each transaction), transaction management system 130 matches the information in the customer transaction retrieval request (received from mobile device 102) and the merchant payment authorization request (received from merchant 108) to the token information received in each message. Do it by letting it. When a match is made, the transaction management system 130 sends a transaction detail message (via path 114) to the customer's mobile device 102. FIG. 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, provide one or more marketing messages to the customer. In addition, the transaction management system 130 also transmits to the phone a list of payment accounts that the customer has registered with the system, including credit, debit, check, prepaid and other types of accounts. The list of accounts may include all of the accounts that the customer has registered with the system, or partial accounts based on rules established by the mobile payment network operator, merchant, issuer of each payment account, customer or other entity. Collections can be included (eg, the list of accounts sent to the mobile device only includes accounts that can be used for the current transaction). In connection with some embodiments, the list of accounts can contain only a single account or multiple accounts. Further, the list of accounts does not include proof of actual payment; rather, proof of actual payment is provided to transaction management system 130 (or, in some embodiments, wallet issuer, as described below). stored in (or accessible to). As such, the mobile device 102 does not store sensitive payment account information. For example, the list of accounts may simply contain an identifier (such as a proxy) to allow the transaction management system 130 or wallet issuer to identify the actual proof of payment associated with each customer's account. I can. Here, the customer can see on the display 136 of the mobile device 102 the name of the merchant to be paid, the payment amount, 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, such derivation may be required by the merchant adopting new payment methods, such as where the merchant cannot easily change its system to send static tokens to the transaction management system 130. reduces or even eliminates the need for equipment upgrades and software changes. Tokens can be derived using a mapping table that maps merchant identifiers, terminal identifiers, or other information (sent to transaction management system 130 by the merchant's system) to tokens. Based on the received identifier, a mapping process occurs to identify the appropriate token for use in that payment transaction. The selected token is made available to match transactions from the customer message queue in the transaction management system 130 (or wallet issuer, as described below) in the transaction management system 130 ( Alternatively, associated with a transaction in a merchant transaction queue (at the token issuing authority), as described further below. Those skilled in the art will appreciate that other matching and mapping techniques can also be used. In any event, a 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 mobile device in connection with the present invention. become).

(e.g., the token is generated by either the merchant 108, the transaction management system 130, or the token issuing authority prior to being displayed on a display device associated with the merchant during the checkout transaction; and In embodiments using "dynamic" tokens (where the token contains additional information about the transaction), the checkout process can proceed without having to send a customer transaction retrieval request message to the transaction management system 130. I can. For example, in some embodiments, some or all of the transaction details are encoded in dynamic tokens that, when captured and processed by the mobile device 102, provide the transaction details to the mobile device 102. Rukoto can. Further details of embodiments of both "static" and "dynamic" tokens are further described below or contained in commonly assigned applications incorporated herein by reference. . In either case, however, the token will pass messages from the mobile device 102 and messages from the merchant 108 to the transaction management system 130 (or a combination of the wallet issuer and token issuing authority as described herein). ) to process matches.

To complete a payment transaction, the customer interacts with mobile device 102 to select the desired payment account to use in the current transaction, and a customer payment authorization request message is sent (via path 114) to the transaction. to be 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 a final chance to confirm or cancel the payment transaction. Steps are optional. The customer confirmation or cancellation is sent from mobile device 102 via path 114 to transaction management system 130 as a customer payment authorization message.

Upon receipt of a payment authorization message from the customer's mobile device, the transaction management system 130 (or, as further described below, in some embodiments, the wallet issuer or other entity) approves the transaction. Generating an Authorization Authorization Request message for transmission over one or more payment processing networks (not shown in FIG. 1) to authorize, clear and settle funds. This request message contains the amount of the transaction, or at least a pointer or reference to the associated merchant payment authorization request (received from merchant 108) and a customer selected, pre-stored in transaction management system 130 (and portable Include information from the Merchant Payment Authorization Request, such as a payment account identifier identifying the payment account (identified by a proxy or other identifier received from the device). The authorization process may be a standard authentication process on one or more authentication networks (e.g., VISANET operated by Visa, Inc., hereinafter simply referred to as "payment processing" in FIGS. 2, 3, 5, and 6). ® network, automated clearing house systems such as the National Association for Automated Clearings (NACHA), etc.). Once available funds are confirmed, the transaction management system sends a Merchant Payment Authorization Response message (via path 116) to the merchant and the transaction can be completed at the point of sale. The customer payment authorization response message can also be displayed to the customer at the point of sale and/or sent to the customer's mobile device.

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

In connection with some embodiments, the mobile device 102 is, for example, an iPhone®, an Android® phone, or capable of accessing and displaying web content or accessing the Internet. It can be a smart phone or a web-enabled mobile device such as any phone. In some embodiments, mobile device 102 communicates with transaction management system 130 using a cellular or wireless network. In some embodiments, transaction management system 130 is a secure server (or network of servers). In some embodiments, the transaction management system 130 (or, in some embodiments, the wallet issuer and/or token issuing authority) uses the VISANET® network operated by Visa, Inc. One or more payment processing networks, such as the BANKNET® network operated by MasterCard International, Inc. (not shown in FIG. 1, but indicated as "Payment Processing" in FIGS. 2, 3, 5 and 6) (is there). Transaction management system 130 (or, in some embodiments, wallet issuers and/or token issuing authorities) allows customers operating mobile devices 102 to use a wide range of different forms of payment instruments and accounts. We may also communicate with other financial transaction networks (such as ACH and EFT networks, private label networks, and other payment systems such as PayPal(R)) so that we can conduct transactions with you. Transaction management system 130 (or, in some embodiments, wallet issuers and/or token issuing authorities) may also include Google®, Apple®, Yahoo®, Microsoft It can communicate with one or more advertising or offering management networks, such as those provided by .RTM. Data, including advertisements and offers, can be received from those networks and provided to the customer via the mobile device 102, as described further below.

In some embodiments, other devices can obtain tokens and/or initiate transactions. For example, in some embodiments, a customer operating a mobile device 102 obtains a token for use in a transaction and uses other participants in the transaction (merchants, other customers operating other mobile devices). etc.) can be provided with the 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 point of interaction (merchant 108, other mobile device, etc.). can be performed by the consumer operating the mobile device 102 to do so. For example, when a token is acquired by the mobile device 102, the mobile payment application may have the token (or an encoded version of the token, such as a QR code) read or captured at the point of interaction. , can be displayed on the display screen of the mobile device 102 and transmitted to the location of interaction, such as via a wireless communication link. For example, processing at vendor 108 may proceed as follows (although other processing flows may also be used with favorable results).

Initially, a store clerk associated with merchant 108 scans the items at the POS terminal to generate an initial basket or collection of items to be purchased by the customer operating mobile device 102 (scanning the items may also generate tokens). For convenience, scanning the item is described as occurring first, although it can occur after it has been captured and acquired in this illustrative embodiment). operating a mobile device 102 configured with a payment application associated with the present invention; A consumer (who has registered a payment account) decides to use mobile device 102 to conduct a payment transaction with merchant 108 and uses mobile device 102 to request a token for use in the transaction. interact. This request causes a message to be sent to transaction management system 130 . The message also contains information that authenticates the consumer, along with the consumer's mobile device (as described above), and the transaction management system 130 generates a token for use in the transaction and a token in the transaction queue. , use data from the message to generate an in-flight transaction record.

Transaction management system 130 causes a message to be sent to mobile device 102 that includes data associated with the token for use in the transaction. The mobile device 102 (under control of the payment application of the present invention) causes the token to be displayed on the mobile device 102 display screen. 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's clerk or merchant's POS system for capture. be encouraged to do so. When the merchant system 108 captures the token from the mobile device 102, the merchant system 108 associates the token with details of the transaction in process (which can include the total amount of the transaction and other details of the item scanned) and provides information about the transaction. Send a process transaction request message to the transaction management system 130 that includes the token information (which can include the amount of the transaction, among other information). For example, the message includes information identifying the token (received from the mobile device 102) and information identifying the cash register, POS terminal, merchant 108, location, amount of the transaction, item details of the item purchased. Can contain data elements. Transaction management system 130 uses information from the processing transaction request message to identify pending transactions in the transaction queue and update the transaction queue.

A request message containing information about the transaction received from merchant 108 , including the amount of the transaction, is sent from transaction management system 130 to mobile device 102 . Additionally, a message can be used by a customer in a particular transaction (e.g., by applying one or more merchant-specific rules, one or more system-specific rules, and one or more customer account rules). It may contain information identifying one or more of the customer's available payment accounts identified by management system 130 . A customer interacting with mobile device 102 selects an available payment account from the information received from transaction management system 130 and causes the selected account information and a transaction confirmation message to be sent to transaction management system 130 .

For some embodiments, some or all of these messages between mobile device 102 and transaction management system 130 may be sent in one or more transaction sessions. That is, session control allows the same mobile device 102 to both request tokens, receive information about available payment accounts, and select available payment accounts in a single transaction session. Initiated to assure. Thus, embodiments ensure that different customers or users cannot reuse or copy different users' payment information. Moreover, this method ensures 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 receipt of the payment account selection and 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). send to The payment authorization request message includes the actual proof of payment (identified based on information received from mobile device 102), the amount of the transaction, and merchant information. Upon receiving an authorization response from the payment processing system, the transaction management system 130 causes an acknowledgment message to be sent to the merchant 108 (the acknowledgment is also sent to the mobile device 102). In-flight transactions are also removed from the transaction queue. Thus, a payment transaction is performed by enabling the mobile device 102 to obtain a token for use in the transaction and provide the token to the Merchant 108 for use in the transaction. can do This transaction processing can also be used with loyalty, discount, and other types of transactions. Additionally, the process can be used to conduct transactions at other types of merchant locations (including MOTO, Internet, etc.), ATM machines or kiosks, etc., and in person-to-person transactions.

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

As described further below, transactions conducted using embodiments of the present invention have several desirable advantages over existing payment methods. For example, customers can use their mobile devices to conduct payment transactions at a wide variety of merchant locations. Additionally, the mobile device can be used to access a variety of different payment accounts held by the customer, allowing the customer to select the most appropriate or desired payment account for each transaction. make it possible. Using features of the present invention, embodiments can utilize existing point-of-sale systems and hardware, eliminating the need for merchants to install or replace expensive hardware. Moreover, paying according to embodiments of the present invention is more secure than existing payment methods. This is because each transaction has two attributes: user information known to the customer (user identifier and/or password or PIN) along with a unique attribute associated with the mobile device used by the customer to initiate the transaction. This is because it is possible to request authentication using an item. Other benefits and advantages will become apparent to those skilled in the art upon reading this disclosure.

For some embodiments, system 100 includes multiple transaction management systems 130a-130n. Each (or some) merchant 108 has an association or relationship with one or more transaction management systems 130a-130n, and a customer operating a mobile device 102 can determine which transaction management system 130a-130n It does not need to know if it is 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 can be determined by which transaction management system 130a-n was previously involved in any given transaction. It does not necessarily need to know whether it is participating (until such information is confirmed during the transaction, as described herein).

As described in both co-pending applications, processing a purchase or other transaction, in accordance with some embodiments, includes generating, scanning, or otherwise capturing a token associated with the location of the transaction. In some embodiments, this token can be dynamically generated for use in individual transactions at a particular merchant or location. Scanning or capturing the token by mobile device 102 causes information to be sent to transaction management system 130 for use in completing the transaction. For some embodiments, token-related data can be used in connection with identifying or selecting an appropriate payment account for a transaction. As described herein, the data associated with the token is also sent to any transaction management system 130a-- to retrieve information about the transaction at the merchant (eg, information identifying payment amount, retailer name, etc.). n can be used to determine whether the mobile device should communicate.

For some embodiments, mobile device 102 (or merchant 108, in situations where a token is provided from mobile device 102 to a merchant system in the transaction) may, during a given transaction, determine which transaction management system 130a-n Any of a number of different methods can be used to determine if should be contacted. For example, in some embodiments, when a mobile device 102 scans or otherwise captures a token at a point of sale, the token is sent by the mobile payment application to contact the appropriate transaction management system 130a-n. It can contain 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 mobile device 102 to route access to the appropriate transaction management system 130a-n. It is possible to As an illustrative example, the URL https://paydiant.com/tms/production can be included directly within the token along with the token value itself. In such embodiments, the URL or URI is encoded using a URL encoding method such that the mobile payment application can efficiently and accurately decode the URL or URI from the token along with the value of the token. can be made into

As another illustrative example of information that can be included in the token, a formatted URL string can be encoded within the token for capture and processing by the mobile payment application (e.g., the URL string can be can be encoded in a QR code, etc.). A formatted URL string can have the following structure: https://<hostname/ipaddress>:<port>/<tokenIssuingAuthorityIdentifiter>/<issuedToken>/<transactionMetaData>. An exemplary string that follows this format can 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 a mobile payment application (e.g., URI-based The identifier can be encoded as a QR code, etc.). A token can be an alphanumeric token such as "3ab0f564-82b5-4846-83a0-604c44989c59". This string can be used to look up the appropriate transaction management system (or wallet issuer/token issuing authority) for interaction. Tokenized string identifiers can also be used. For example, the tokenized string can be formatted in a variety of ways, including as illustrative (non-limiting) examples: <tokenIssuingAuthorityIdentifier>:<issuedToken>:<transactionMetaData>.

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

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

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

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

In some embodiments, the value from the token itself may not be required to determine the appropriate transaction management system 130 to use. For example, the mobile device 102 or merchant 108 may specify any number of factors such as the time of day, day of the week, current transaction volume at the interaction location, purchase amount, or any other factor that determines which transaction management system 130 to use. One or more rules can be adhered to based on factors such as: The mobile device 102 or merchant 108 also sets a default transaction management system 130 (which defines a default transaction management system 130 to use if no specific transaction management system 130 has been specified in association with the token). , and transaction management system 130 modifies based on one or more rules that evaluate data, which can include one or more data items from tokens or data items from any other source. It may be possible.

For a further embodiment, a token captured by mobile device 102 carries an identifier that can be decoded by a mobile payment application on mobile device 102 to derive a path to associated transaction management system 130a-n. can contain. For example, an algorithm could be used to translate identifiers received in tokens into paths to the appropriate transaction management system 130 . As an illustrative example, the simple identifier "V1P" can be used to construct a path for https://visa.com/1/production based on the following method: 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 maps to , to the “production” subdirectory. Similar methods and mappings can be used to generate a wide variety of URL/URI schemes so that the mobile payment application on the mobile device 102 can efficiently route the correct path to communicate with the appropriate transaction management system 130. make it possible to identify Those skilled in the art, upon reading this disclosure, will appreciate that other techniques can also be used to determine the appropriate path to the transaction management system.

In some embodiments, the functions performed by transaction management system 130 may be performed by one or more entities. For example, in some embodiments, functions performed by transaction management system 130 may be performed by wallet issuers and token issuing authorities. In some embodiments, the functions performed by the wallet issuer can include, for example, functions related to user management, user authentication, and some basic transaction management. Functions performed by the token issuing authority may include, for example, merchant management, merchant authentication, and some basic transaction management related functions. Several different wallet issuers (e.g., issuing mobile wallets to multiple consumers and their For the consumer, there can be a user-related function). Features of such an embodiment will be described with reference to FIG.

Further details of certain aspects of systems according to 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 showing communication paths between mobile device 202 , merchant 208 , one or more transaction management systems 230 and payment processing system 232 . Portable device 202 can be, for example, a mobile phone, a PDA, a personal computer, or the like. For example, mobile device 202 may be an Apple iPhone®, RIM's BlackBerry®, a mobile phone using the Google Android® operating system, or the like. For some embodiments, the mobile device 202 can run a payment application, allowing the mobile device 202 to act as a payment device as described herein. In some embodiments, mobile device 202 is configured so that a customer operating mobile device 202 can interact with one or more transaction management systems 230 to initiate transactions via a web interface. , can access and display web content or access the Internet.

Portable device 202 of FIG. 2 may, for example, communicate over one or more wired and/or wireless networks 201 . As an example, the wireless network may be a cellular network (represented by cell transmitter 215). Mobile device 202 can communicate over a cellular or other wireless network via gateway 216 and can communicate with network 214 (eg, the Internet or other public or private network, etc.). An access point, such as access point 218 , may 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 embodiments in which mobile device 202 drives a payment application that enables mobile device 202 to function as a payment device with respect to the present invention, the payment application connects network 201 to one or more transaction management systems 230 . It can generate or control the communication of data via.

In some embodiments, mobile device 202 is capable of both voice and data communications over wireless network 214 via access point 218 . For example, mobile device 202 may make or receive phone calls, send and receive emails, and send and receive Short Message Service (“SMS”) messages over a wireless network via 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 communications can occur via network 215 .

In some embodiments, mobile device 202 may establish communications 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.). can also Mobile device 202 may, for example, use one or more transaction management systems 230 (to create, edit, view, or change payment account settings and selections for conducting payment transactions, etc.), web 240 . and other services 242 on network 201 . Mobile device 202 may 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 mobile device 202 . Such access can be provided by web browsing functionality or invocation of an application (eg, browser) in response to the customer launching a web browser application installed on mobile device 202 . In some embodiments, a user uses a web browser to interact with one or more transaction management systems 230 to register payment accounts, establish account selections, conduct payment transactions, etc. can be used.

Portable device 202 has a display screen 236 and a data input device 238 (such as a keypad or touch screen or voice interface). With respect to embodiments of the present invention, customers use mobile device 202 to conduct purchase transactions with merchants 208 (or ATM transactions with ATMs or any other transactions supported by the system of the present invention). can do Merchant 208 can be a physical storefront, an electronic merchant, or a MOTO merchant (or other person or entity). Mobile device 202 , in some embodiments, also includes a camera (not shown) or other image capture device such that mobile device 202 can capture an image or representation of token 210 . Mobile device 202 , in some embodiments, also includes a wireless receiver (not shown) or other wireless signal receiving device such that mobile device 202 can capture wireless signal representations of token 210 . have For example, a customer may use the present invention to take a digital photograph or capture an image of a token displayed on or on a merchant point of sale device to initiate a payment transaction. The mobile device 202 can be operated. The captured image is shown as item 237 on display screen 236 . As explained further below, tokens 210 can be used to initiate and conduct transactions with merchants.

Merchant 208 may, as described, process payments and transactions, including payment transactions (as well as "traditional" or standard payment transactions, including cash, standard payment cards, etc.) in the context of the present invention. , can operate one or more merchant systems 209 . Merchant system 209 may be a networked point of sale system (for physical retailer locations) or may be a shopping cart system (such as for electronic commerce or Internet retailer locations). . Merchant system 209 can also be an ATM network or the like, where the "merchant" is an ATM device. Merchant system 209 may also be a combination of systems designed to allow merchants to receive payments for merchants and services. In some embodiments, merchant system 209 may communicate with one or more point-of-sale devices 212 having display devices 213 for presenting and receiving information from customers. For example, if merchants 208 are physical retailer locations, merchant systems 209 may each be located in different checkout lanes or locations within the store (or in different stores at different geographic locations). ), which can communicate with several different point-of-sale devices 212 . Each point of sale device 212 presents transaction information to the customer at the point of sale (or "POS") so that the customer can authorize or authorize the purchase and submit payment for the purchase; can be displayed or communicated.

As another example, where merchant 208 is an Internet or other electronic merchant, merchant system 209 may include a web server (or any Internet-accessible server) configured to process purchase transactions associated with merchant 208 . network of servers). Point of sale device 212 is capable of interacting with merchant system 209 via a network, such as the Internet in such an example, and interacts with merchant system 209, e.g., personal computer, mobile device, etc. , which can be several remote terminals. Since embodiments of the present invention can initiate and execute transactions with both physical and remote types of merchants, the point of sale, the point of purchase, or the interaction between a buyer and a merchant , may be referred to herein as a "place of sale" or "place of interaction".

For embodiments of the present invention, tokens 210 are displayed at or near the point of sale. A token can be either a "static" token or a "dynamic" token. In situations where static tokens are used, the tokens are placed near the location of the point of sale (on stickers or placards so that customers can easily see, read, or capture the tokens). printed, displayed or provided. Static token 210 can be printed as a barcode image, as an alphanumeric identifier, or in some other form. In some embodiments, the token can be presented in a form readily readable by a human, such that it can be both keyed in or captured using the mobile device 202 . In embodiments where static tokens are used, additional processing steps may be performed (as described further below) to provide mobile device 202 with detailed information about the transaction.

In embodiments where dynamic tokens are used, the tokens may be displayed on display devices 213 associated with point of sale devices 212 . A dynamic token can be generated to contain transaction information (eg, purchase amount), and in some embodiments, can be a token between mobile device 202 and transaction management system 230 during a payment transaction. It can contain fewer messages in between. Token 210 may be captured as a barcode image, as an alphanumeric identifier, as a radio signal, or in any other form in which token 210 may be captured as an image (eg, using a camera or scanner associated with mobile device 202). It can be encoded or displayed. Token 210 can also be keyed in by the customer of mobile device 202 or captured by a wireless receiver associated with mobile device 202 . In some embodiments, the mobile device can operate with multiple types of tokens 210 (e.g., the mobile application can perform image capture, Radio reception or keystrokes can be used to capture the token 210).

Display device 213 can be an LCD (or other display technology) display (such as those currently available from many vendors for systems such as the Hypercom 4150 terminal or the Verifone MX870 terminal). ). The use of token 210 in transactions with respect to the present invention will be further described below. In general, however, token 210 uses information stored in or accessible to transaction management system 230 to process payment requests from mobile devices as payment authorization requests from merchant 208 to complete payment transactions. Used by transaction management system 230 for reconciliation processing. In embodiments where token 210 is a dynamic token, the token can also be used to communicate transaction details from merchant 208 to mobile device 202 .

In a typical exemplary transaction, the customer first selects mobile payment as a payment option and authenticates with the payment application on mobile device 202 (or alternatively via a web browser interacting with transaction management system 230). process and capture token 210 from a device associated with merchant 208 (such as from display 213 of point of sale device 212), transaction details and payment account list or preferred or available from transaction management system 230 purchases goods or services from a merchant 208 by receiving a list of available accounts, selecting a payment option on the mobile device 202, and submitting a customer payment authorization request to the transaction management system 230 across the network 201; can do

Selecting a payment option includes receiving information identifying one or more payment accounts available to the customer. The available payment accounts may be specified by the customer during a registration process, such as the process described further below in connection with FIG. In connection with some embodiments, the presentation of different payment account options is based on a list of available payment accounts such that the customer is presented with the account most suitable or available for the current transaction. , can include applying one or more rules or selections. The customer selects the payment account (or account, in the case of a compound trade 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 subsequently received from the transaction management system 230 (after processing the customer transaction retrieval request) may include additional metadata or information associated with each payment account (e.g., current account balance available, any special offers available if the account is used in the current transaction, etc.). In some embodiments, the list of accounts subsequently received from transaction management system 230 is based on the application of rules in transaction management system 230 (eg, application of one or more customer, merchant, or system rules). , can contain fewer accounts. For example, a rule may specify that a particular payment account should not be used for low value transactions. In such a case, that particular payment account would not be included in the list of accounts sent by the transaction management system in response to the customer transaction retrieval request. In other words, after processing a customer transaction retrieval 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 transmits a merchant payment authorization request message to transaction management system 230 over the network. Transaction management system 230 uses token 210 to match customer payment authorization requests (received from mobile device 202 over network 201) with merchant payment authorization requests (received from merchant 208 over network 220). do.

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

In some embodiments, the transaction management system 230 may send a customer payment confirmation request message to the customer's mobile device 202, giving the customer a final chance to confirm or cancel the payment transaction. make it possible. For example, the customer can be prompted to "confirm" or "cancel" a payment transaction. The facilitation can provide additional information about the transaction and the selected payment account, allowing the customer to 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.

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

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

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

An exemplary system is similar to the system shown in FIG. 2, except that one or more token issuing authorities 250 and one or more wallet issuers 260 are shown instead of transaction management system 230. is shown in FIG. 3 (however, in some embodiments, one or more transaction management systems 230 are in a system that operates with one or more wallet issuers 260 and one or more token issuing authorities 250). , is still available). As shown in FIG. 3, wallet issuer 260 may communicate with mobile device 202 via one or more network paths. In general, wallet issuer 260 and each mobile device 202 operating a mobile payment application issued by wallet issuer 260 can communicate (e.g., the mobile payment application can communicate with the wallet issuer associated with mobile device 202). H.260 can be encoded to ensure reliable interaction and communication with H.260). Further, token issuing authority 250 communicates with one or more merchants 208 via one or more network paths. In some 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, although wallet issuer 260 is shown communicating with one or more payment processing networks 232 , in some embodiments the token issuing authority also communicates with one or more payment processing networks 232 . can communicate. Further details of transactions involving these entities will be provided below, along with the description of FIG.

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

The registration process 400 of FIG. 4 begins when a customer first registers with a registration server (which can be a component of or associated with the transaction management system 230 of FIG. 2 or the wallet issuer of FIG. 3). Start when you interact to start processing. For example, a customer may access a registration web page associated with a registration server or use features of a mobile application to complete a registration process (on either a mobile device or other computing device). ) can operate an Internet browser. The registration web page may request the customer to provide certain methods to initiate the account creation process. For example, a customer may provide name, address, other contact information, as well as contact information, including one or more email addresses and phone numbers. A customer identifier or other unique record (or records) may be established in a database associated with or accessible to transaction management system 230 or wallet issuer 260 . A 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 (or wallet issuer 260, etc., depending on the embodiment) or information provided by or based on the customer (e.g., mobile phone number Alternatively, it can be an identifier associated with the mobile device 202).

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

Processing continues at 406 where the customer provides information about one or more payment instruments or accounts with which the payment system of the present invention wishes to be associated. In other words, the customer provides information about one or more payment accounts with which the customer wishes to associate the customer's account relationship with transaction management system 230 (or wallet issuer 260, depending on the embodiment). For example, a customer can enter information about one or more credit cards, debit cards, gift cards, bank accounts, checking accounts, and the like. Information about each account includes proof of actual payment or information sufficient to process a transaction using that account. For example, for a credit or debit card, the information can include the primary account number (or PAN (Permanent Account Number)), expiration date, and verification code. For bank accounts, the information can include routing numbers and account numbers. 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 that she wishes to utilize in connection with the present invention. These are the primary account number (or PAN) of #######, a Chase Credit Card with a card expiration date of 05/12, an ABA number of ####### and a ###### A Webster Bank checking account with an account number of ##, a PAN of ######## and a Webster Bank Visa debit card with a card expiration date of 06/11, a PAN of ###### and 8/ Includes Starbucks gift cards with 10 expiration dates. Additional account identification information can be provided as needed (eg, in some embodiments, for payment cards, a card verification number can also be provided). 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 dates, verification codes), payments made using the present invention are eligible for discount redemption as "card gift" transactions. can do With some embodiments, customers can add, remove, or update account information as needed.

Processing continues at 408 where the customer may optionally establish one or more preferences or rules associated with using one or more of the accounts entered at 406 . For example, a customer can designate one account as the "primary" or default account. Other rules and preferences can also be set so that accounts are efficiently and logically selected and used. For example, a customer can specify priorities or other account-based rules that indicate how a particular payment account should be treated with respect to other payment accounts. Customers can also optionally specify usage limits or balance terms governing when and how payment accounts should be submitted. The customer may also specify the order of accounts displayed on the mobile phone based on which merchant they purchase from, or the funds available in each account, or the rewards received for using each account. I can.

In some embodiments, rules (such as customer-specific rules) can cause the payment process to proceed faster or in fewer customer steps. For example, a customer can specify that a default payment account should be used when making purchases at a particular merchant (certain types of purchases, such as purchases of less than a certain amount). In such circumstances, a purchase transaction using the present invention can proceed without the customer having to select or confirm a payment account option, which is automatically through the application of customer-specified rules. is performed on

After reading this disclosure, one skilled in the art will appreciate that a wide variety of account-level rules can be specified to allow control over how (and when) a payment account is presented to a customer as a payment option. will understand what can be done.

In the illustrative embodiment introduced above, a customer called "Jane" specified the following account preferences. (i) she wants to use less credit and (ii) she wants less transaction fees. Jane also specified rules to 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 checking account or debit card associated with a checking account should be used second. (although she prefers not to use a checking account if the transaction reduces her balance to less than $1,000) and (iii) her credit card is , with the lowest priority, should be the last payment option.

When Jane uses her mobile device to conduct a transaction using the present invention, the transaction management system 230 (or wallet issuer 260) determines which payment accounts are available for the transaction. will compare the rules and selections specified by Jane with the details of the transaction to recommend For example, if Jane uses her mobile device to purchase a cup of coffee at Starbucks, the transaction management system determines 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 a selection of payment options based on their overall preferences and intended use. Additionally, payment accounts that cannot be used or are not suitable for a particular transaction should be made available to the transaction management system 230 (or wallet issuer 260) so that the customer does not have to be presented with such a payment account as an option. ) would be identified as such (eg, if Jane buys gas at a gas station, she would not be presented with a Starbucks gift card as the payment account for that transaction).

In some embodiments, processing may continue at 410 if the customer operates or uses a mobile device (iPhone or Android phone) capable of operating applications related to 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 quickly and easily perform payment transactions related to the present invention. For phones or devices incapable of running such applications, a link or web page may be provided to the customer that can be accessed via a mobile phone browser so that the customer can perform payment transactions in connection with the present invention. , can be generated or provided.

Once a customer establishes an account relationship with transaction management system 230 (or wallet issuer 260, depending on the embodiment) and registers one or more payment accounts with transaction management system 230 (or wallet issuer 260). Customers can then utilize the system of the present invention to conduct purchase transactions at merchants that support the transactions 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 transactions interacting with multiple transactions involving multiple mobile devices 202 and multiple merchants 208 (or other interaction locations such as ATMs, other mobile devices, etc.). There may be a wallet issuer 260 and multiple token issuing authorities 250 . For example, some consumers obtain a mobile payment application on their mobile device 202 from their financial institution or other entity, and the financial institution or other entity provides these consumers with a wallet issuer 260 (or use an agent that performs the functions of a wallet issuer). Certain merchants 208 may choose to interact with certain token issuing authorities 250 but not with others. Alternatively, merchant 208 can use a single token issuing authority. Each of these choices represents a set of parties participating in a given transaction between the consumer and the merchant 208, and overcomes the technical challenge of allowing all participants to successfully participate in the transaction. offer. Embodiments provide systems and methods such that transactions can occur despite potentially large and diverse numbers of participants.

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

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

In the illustrative embodiment illustrated in FIG. 5, the merchant 108 has several relationships, and in the transactions shown (interactions labeled as "1") , to request the issuance of 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 otherwise identifies a token for use in the transaction. Token issuing authority 250b can also generate in-flight transaction records associated with the token. In some embodiments, pending transaction records may include information including merchant identifiers, terminal identifiers, transaction amounts, and other data related to pending transactions. For some embodiments, tokens generated or obtained by token issuing authority 250b include information that can be used to identify token issuing authority 250b. As noted above, such information may be a formatted URL string (which, in some embodiments, provides the token issuing authority 250b with the URL along with other transaction-related information), a URI based identifiers, tokenized string identifiers, etc. The token (including the token identifier and information identifying the token issuing authority) is returned to merchant 108 for presentation or communication to mobile device 102 .

After reading this disclosure, one of ordinary skill in the art will appreciate that, in some embodiments, information identifying tokens and token issuing authorities is also pre-stored or made available locally 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 interaction "2"). Once captured, the mobile payment application on the mobile device 102 can be manipulated to decrypt the token (shown as interaction "3") in order to obtain the information contained therein. there). In some embodiments, decryption of the token may involve a cooperative process between the mobile device 102, the mobile payment application, and the wallet issuer 260 that issued the mobile payment application, or other device. . Decryption of the token can be any or all of the following: identification of the particular token issuing authority 250b that issued the token, the actual token value, and any metadata provided with the token value.

At this point in the transaction, the token issuing authority 250b has a pending transaction record received from the merchant 108 containing details of the transaction. The pending transaction record can be identified using a token issued or provided by the token issuing authority 250b. However, the token issuing authority 250b may not have information about the customer or the payment mechanism used by the customer at this time. The customer (via the mobile payment application on the mobile device 102) can have information about the pending transaction, as long as it is provided in the metadata decrypted in "3", and has token issuance authority. Along with information that can be used to identify the person 250b can have a token value. The wallet issuer 260 authenticates the customer and the mobile device 102 and has information related to tokens received or captured by the mobile device 102 . In general, at this point, the wallet issuer 260 also knows the identity of the token issuing authority 250b. The wallet issuer 260 also knows certain items of metadata associated with the transaction (if those items were provided with the token). For example, consider the illustrative example where the token is encoded in a formatted URL string having the following format: https://<hostname/ipaddress>:<port>/<tokenIssuingAuthorityIdentifiter>/< issuedToken>/<transationMetaData>. The string received by the mobile device 102 at "2" and decrypted at "3" can reveal a URL string formatted as: https://176.64.73.134:8663/pydt/y7uyjhd7 /USD/34000/MID01001, which is accessible at https://176.64.73.134:8663 by the appropriate token issuing authority 250b to interact with the mobile device 102, mobile payment application and wallet issuer 260. , “pydt”, it is possible to determine that it is a token issuing authority. The token used to identify the transaction record being processed is "y7uyjhd7" and the transaction is in US dollars with a value of $3,400 at the merchant identified as "MID01001". Additionally, wallet issuer 260 may have location and other data received from mobile device 102 .

In some embodiments, processing at "3" may not result in mobile 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 specifying the transaction amount). In such situations, one or more additional interactions are required. For example, one such additional interaction is shown as interaction "4" in which the mobile device 102 interacts with the wallet issuer 260 in a request for transaction details. Processing at "4" can include the mobile device 102 providing the token value to the wallet issuer 260 along with information used to identify the token issuing authority 250b. The wallet issuer 260 issues a request to the token issuing authority 250b requesting details of the transaction associated with the pending transaction record associated with the token value obtained by the mobile device 102 at "2". can be done. (if the token obtained in '2' does not have or does not have enough metadata about the transaction) process in '4'; or (if the token obtained in '2' does not have enough metadata about the transaction) ), then processing at "3", processing can continue as described below.

The wallet issuer 260, interacting with the mobile payment application on the mobile device 102, can proceed to perform the process of determining which customer's payment accounts can be used for transactions. For example, wallet issuer 260, which stores customer preferences and rules, states that only some customer payment accounts are available for use at merchants identified by "MID01001" (or based on merchant type and location). You can judge what you can do. The wallet issuer 260 can also determine that only certain payment accounts are available for use to complete a transaction with an amount of $3,400 in US dollars. The wallet issuer 260 notifies the customer which payment accounts are available for use in pending transactions and obtains the customer's selection of one or more payment accounts to use to complete the transaction. to interact with mobile payment applications.

Once the customer selects the desired account and confirms or accepts the transaction on mobile device 102 , the transaction proceeds to either mobile device 102 , wallet issuer 260 , or a combination of mobile device 102 and wallet issuer 260 . Either party obtains transaction authorization from one or more payment processing networks 280 for the transaction and may proceed to interaction "5" providing transaction authorization to the appropriate token issuing authority 250b. Interactions at such "5" can include several messages. For example, when a customer selects a preferred payment account to use to complete a transaction, a message is sent to the wallet issuer 260 identifying the preferred payment account (according to some embodiments, the message may be the actual does not contain payment account credentials, but rather contains a proxy or identifier that wallet issuer 260 can use to retrieve or identify the actual payment account credentials). The wallet issuer 260 constructs a payment authorization request message with information including the actual payment account credentials (PAN, account number, confirmation or verification data, expiration date, etc.), transaction amount, and merchant identifier. A 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 authorization code and authorization response messages that are sent along with the token to the appropriate token issuing authority 250b.

Token issuing authority 250b, upon receiving the authorization code and authorization response, uses the received token to identify the transaction record in process and interacts with merchant 108 to complete the transaction ("6" in ). For example, in a payment authorized situation, the token issuing authority 250b can send information confirming that the transaction was successfully completed, and the merchant 108 can have the transaction receipt printed at the interaction location. Wallet issuer 260 can also have transaction receipts or other information sent to mobile device 106 .

In some situations, it may not be possible for wallet issuer 260 to obtain payment authorization from payment processing network 280 based on the information available to wallet issuer 260 . For example, in some embodiments, the token issuing authority 250 may not provide additional metadata associated with the transaction (such as the merchant identifier and/or the amount of the transaction). In such cases, embodiments can be provided in which additional communication between the wallet issuer 260 and the token issuing authority 250 is required. For example, in some embodiments, when wallet issuer 260 obtains a token from mobile device 102, wallet issuer 260 establishes communication with token issuing authority 250 to provide missing metadata (e.g., , merchant identifier, and amount of the transaction). Wallet issuer 260 may proceed as described above and obtain payment authorization from payment processing network 280 .

In yet another embodiment where wallet issuer 260 is unable to obtain payment authorization from payment processing network 280 based on information available to wallet issuer 260, token issuing authority 250 obtains payment authorization. can do For example, in some embodiments, when the wallet issuer 260 identifies appropriate payment account credentials to use in a transaction, the wallet issuer 260 provides 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 construct a payment authorization message with information from the pending transaction record along with the payment account credentials received from the wallet issuer 260 . In either circumstance, the ability to complete the transaction will provide the mobile device 102 and the wallet issuer 260 with information used to identify the token issuing authority 250 (URL, URI or other data provided with the token). ), along with 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 other device or transaction participant). ) can be provided. In such embodiments, different entities, systems or devices may perform different transaction management functions. Refer to FIG. 6 where one illustrative system is illustrated. In conjunction with FIG. 5, interacting with multiple transactions involving multiple mobile devices 202 and multiple merchants 208 (or other interaction locations such as ATMs, other mobile devices, etc.), as in the embodiments 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 makes a transaction with merchant 108 . In the illustrated system 600, the mobile device 102 operates a payment application provided by the wallet issuer 260 (installed and configured via a process such as that shown in FIG. 4). In the illustrated system, mobile device 102 obtains a token from token issuing authority 250b (in the transaction labeled as item "1"). In some embodiments, a user and device authentication process occurs with or prior to interaction "1" (eg, 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 would allow token issuing authority 250b to send details of the transaction to mobile device 102 in a message labeled as item "4", described below). Upon receiving a request for a token, the token issuing authority 250b can generate a pending transaction record 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 identifier. It can contain information including other data associated with the transaction in it. In connection with some embodiments, tokens generated or obtained by token issuing authority 250b include information used to identify token issuing authority 250b. As noted above, such information may be formatted URL strings, URI based identifiers, tokenized string identifiers, etc. The token (including the token value and information identifying the token issuing authority and, in some embodiments, some additional metadata) is presented or otherwise communicated to merchant 108 by: It is sent back to the mobile device 102 .

The mobile device 102 can display or present the token as a QR code (or via a wireless signal such as Bluetooth, NFC, etc.) and the merchant 108 can display (e.g., a scanner or other reader ) can be prompted to capture a token (denoted as a '2' interaction). Once captured, the merchant 108 can decrypt the token (shown as interaction "3") to obtain the information contained therein. In some embodiments, decrypting a token may involve a collaborative process between merchant 108 and other entities. The result of token decryption 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, 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 in process to the token issuing authority 250b along with a token value that can be obtained from interactions "2" and "3". The information may include merchant identifiers, terminal identifiers, transaction amounts, and other data related to transactions being processed.

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

Once the mobile device 102 (and, in some embodiments, the wallet issuer 260) has information related to the pending transaction (including, for example, information identifying the merchant 108, the amount of the transaction, 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 accounts can be used in the transaction. You can proceed to the execution of the processing to be performed. For example, wallet issuer 260, which stores customer preferences and rules, determines that only certain customer payment accounts are available for merchant use (or based on merchant type or location). can do The wallet issuer 260 can interact with the mobile payment application to notify the customer which payment accounts are available for use in pending transactions, and to complete the transaction. A customer's selection of one or more payment accounts to use can be obtained.

Once the customer selects the desired account and confirms or accepts the transaction with the mobile device 102, interaction "5" proceeds to either the mobile device 102, the wallet issuer 260, or the mobile device 102 and the wallet issuer. Any combination of parties 260 can obtain transaction authorization from one or more payment processing networks 280 for a transaction and communicate it to the appropriate token issuing authority 250b to provide the transaction authorization. Such interactions in "5" can involve several messages. For example, when a customer selects a preferred payment account to use to complete a transaction, a message is sent to the wallet issuer 260 identifying the preferred payment account (according to some embodiments, the message is does not contain the actual payment account credentials, but rather contains 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 constructs a payment authorization request message with information including the actual payment account credentials (PAN, account number, confirmation or verification data, expiration date, etc.), transaction amount, and merchant identifier. A 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 authorization response message, which are sent along with the token to the appropriate token issuing authority 250b.

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

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

In yet another embodiment for situations where wallet issuer 260 is unable to obtain payment authorization from payment processing network 280 based on information available to wallet issuer 260, token issuing authority 250 can obtain payment authorization. For example, in some embodiments, once wallet issuer 260 identifies appropriate payment account credentials to use in a transaction, wallet issuer 260 passes those payment account credentials (along with the token) to token issuing authority 250, which Second, payment authorization messages can be constructed with information from the pending transaction record along with the payment account credentials received from the wallet issuer 260 . In either situation, the ability to complete a transaction indicates to mobile device 102 and wallet issuer 260 information (URL, URI, or other information provided with the token) that can be used to identify token issuing authority 250. data), along with information used to identify the transaction (token).

Embodiments cause processing to occur in a system with multiple transaction management systems, and in a system with multiple entities that perform different aspects of transaction management (such as wallet issuers and token issuance) and portable A device communicates with which transaction management system (or other device or entity) as a path or communication channel for each particular transaction to use to interact with the associated transaction management system. can be easily and efficiently identified.

Embodiments thus allow a wide variety of different transaction management systems and other entities and devices to be used in the payment system of the present invention, allowing mobile devices participating in the payment system to or other device or entity) to correctly identify and determine whether to communicate with the transaction location to complete the transaction with respect to the present invention based on the information captured in the checkout token obtained at the location of the transaction. make it possible to

The above description of the processes herein should not be taken to imply a fixed order for performing the process steps. Rather, the processing steps can be performed in any order practical, including concurrent execution of at least some steps. Although the present invention has been described in connection with specific exemplary embodiments, various alterations, substitutions, and alterations apparent to those skilled in the art depart from the spirit and scope of the invention as defined in the appended claims. It should be understood that the disclosed embodiments may be made without

Claims (20)

determining, by a customer device, a transaction between a customer associated with the customer device and a merchant associated with a merchant device;
sending, in response to determining the transaction, by the customer device to a transaction management system a request for a token for the transaction, the request including information characterizing the transaction; and,
receiving the token from the transaction management system, the token including identification information identifying an access location for accessing functionality of the transaction management system;
displaying a quick response (QR) code encoding at least the identifying information for scanning by the merchant device in response to receiving the token;
method including. 3. The identifying information comprises a Uniform Resource Locator (URL) string or a Uniform Resource Identifier (URI) string indicating an electronic address of a server of the transaction management system, the server providing the function. 1. The method according to 1. 2. The method of claim 1, wherein the identifying information comprises a formatted uniform resource locator (URL) linked to the transaction management system. 2. The method of claim 1, wherein the identifying information includes one or more of the merchant's identifier, a transaction amount of the transaction, or a currency type of the transaction. 12. The token indicates transaction details of the transaction between the merchant and the customer, including an account in the transaction management system of at least one of the merchant or the customer, based on the characteristics of the transaction. 1. The method according to 1. receiving confirmation from the transaction management system that the transaction is complete;
sending a transaction receipt to the merchant device indicating completion of the transaction in response to receiving the confirmation;
2. The method of claim 1, further comprising: receiving an indication from the transaction management system that the transaction has been processed using the token;
2. The method of claim 1, further comprising: 2. The method of claim 1, wherein determining the transaction comprises initiating the transaction by detecting that the customer device is within a specified distance of the merchant device. a non-transitory memory for storing instructions;
A customer device comprising a processor,
The processor
determining initiation of a transaction between a customer associated with the customer device and a merchant associated with the merchant device;
sending a token request for a token for the transaction to a transaction management system in response to determining the initiation of the transaction, the token request including information about the transaction;
receiving the token from the transaction management system, the token indicating a uniform resource locator (URL) string or a uniform resource identifier (URI) string for accessing functionality of the transaction management system; including information;
displaying a quick response (QR) code indicative of at least the identifying information for scanning by the merchant device in response to receiving the token;
a customer device configured to execute instructions for causing the customer device to perform 10. The customer device of claim 9, wherein the identifying information includes one or more of the merchant's identifier, the transaction amount of the transaction, or the currency type of the transaction. 10. The token indicates transaction details of the transaction between the merchant and the customer, including an account in the transaction management system of at least one of the merchant or the customer, based on characteristics of the transaction. Customer equipment as described in . Executing the instructions includes:
receiving confirmation from the transaction management system that the transaction is complete;
sending a transaction receipt to the merchant device indicating completion of the transaction in response to receiving the confirmation;
10. The customer device of claim 9, further causing the customer device to: Executing the instructions includes:
receiving an indication from the transaction management system that the transaction has been processed using the token;
10. The customer device of claim 9, further causing the customer device to: 10. The customer device of claim 9, wherein determining the transaction includes initiating the transaction by detecting that the customer device is within a specified distance of the merchant device. determining initiation of a transaction between a customer associated with the customer device and a merchant associated with the merchant device;
sending a token request for a token for the transaction to a transaction management system in response to determining the initiation of the transaction, the token request including information about the transaction;
receiving the token from the transaction management system, the token indicating a uniform resource locator (URL) string or a uniform resource identifier (URI) string for accessing functionality of the transaction management system; including information;
displaying a quick response (QR) code, including at least the identifying information, for scanning by the merchant device in response to receiving the token;
A non-transitory machine-readable medium containing machine-readable instructions for causing a machine to perform operations including 16. The non-transitory machine-readable medium of claim 15, wherein the identification information comprises one or more of the merchant's identifier, the transaction amount of the transaction, or the currency type of the transaction. 16. The token indicates transaction details of the transaction between the merchant and the customer, including an account in the transaction management system of at least one of the merchant or the customer, based on characteristics of the transaction. A non-transitory machine-readable medium as described in . The operation is
receiving confirmation from the transaction management system that the transaction is complete;
sending a transaction receipt to the merchant device indicating completion of the transaction in response to receiving the confirmation;
16. The non-transitory machine-readable medium of claim 15, further comprising: The operation is
receiving an indication from the transaction management system that the transaction has been processed using the token;
16. The non-transitory machine-readable medium of claim 15, further comprising: 16. The non-transitory machine-readable medium of claim 15, wherein determining the transaction includes initiating the transaction by detecting that the customer device is within a specified distance of the merchant device.

Images