JP2021121975A - Transaction token issuance authority - Google Patents

Abstract

To provide a method, a system, and a machine-readable medium capable of certifying payment of a consumer who wants to pay for a product.SOLUTION: The method includes: receiving a payment permission message, which includes information related to a transaction involving a vendor server and a customer's device, by a token issuing authority from the vendor server; determining, based on analysis of the payment permission message, the necessity for providing tokens to the vendor server for the transaction that the vendor server and the customer's device are involved; providing, in response to the determination, the token containing encoded electronic information that can be used for identifying the token issuing authority by the customer's device; transmitting the token to the vendor server; receiving the token and a permission response message from a wallet issuing server after the transmission; and processing transactions based on reception of the token and the permission response message.SELECTED DRAWING: Figure 5

Description

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

Recently, payment systems and payment methods have been proposed in which a user executes a transaction using a portable device. In some methods, as proposed by the applicant of the present invention, a user can perform a transaction using a portable device equipped with a mobile payment application. In the proposed transaction, a "token" (such as a checkout token or ATM token) can be captured or communicated to a mobile device. Tokens are used by transaction management systems to facilitate the completion of transactions between the user of the mobile device and the transaction location. For example, a transaction management system uses the information associated with a token to identify the vendor (or consumer) associated with the transaction location and to identify the transaction information in progress associated with the transaction location. Can be done.

As a related technology, the store terminal device sends the payment amount and the store terminal device ID that have been input to the payment system to the payment intermediary server, and the payment intermediary server generates a transaction number for the payment amount and the relevant technology. It is transmitted to the store terminal device, the store terminal device displays the QR code (registered trademark) indicating the received transaction number on the display, the QR code includes the URL of the payment intermediary server, and the QR code is the payment intermediary. The server may generate it, the user terminal device reads the QR code, accesses the payment intermediary server with the URL, transmits the transaction number included in the QR code, and the payment intermediary server receives the transaction information from the transaction number. There is a payment system that identifies and sends to the user terminal device (see, for example, Patent Document 1).

Japanese Unexamined Patent Publication No. 2011-210171

In some embodiments of the system introduced by the applicant of the present invention, tokens are used to connect two entities wishing to make a transaction. The system described is, for example, in the case of a purchase transaction, a payment proof of a consumer who wants to pay the vendor of the goods associated with the transaction being processed, at the store, in the checkout column, the purchase transaction being processed. It can be used to replace the use of magnetic stripe cards and readers used to combine together.

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

It would be desirable for multiple transaction management systems to provide systems and methods that can be involved in transactions. In addition, it would be desirable to allow multiple entities or systems to perform different transaction management functions while allowing users of mobile devices to execute transactions efficiently and reliably.

Furthermore, it would be desirable for the devices involved in the transaction to be able to easily identify the appropriate transaction management system for each transaction, along with the correct route or communication channel used to communicate with the appropriate transaction management system. For example, in a transaction in which the portable device captures a token associated with the point of transaction, the portable 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 processes to identify the appropriate transaction management system to use in the transaction based on the information received from the token. Can be done.

A method according to one aspect of the present invention is to receive a payment authorization message from a vendor server by a token issuing authority, the payment authorization message relating to a transaction involving the vendor server and the customer's device. It is necessary for the token issuing authority to provide the token to the vendor server for the transaction involving the vendor server and the customer's device based on the analysis of the payment authorization message. It is determined that there is, and the token issuing authority provides the token in response to the determination, and when the token is decrypted, the token is decrypted by the customer's device. After including the encoded electronic information that can be used to identify the issuing authority, and the token issuing authority transmitting the token to the vendor server, and after the transmission. Processing the transaction based on receiving the token and the authorization response message from the wallet issuing server by the token issuing authority and receiving the token and the authorization response message by the token issuing authority. And is a method that includes.

A system according to one aspect of the present invention is a system including a non-temporary memory and one or more hardware processors combined with the non-temporary memory, the one or more hardware. The processor receives a request from the vendor server to process a transaction related to the vendor server and the customer's mobile device by the token issuing server, and responds to the request received by the token issuing server. The decryptable information provides the electronic address of the token issuing server in response to being decrypted, and the token issuance. The server transmits the token to the vendor server, receives the token and authorization code associated with the transaction from the wallet issuing server after the transmission, and at least to the received token. To read instructions from the non-temporary memory so that the system performs an operation that includes identifying the transaction based on and processing the transaction in response to the identification. It is configured.

A non-transitory machine-readable medium according to an aspect of the present invention can generate a token in which the electronic address of a token issuing entity is embedded in response to a request received from a trader to execute a transaction. Generating a transaction record containing the trader's identifier or the amount of the transaction, associating the transaction record with the token, sending the token to the trader in the form of a machine-readable code, and sending. After that, from the wallet issuing server, the token and the message authorizing the transaction are received, and the transaction record associated with the token is specified based on the reception. It is a non-temporary machine-readable medium in which a machine-readable instruction for processing the transaction in response to the transaction and causing the machine to execute an operation including the transaction is stored.

FIG. 5 is a block diagram illustrating a portion of a system configured for some embodiments. FIG. 5 is a block diagram illustrating a portion of the system of FIG. 1 configured for some embodiments. FIG. 5 is a block diagram illustrating a portion of a system configured for some embodiments. It is a block diagram which illustrates the process which concerns on some embodiments. FIG. 5 is a block diagram illustrating a portion of a system configured for some embodiments. FIG. 5 is a block diagram illustrating a portion of a system configured for some embodiments.

Embodiments of the present invention relate to systems, methods, processes, computer program code and means of performing transactions. More specifically, in some embodiments, a system, method, or process that operates a portable device to perform a transaction with a vendor, service provider, and other device (such as an automated teller machine or "ATM"). , Computer program code and means. For some embodiments, the systems, methods, processes, computer program code and means that operate the portable device to perform a transaction may allow the portable device to communicate with the appropriate entity to perform the transaction. To be able, it involves determining the transaction token issuance authority associated with the vendor or the point of transaction. In general, embodiments can be used to execute a transaction by scanning, capturing, or entering code associated with the transaction, as referred to above, both under review and in common. It can be developed with the system as described by the present inventor in an application with a single applicant. A feature of some embodiments is that the portable device, along with a payment system, is used to execute a transaction at a vendor's location or where it interacts (or, in some embodiments, an ATM, kiosk, etc.). Will be explained.

In connection with some embodiments, multiple transaction management systems (or remote transaction management devices) can be associated with or used in the payment system of the present invention. For example, the first vendor uses the services of the first transaction management system to process transactions, while the second vendor uses the services of the second transaction management system to process transactions. Can be used. Consumers holding mobile payment devices with mobile payment applications according to the invention do not necessarily need to know which transaction management system each vendor uses. However, in connection with some embodiments, the mobile payment application on the mobile device must know which transaction management system to communicate with during the transaction associated with the present invention. The embodiments described herein provide a technique that allows a mobile payment application on a mobile device to determine which transaction management system to communicate with in order to perform a payment transaction. Further, embodiments can also be used in situations where the vendor system needs to determine the appropriate transaction management system to communicate with based on the information received from the portable device. The result is a system that allows multiple transaction management systems to participate in the payment system. Further, as further described herein, a plurality of layers or sets of systems or subjects, each executing aspects of a transaction management system that references another system or subject, can be provided.

In connection with some embodiments, the functions of a 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 authority can execute functions such as trader authentication and basic transaction management function. In such an embodiment, when the consumer operates the portable device to perform a transaction with the vendor, the portable device (and / or the portable device that works with the wallet issuer) is (portable device). It must be determined which token-issuing authority issued the token on behalf of the trader so that the transaction can be executed between the consumer and the trader. The embodiment allows such a transaction to be executed. Other features and advantages will be apparent from the disclosure below, where the first description of a transaction is provided with reference to Figure 1 (multiple transaction management systems can participate in a transaction). Further transaction details will be provided in Figure 2 (with multiple transaction management systems involved). FIG. 3 illustrates the details of a transaction in which some of the functions of the transaction management system are performed by one or more token issuers and one or more wallet issuers. FIG. 4 illustrates a wallet registration process (which can be performed between a user who wants to configure a mobile payment application on a mobile device and a transaction management system or wallet issuer). In FIG. 5, further details of transaction processing are described for situations in which one or more wallet issuers and one or more token issuer participate in a transaction.

Some terms are used here for convenience and convenience of commentary. For example, the phrase "point of transaction" is commonly used by a user operating a mobile device to refer to a subject, device, or other object with which he or she wishes to make a transaction. For example, a "point of transaction" is a vendor's POS terminal, vendor's website, ATM, kiosk, other individual, an item with an identifier such as a printed QR code, Bluetooth®, etc. When operating with a wireless device or beacon, NFC chip, audio device, or other device, it can be an item or object, including other devices that can be used to initiate a transaction. For convenience, as used herein, without the aforementioned limitation, the "point of transaction" can also be referred to simply as a "trader."

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 a mobile device during or in connection with a transaction involving the vendor and the mobile device, depending on the location of the transaction of the vendor. As another example, tokens can be provided to a portable device by an ATM during or in connection with a transaction involving the ATM and the portable device. As yet another example, the token can be provided by the customer to the place of interaction 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 described further herein, tokens can be issued, generated, or provided by a transaction management system or a "token issuer".

The phrase "capture" may be used to refer to the action of scanning, reading, or otherwise retrieving a "token" (an identifier used to facilitate a transaction for some embodiments). You can do it. The phrase "captured" (or "captured") has no limited intent and allows the portable device to perform keystrokes, image capture, RFID, BLE / Bluetooth, NFC reading, and other scans. It is intended to include embodiments that are manipulated to receive a token (or data associated with the token) by reading or using other wired or wireless techniques described herein. For some embodiments, the phrase "capture" further includes any decoding or image processing of the token required to retrieve or obtain information from the token.

As another example, the phrase "radio" is connected, for example by using communication technology based on radio frequency or other electromagnetic radiation, including RFID, wifi, Bluetooth / BLE, Zigbee or other technology. Used to refer to no telecommunications technology. By reading this disclosure, one of ordinary skill in the art will appreciate that the use of these terms is not intended to be limiting and is for the purpose of commentary.

As another example, the phrase "transaction management system" refers to a system operated by a subject to facilitate a transaction, including portable devices and vendors, ATMs or other devices. In general, the transaction management system can be a transaction management system as described in US Pat. Nos. 8,632,000 and 8,380,177. In general, a transaction management system transfers transaction information in process received from one device (transaction location, portable device, item, etc.) associated with a first party to another device (portable) associated with a second party. It can be a system that matches the information received from the device, transaction location, etc.). In connection with some embodiments, transaction management systems perform match processing using tokens (such as checkout tokens or ATM tokens), at least in part. Once the transaction information being processed matches the user information, further processing is performed to allow the selection or identification of the appropriate or desirable payment account to be used to complete the transaction. Can be done. In some embodiments, the transaction management system can perform other functions. For example, a transaction management system can perform user and portable device authentication processing. A transaction management system can also be used to issue tokens that are used in executing 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 act on its behalf. For example, the user's device decides to publicize the token using the Bluetooth beacon feature, and a particular retailer (the token determines the user's position either on its own or in combination with the positioning feature of the user's device. When located near an ATM or other interaction location, the transaction management system is at one or more interaction locations at that location and the user associated with the particular device. Can be checked in. Checking in means that the interaction location system has received certain profile information about the user, such as name, nickname, photo, loyalty program number, and preference for frequently purchased items and services. In addition, the check-in process encourages the gas station pump (where the interaction is to occur) to start injecting petrol, or to have the bartender automatically prepare a particular drink. Alternatively, the place of interaction, or the location of interaction, such as automatically enforcing the payment device to pre-authorize the payment of a predetermined amount in order to have the kitchen staff prepare the user's favorite meal. The clerk at the interaction location will execute the transaction on behalf of the user.

In some embodiments, the functions performed by the transaction management system can be performed by different entities. For example, as used herein, a "wallet issuer" can perform functions such as authentication of users and mobile devices, as well as certain transaction processing functions. As used herein, a "token issuer" or "token issuer" may perform some transaction processing functions, as well as functions such as communication and authentication with vendors, ATMs or other places of interaction. You can. As used herein, the term "directory service" refers to services performed by, or on behalf of, any transaction management system, token issuer, and wallet issuer (or other entity). It can be used for reference. A "directory service" is performed (eg, based on a token) to determine which entity and device (such as a portable device or vendor) should communicate with in order to perform the transaction processing described herein. It is possible to provide a service that enables research or mapping of functions to be performed. More details on such features will be provided below.

The features of the present invention are described assuming the use of the payment systems described above in our ongoing application, and the details of those systems are not completely repeated here. However, embodiments of the present invention are not limited to use in connection with the payment system described in the applications pending with us.

Features of some embodiments of the present invention will be described with reference to FIG. 1, which is a block diagram of the system 100 for some embodiments. More specifically, FIG. 1 is a block diagram of a system in which a plurality of transaction management systems 130an are used. Each transaction management system 130 can perform the functions described herein, or other functions in which a mobile payment application transaction can be processed in situations where different transaction systems participate. In such a system, transactions at the first vendor can require interaction with the first transaction management system, and transactions at the second vendor can interact with the second transaction management system. There can be an environment that can request. The embodiment illustrated in FIG. 1 makes it possible to use such a plurality of transaction management systems. Before explaining how multiple transaction management systems, wallet issuers and / or token issuers are used, an overview of how transactions can be processed will be provided. .. Further details of different types of transactions and transaction processing can be obtained with reference to patents and applications granted to the same applicant, which are incorporated herein by reference.

For convenience, various transactions will be described with reference to the payment system 100 of FIG. 1, and for convenience, the situation where a single transaction management system 130 will be used first will be described. As shown, a payment account holder, purchaser, or other user or operator (here, a "customer") can hold or use a mobile device 102 (such as a mobile phone). The portable device 102 has a display screen 136 and a data input device 138 (keypad, touch screen, etc.). For embodiments of the present invention, the customer may use the portable device 102 to perform a transaction (payment, royalty, return or other transaction) with the vendor 108. The trader 108 is a physical storefront, an electronic trader, or a mail order and telephone (“MOTO”) trader (or another person, or entity, or a customer and / or a customer who can initiate a transaction. It can be any other object that can work with the device. Further, the trader 108 does not have to be a "merchant", but may be another individual (in the case of an individual-to-person transaction), a kiosk, or another unmanned device (such as an automated teller machine "ATM"). You can also do it.

In a typical exemplary transaction, a customer first sells a product or service at a point of sale (eg, a physical checkout counter, an electronic shopping cart, etc., generally referred to here as a "sales place" or , Called "POS"), you can purchase goods or services from the vendor 108. The vendor 108 initiates a checkout transaction as usual by summing up the items to be purchased (eg, by bar code scanner, keystroke of product code, etc.). The vendor (which operates via a clerk, display screen, POS terminal facing the customer, etc.) encourages the customer to select a payment option. In previous systems, vendors may have prompted customers to choose "credit," "debit," or other payment options. In connection with the present invention, a trader (operating via a clerk, a display screen, a POS terminal facing the customer, etc.) can prompt the customer along with the mobile payment options. If the customer chooses the mobile payment option, the features of the invention are utilized to process the transaction.

In some embodiments, the choice, rather than requiring the customer to select a mobile payment option, by action (such as by pressing a button on a POS terminal or by instructing a clerk to make a choice). 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 an embodiment, the action of capturing the tokens used in the present invention will allow the transaction to proceed in connection with the present invention.

When the mobile payment option is selected and the purchase total is generated, the vendor 108 sends a vendor payment authorization request message to the transaction management system 130 (via route 116). A vendor payment authorization request message can contain one or more data or information about a transaction. For example, this message may include a trader identifier, a payment amount, and, as further described herein, one or more of the tokens used to identify the trader and transaction for further processing.

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 vendor 108 (eg, vendor 108 displays at the point of sale. Alternatively, you can have some checkout tokens that you can use to present). In such an embodiment, the vendor 108 will select a token to use in a given transaction. In some embodiments, such tokens can be generated or presented using standard formats. In the illustrated example, vendor 108 may be issued or provided in a range of tokens, or a predefined sequence or number sequence. As a particular example, a vendor can be instructed to use a range of numbers (eg, "00000" to "99999") with a sequence or usage pattern (eg, a particular checkout token is simply It can only be used for one valid transaction). In such an embodiment, the POS system will give the selected token to the transaction management system 130. In other embodiments, however, the token is issued or selected by transaction management system 130 (as further described below) and provided to vendor 108 in response to a vendor authorization request message. .. Those skilled in the art will appreciate that other techniques of issuing, using, and selecting tokens can be used. In some embodiments, the token is issued by a "token issuer", as further described below.

In connection with some embodiments, tokens are dynamically generated for each transaction. In some embodiments, the token is an individual checkout location (eg, a particular POS terminal, or location, a particular ATM machine or other device, or a plumber or a plumber who does not have a particular checkout location. It is a static identifier associated with a small business person such as an electrician or an individual). The trader 108 displays or presents the token to the customer. For example, the token can be displayed on a display device associated with the vendor or pre-printed on a placard or other display near the point of sale.

From the customer's point of view, the payment process of the present invention can begin with the customer performing an authentication process to verify its identity and authority in order to execute a transaction using the present invention. The authentication process can be performed after the customer selects the mobile payment option at the point of sale or, in some circumstances, before it. In connection with some embodiments, the authentication process contributes to authenticating the customer to the transaction management system 130. The authentication process involves the customer launching a mobile payment application or web browser on the mobile device 102 and providing one or more items of proof or information to the transaction management system 130 via the communication path 114. Can be done. For example, the authentication process can include entering a user identifier, password or other proof into a login screen or other user interface displayed on the display device 136 of the portable device 102. The transaction management system 130 compares the received information with the stored information in order to authenticate the customer. Further, as described herein, different transaction management systems 130an can be included, and different portable devices can interact with different transaction management systems 130an to perform this authentication process. .. Moreover, in some embodiments, the function of performing authentication can be performed by the issuing entity of the mobile payment application used by the consumer. Such entities can be referred to herein as "wallet issuers".

The authentication process, in some embodiments, also stores one or more attributes of the portable device 102 and attributes collected from the portable device 102 during the registration process (as in the process of FIG. 3). Includes comparison with sets. For example, the attribute can include an identifier associated with the portable device 102 that uniquely identifies the device. In this way, the customer is authenticated in two directions by something he knows (login proof) and something he has (portable device). Upon successful authentication of the customer, the system has access to the transaction management system 130 as part of the registration process various attributes about the customer, including a list of payment accounts previously identified by the customer. In some embodiments, the authentication process is performed between the portable device 102 and the wallet issuer, as further described herein.

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

In connection with some embodiments, either "static" tokens or "dynamic" tokens are used. In embodiments where "static" tokens are used (eg, such as those assigned to be used by a particular transaction location and do not contain any variable information for each transaction), transaction management system 130. Matches the information in the customer transaction search request (received from the mobile device 102) with the information in the vendor payment authorization request (received from the vendor 108), and matches the token information received in each message. Do it by letting it do. When matched, the transaction management system 130 sends a transaction detail message (via route 114) to the customer's mobile device 102. Information from the transaction details message includes, but is not limited to, transaction details, including, but not limited to, the payment amount, name, and vendor location (information included or derived from the vendor payment authorization request). Alternatively, provide one or more marketing messages to the customer. In addition, the transaction management system 130 also sends to the phone a list of payment accounts that the customer has registered with the system, including credits, debits, checks, prepaid and other types of accounts. The list of accounts may include all of the accounts that the customer has registered with the system, or parts of the accounts based on rules established by the mobile payment network operator, vendor, issuer of each payment account, customer or other entity. It can contain a set (for example, the list of accounts sent to a mobile device only includes accounts that can be used for the current transaction). In connection with some embodiments, the list of accounts may include only a single account or multiple accounts. In addition, the list of accounts does not include the actual payment proof, but rather the actual payment proof is to the transaction management system 130 (or, in some embodiments, the wallet issuer, as described below). Storage (or accessible to). As such, the portable device 102 does not store important payment account information. For example, the list of accounts may simply include an identifier (such as a proxy) that allows the transaction management system 130 or wallet issuer to identify the actual payment proof associated with each customer's account. You can. Here, the customer can see on the display 136 of the portable device 102 the name of the trader who intends to pay, the payment amount, and a list of payment accounts that can be used to pay the trader 108.

In some embodiments, the vendor token can be derived from a unique identifier in the vendor payment authorization request. For example, if the vendor cannot easily modify the system to send static tokens to the transaction management system 130, such derivation may be required by the vendor adopting a new payment method. No, reduce the need for equipment upgrades and software changes, or even erase. The token can be derived using a mapping table that maps the vendor's identifier, terminal identifier, or other information (sent by the vendor's system to the transaction management system 130) to the token. Based on the identifier received, the mapping process occurs to identify the appropriate token to be used in the payment transaction. The selected token is made available in transaction management system 130 (or, as described below, to match transactions from the customer message queue) in transaction management system 130 (or, as described below, the wallet issuer). Alternatively, it is associated with a transaction in the trader transaction queue (in the token issuer), as described further below. Those skilled in the art will appreciate that other matching and mapping techniques can also be used. In any case, the token is from a combination of identifiers (letter, number, and / or symbol) used to associate a vendor payment authorization request with a payment authorization request received from a customer operating a portable device related to the present invention. Will be).

(For example, the token is generated and generated by either the vendor 108, the transaction management system 130, or the token issuer before it is displayed on the vendor-related display device during the checkout transaction, and In embodiments where the token uses a "dynamic" token (which contains additional information about the transaction), the checkout process can proceed without the need to send a customer transaction search request message to the transaction management system 130. You can. For example, in some embodiments, some or all of the transaction details are encoded in a dynamic token that provides the transaction details to the mobile device 102 when captured and processed by the mobile device 102. Rukoto can. Further details of both "static" and "dynamic" token embodiments are contained in applications assigned to the same applicant, further described below or incorporated herein by reference. .. However, in either case, the token combines the message from the mobile device 102 with the message from the vendor 108 into the transaction management system 130 (or, as described herein, a wallet issuer and a token issuer). ) Is used for matching processing.

To complete the payment transaction, the customer interacts with the mobile device 102 to select the desired payment account to use in the current transaction, and the customer payment authorization request message is a transaction (via route 114). It should 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 the last opportunity to confirm or cancel the payment transaction. The steps are optional. The customer confirmation or cancellation is transmitted from the mobile device 102 to the transaction management system 130 via the route 114 as a customer payment authorization message.

Upon receiving the payment authorization message from the customer's mobile device, the transaction management system 130 (or, in some embodiments, the wallet issuer or other entity) of the transaction, as further described below. Generate an authorization permission request message to be sent over one or more payment processing networks (not shown in FIG. 1) for authorization, clearing, and settlement of funds. This request message is a pointer or reference to the transaction amount, or at least the relevant vendor payment authorization request (received from vendor 108), and is selected by the customer and pre-stored in the transaction management system 130 (and mobile). Includes information from a vendor payment authorization request, such as a payment account identifier that identifies a payment account (identified by a proxy or other identifier received from the device). Authorization The authorization process is a standard authentication process on one or more authentication networks (eg, VISANET operated by Visa, referred to herein simply as "payment process" in FIGS. 2, 3, 5, and 6". It is executed using the (registered trademark) network, automatic clearing house system such as National Automatic Payment Association (NACHA), etc.). Once the available funds are confirmed, the transaction management system sends the vendor a vendor payment authorization response message (via route 116) 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, vendor 108 is not provided with any actual payment proof of the customer during the checkout process, as further described below. Moreover, the portable device 102 never stores, transmits or receives the actual payment proof. Rather, the portable device 102 stores or has access to a proxy associated with the actual payment proof, which is used to identify the desired payment account for use in a particular transaction. .. The proxy is sent in a customer payment authorization request message to the transaction management system 130 (or, in some embodiments, the wallet issuer) and to the transaction management system 130 (or, in some embodiments, the wallet issuer). Uses a proxy to search for or identify the actual payment proof associated with the selected account. The actual payment proof is sent from the transaction management system 130 (or, in some embodiments, the wallet issuer) to the account issuer or authorization agent. By ensuring that the actual payment proof is not revealed or stored by the vendor 108 or the mobile device 102, the embodiment is to provide stronger account security and reduce the likelihood of fraud or misuse. I will provide a.

In connection with some embodiments, the portable device 102 can access, display, or access the Internet, for example, an iPhone®, an Android® phone, or web content. It can be a smartphone such as an arbitrary telephone or a portable device that can browse the Internet. In some embodiments, the portable device 102 uses a mobile or wireless network to communicate with the transaction management system 130. In some embodiments, the transaction management system 130 is a secure server (or network of servers). In some embodiments, the transaction management system 130 (or, in some embodiments, the wallet issuer and / or token issuer) is the VISANET® network operated by Visa. One or more payment processing networks, such as the BANKNET® network operated by MasterCard International (not shown in Figure 1, but shown in Figures 2, 3, 5 and 6 as "Payment Processing". Communicate with). The transaction management system 130 (or, in some embodiments, the wallet issuer and / or the token issuer) allows the customer operating the portable device 102 to use a wide range of different forms of payment devices and accounts. It can also communicate with other financial transaction networks (such as ACH and EFT networks, private label networks, and other payment systems such as PayPal®) so that it can execute transactions. The transaction management system 130 (or, in some embodiments, the wallet issuer and / or the token issuer) also includes Google®, Apple®, Yahoo®, Microsoft. It can communicate with one or more advertisements or provision management networks, such as those provided by (Registered Trademarks) and the like. As further described below, data, including advertisements and offers, can be received from their networks and provided to customers via the portable device 102.

In some embodiments, other devices can acquire tokens and / or initiate transactions. For example, in some embodiments, a customer operating a portable device 102 obtains a token for use in a transaction and another participant in the transaction (a trader, another customer operating another portable device). Etc.), the token can be provided. The flow of such a transaction can generally proceed as follows.

For some embodiments, a transaction (such as payment, loyalty or other transaction) obtains a token from transaction management system 130 and presents the token to the location of interaction (such as vendor 108, other mobile device). To do so, it can be performed by the consumer operating the portable device 102. For example, when the token is acquired by the mobile device 102, the mobile payment application is for the token (or an encoded version of the token, such as a QR code) to be read or captured at the location of the interaction. , It can be displayed on the display screen of the portable device 102 and transmitted to the place of interaction via a wireless communication link or the like. For example, the process at vendor 108 can proceed as follows (although other process flows can be used with favorable results).

Initially, the clerk associated with vendor 108 scans the items at the point-of-sale terminal and generates an initial basket or set of items purchased by the customer operating the portable device 102 (scanning the items is a token generation). It can occur after being captured and captured, but in this illustrated embodiment, for convenience, scanning the item will be described as occurring first). One or more in the transaction management system 130, operating a portable device 102 configured with a payment application related to the present invention (eg, through a process as described below with reference to FIG. 4). The consumer (who has registered the payment account) decides to use the mobile device 102 to perform a payment transaction with the vendor 108 and with the mobile device 102 to request a token for use in the transaction. Interact. This request causes the transaction management system 130 to send a message. The message also contains information that authenticates the consumer, along with the consumer's portable device (as described above), and the transaction management system 130 generates tokens for use in the transaction and is in the transaction queue. Uses data from messages to generate transaction records in process.

The transaction management system 130 causes the mobile device 102 to send a message including data related to the token for use in the transaction. The portable device 102 (under the control of the payment application of the present invention) causes the token to be displayed on the display screen of the portable device 102. Tokens can be displayed or presented in the form of QR codes, barcodes, bluetooth or RFID signals, and consumers present the tokens to the vendor's clerk or vendor's point-of-sale system for capture. You are prompted to do. When the vendor system 108 captures a token from the portable device 102, it associates the token with the details of the transaction being processed (which can include the full amount of the transaction and other details of the scanned item) and provides information about the transaction. (Among other information, the transaction amount can be included), and a processing transaction request message including token information is sent to the transaction management system 130. For example, the message includes information that identifies the token (received from the portable device 102) and information that identifies the cashier, POS terminal, vendor 108, location, transaction amount, item details of the purchased item, and so on. It can contain data elements. The transaction management system 130 uses the information from the processing transaction request message to identify the transaction in process in the transaction queue and update the transaction queue.

A request message containing information about the transaction received from the vendor 108, including the transaction amount, is transmitted from the transaction management system 130 to the portable device 102. In addition, a transaction can be used by a customer in a particular transaction (eg, by applying one or more vendor-specific rules, one or more system-specific rules, and one or more customer account rules). It can include information identifying available payment accounts for one or more customers identified by management system 130. The customer interacting with the portable device 102 selects an available payment account from the information received from the transaction management system 130, and causes the transaction management system 130 to send the selected account information and the transaction confirmation message.

For some embodiments, some or all of these messages between the portable device 102 and the transaction management system 130 can be transmitted in one or more transaction sessions. That is, session control allows the same mobile device 102 to both request a token and receive information about available payment accounts and select available payment accounts in a single transaction session. Started to guarantee. Thus, the embodiment ensures that different customers or users cannot reuse or copy the payment information of different users. Further, in this method, the portable device 102 that initiated the token request is the only device that can be used to make a payment for the transaction identified in the message sent from the vendor 108 to the transaction management system 130. Guarantee that there is.

Upon receiving 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). To send to. The payment authorization request message includes the actual payment proof (identified based on the information received from the mobile device 102), the transaction amount, and the vendor information. Upon receiving the authorization response from the payment processing system, the transaction management system 130 causes the vendor 108 to send an acknowledgment message (the acknowledgment is also sent to the portable device 102). Transactions in progress are also removed from the transaction queue. In this way, the payment transaction is performed by allowing the mobile device 102 to acquire a token to be used in the transaction and provide the token to the vendor 108 for use in the transaction. Can be done. This transaction processing can also be used with royalties, discounts, and other types of transactions. In addition, processing can be used to execute transactions at other types of vendor locations (including MOTO, the Internet, etc.), ATM machines or kiosks, etc., and in individual-to-individual transactions.

Although the system shown in FIG. 1 (and elsewhere throughout this disclosure) shows only a single portable device 102 and one of ordinary skill in the art 108, one of ordinary skill in the art has many devices in use and the system. You will understand that there are many vendors who use it. Further, in connection with some embodiments, a plurality of devices of the transaction management system 130 (in some embodiments, a wallet issuer and a token issuer) are in operation.

As further described below, transactions performed using embodiments of the present invention have some desirable advantages over existing payment methods. For example, a customer can use a portable device to perform a payment transaction at a wide variety of vendor locations. In addition, the portable 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 desirable payment account for each transaction. Make it possible. By using the features of the present invention, the embodiment can utilize the existing sales place system and hardware, so that the trader does not need to additionally introduce or replace expensive hardware. Moreover, paying according to embodiments of the present invention is safer than existing payment methods. This is because each transaction has two unique attributes associated with the portable device that the customer uses to initiate the transaction, as well as user information (user identifier and / or password or PIN) known to the customer. This is because it is possible to request authentication using the item. Other benefits and benefits will become apparent to those skilled in the art by reading this disclosure.

For some embodiments, the system 100 includes a plurality of transaction management systems 130a-130n. Each (or some) vendor 108 is associated with or has a relationship with one or more transaction management systems 130a-130n, and the customer operating the portable device 102 is which transaction management system 130a-130n. You don't need to know if you are participating in any given transaction. Similarly, each portable device 102 can communicate with several different transaction management systems 130a-130n, where the vendor or transaction location is which transaction management system 130a-n is in any previous predetermined transaction. It is not always necessary to know if you are participating (during the transaction, until such information is confirmed, as described here).

As mentioned in the ongoing application, purchase or other transaction processing related to some embodiments involves generating, scanning, or capturing tokens associated with the location of the transaction. In some embodiments, the token can be dynamically generated for use in an individual transaction at a particular vendor or location. Scanning or capturing a token by the portable device 102 causes the transaction management system 130 to send information for use in completing the transaction. For some embodiments, token-related data can be used in connection with identifying or selecting the appropriate payment account for a transaction. As described herein, the data associated with the token is also which transaction management system 130a-to retrieve information about the transaction at the vendor (eg, information identifying the payment amount, retailer name, etc.). n and can be used to determine if the portable device should communicate.

For some embodiments, the portable device 102 (or, in the context where the portable device 102 provides tokens to the in-transaction trader system, the trader 108) is in which transaction management system 130a-n during a given transaction. Any, several different methods can be used to determine if a device should be contacted. For example, in some embodiments, when the mobile device 102 scans or captures the token at the point of sale, the token is used by the mobile payment application to contact the appropriate transaction management system 130an. It can contain identifiers or other information that can be used. The identifier, or other information, is, for example, a URI or URL that is directly encoded in the token and used by the mobile application on the mobile device 102 to determine the route to access the appropriate transaction management system 130a-n. Can be. As an illustrated example, the URL https://paydiant.com/tms/production can be included directly within the token, along with the token value itself. In such an embodiment, the URL or URI is coded using a URL coding method so that the mobile payment application can efficiently and accurately decode the URL or URI from the token along with the value of the token. Can be converted.

As another illustration example of the information that can be contained in a token, the formatted URL string can be encoded in the token for capture and processing by the mobile payment application (eg, the URL string is. It can be encoded in a QR code, etc.). The 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: the currency of the transaction, the amount of the transaction, and the identifier of the vendor.

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

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

In the illustrated example of Table 1, when the portable device 102 interacts with a vendor 108 using Paydiant's transaction management system 130, the token captured by the portable device 102 from the vendor 108 is combined with the value of the token. , The identifier "ABC123" can be included. When the mobile device 102 receives the token, the route used to communicate with the transaction management system is the route associated with the identifier ABC123 (for example, the appropriate route is https://paydiant.com/tms/production). Do a search to determine if it is. If the portable device interacts with vendor 108 using Visa's transaction management system 130, the token captured by vendor 108 by vendor 108 may include the identifier "XYZ567" along with the value of the token. .. Upon receiving the token, the mobile device 102 will use the route to communicate with the transaction management system to be the route associated with the identifier XYZ567 (eg, the route would be https://visa.com/tms/production). ), Perform a search.

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

In some embodiments, one entity or device (transaction management server, token issuer, etc.) can operate 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 the directory service contacts a transaction-related token value, the directory service uses devices (portable device 102, vendor 108, etc.) to obtain additional information related to or available for the transaction. It can act to identify or provide one or more other URIs, URLs (or other addresses) that can be used by (such as the transaction management system 130). As an illustrated, but non-limiting example, a directory service that contacts for a particular transaction (specified by a token value) has a first address from which transaction-related vendor data can be obtained, transaction receipt data (specified by the token value). For example, it is possible to provide a second address that can be obtained (after the transaction is completed) and a third address that can obtain authorization data related to the transaction. Each of these additional addresses, along with a valid token value, can be obtained by the device or subject having the address of the directory server. In some embodiments, the interaction with the directory server can be controlled (eg, only authorized principals or devices can obtain information from the directory service). Additional levels of relationships can also be used. For example, a token issuer may provide an address associated with transaction details, which may refer to other devices or entities for additional transaction details, which may be , Additional information about the transaction can be referenced.

In some embodiments, the value from the token itself may not be needed to determine the appropriate transaction management system 130 to use. For example, the portable device 102 or vendor 108 can be any number, such as the time of day, the day of the week, the current transaction volume at the location of the interaction, the purchase price, or any other factor that determines which transaction management system 130 to use. One or more rules can be observed based on the above factors. The portable device 102 or vendor 108 also sets a default transaction management system 130 (which defines a default transaction management system 130 to use when a particular transaction management system 130 is not specified in connection with a token). The transaction management system 130 modifies based on one or more rules for evaluating data that can include one or more data items from tokens or data items from any other source. You may be able to do it.

In a further embodiment, the token captured by the mobile device 102 has an identifier that can be decrypted by the mobile payment application on the mobile device 102 to derive a route to the associated transaction management system 130an. Can include. For example, an algorithm could be used to translate the identifier received within the token into a route to the appropriate transaction management system 130. As an illustrated example, the simple identifier "V1P" can be used to construct the route for https://visa.com/1/production based on the following method: the first of the identifiers. The "V" at the position of is mapped to the domain "visa.com", the "1" at the second position of the identifier is mapped to the directory with the same name, and the "P" at the third position of the identifier is , Map to the “production” subdirectory. Similar methods and mappings can be used to generate a wide variety of URL / URI schemes, allowing the mobile payment application on the mobile device 102 to efficiently follow the correct route to communicate with the appropriate transaction management system 130. Makes it possible to identify. Those skilled in the art will appreciate that other techniques can also be used to determine the appropriate route to the transaction management system when reading this disclosure.

In some embodiments, the functions performed by the transaction management system 130 can be performed by one or more entities. For example, in some embodiments, the functions performed by the transaction management system 130 can be performed by the wallet issuer and the token issuing authority. 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. The functions performed by the token issuer can include, for example, functions related to vendor management, vendor authentication, and some basic transaction management. Along with several different token issuers (eg, interacting with different vendors facilitating transactions relating to the invention), several different wallet issuers (eg, issuing mobile wallets to multiple consumers and theirs). (Managing user-related functions) can exist for consumers. The features of such embodiments will be described with reference to FIG.

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

The portable device 202 of FIG. 2 can communicate, for example, on one or more wired and / or wireless networks 201. As an example, the wireless network can be a mobile network (represented by cell transmitter 215). The portable device 202 can communicate over the mobile or other wireless network via the gateway 216 and can communicate with the network 214 (eg, the Internet or other public or private networks). An access point, such as an access point 218, can be provided to facilitate data and other communication access to network 214. The access point 218 can follow, for example, 802.11g (or other) communication standards. For example, in an embodiment in which the portable device 202 drives a payment application that allows the portable device 202 to function as a payment device according to the present invention, the payment application connects the network 201 to one or more transaction management systems 230. It is possible to generate or control data communication via the system.

In some embodiments, the portable device 202 is capable of communicating both voice and data over the wireless network 214 via the access point 218. For example, the portable device 202 makes or receives a telephone call, receives, sends and receives an e-mail, and sends a short message service ("SMS") message over a wireless network via an access point 218. You can send and receive, send and receive e-mail messages, and receive, access electronic documents, send and receive streaming media, and so on. Similar communication can be made via network 215.

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

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

Contractor 208, as described, to process payments and transactions, including payment transactions relating to the present invention, including "traditional" or standard payment transactions, including cash, standard payment cards, etc. One or more vendor systems 209 can be operated. The vendor system 209 can be a networked sales location system (for physical retailer locations) or a shopping cart system (for electronic trading or internet retailer locations, etc.). .. When the "trader" is an ATM device, the trader system 209 can be an ATM network or the like. The vendor system 209 can also be a combination of systems designed to allow vendors to receive payments for vendors and services. In some embodiments, the vendor system 209 is capable of communicating with one or more sales location devices 212 having display devices 213 for presenting and receiving information from customers. For example, if the vendor 208 is a physical retailer location, the vendor systems 209 are each located in different checkout lanes or locations within the store (or in different stores in different geographic locations). ), Can communicate with several different retail location devices 212. Each of the sales location devices 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 present the payment for the purchase. It can be displayed or communicated.

As another example where the vendor 208 is the internet or other electronic trader, the vendor system 209 is a web server (or some accessible to the internet) configured to handle purchase transactions associated with the vendor 208. It can be a server network). In such an example, the sales location device 212 can interact with the vendor system 209 via a network such as the Internet, and interacts with the vendor system 209, for example, a personal computer, a portable device, or the like. , Can be some remote terminals. Embodiments of the present invention can initiate and execute transactions with both physical and remote types of vendors, so that the place of sale, the place of purchase, or the interaction between the purchaser and the vendor is , Here it can be referred to as a "place of sale" or "place of interaction".

For embodiments of the present invention, the token 210 is displayed at or near the place of sale. The token can be either a "static" token or a "dynamic" token. In situations where static tokens are used, the tokens are close to the location of the place of sale (on a sticker or placard so that the customer can easily see, read, or capture the token). Printed, displayed, or provided. The static token 210 can be printed as a barcode image, as an alphanumeric identifier, or in any other form. In some embodiments, the token can be presented using the portable device 202 in a form that is easily discernible by humans so that both keystrokes and captures are possible. In embodiments where static tokens are used, additional processing steps can be performed (as further described below) to provide the mobile device 202 with detailed information about the transaction.

In embodiments where dynamic tokens are used, the tokens can be displayed on the display device 213 associated with the place of sale device 212. Dynamic tokens can be generated to include transaction information (eg, purchase amount, etc.), and in some embodiments, between the portable device 202 and the transaction management system 230 during a payment transaction. It can contain fewer messages in between. The token 210 is in another form in which the token 210 can be captured as a barcode image, as an alphanumeric identifier, as a radio signal, or as an image (eg, using a camera or scanner associated with the portable device 202). It can be encoded or displayed. The token 210 can also be keyed in by the customer of the portable device 202 or captured by a wireless receiver associated with the portable device 202. In some embodiments, the portable device can be operated with multiple types of tokens 210 (eg, a mobile application captures an image, depending on how the token 210 is presented to the place of sale. Token 210 can be captured using wireless reception or keystrokes).

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

In a typical exemplary transaction, the customer first selects mobile payment as the payment option and authenticates by the payment application on the mobile device 202 (or via a web browser that interacts with the transaction management system 230). It processes and captures the token 210 from the device associated with the vendor 208 (such as from display 213 of the sales location device 212) with the transaction details and a preferred or utilized from the payment account list or transaction management system 230. Purchase goods or services from vendor 208 by receiving a list of available accounts and selecting payment options on the portable device 202 and submitting a customer payment authorization request to transaction management system 230 across network 201. Can be done.

Choosing a payment option involves receiving information that identifies one or more payment accounts available to the customer. The available payment account may be designated by the customer during a registration process, such as the process described below in connection with FIG. In connection with some embodiments, the presentation of different payment account options is in the list of available payment accounts so that the customer is presented with the account that is most suitable or available for the current transaction. It can include applying one or more rules or choices. The customer selects the payment account to use (or, in the case of a compound transaction registration transaction, the account), and the information is transmitted to the transaction management system 230. In some embodiments, all of the customer's available payment accounts can be displayed to the customer after the customer has been authenticated.

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

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

In some embodiments where the dynamic token 210 is used, it is not necessary for the mobile device 202 to receive transaction details from the transaction management system 230, but rather some or all of the transaction details. , Can be provided to the portable device 202 via data encoded or contained in the dynamic token 210. In some embodiments, the portable 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 opportunity to confirm or cancel the payment transaction. To be able to do it. For example, a customer may be prompted to "confirm" or "cancel" a payment transaction. The facilitation can provide additional information about the transaction and the selected payment account, and the customer can have detailed information about the transaction before selecting "Confirm" or "Cancel". .. In some embodiments, the customer may be given the opportunity to set a choice or configure a mobile payment application to enable or disable a message or transaction step. As a particular example, a customer may be given the opportunity to receive (or not receive) a customer payment confirmation request message.

When the final confirmation to proceed with the payment is received from the customer's mobile device 202, the transaction management system 230 provides one or more payment processing networks 232 for granting, clearing, and closing funds for the transaction. Generate an authorization request message for transmission via. This request message contains transaction details such as the transaction amount or other information from the vendor payment authorization request (received from vendor 208) and the actual payment proof associated with the payment account selected by the customer. .. The actual payment proof can be obtained by using the payment account selection information and performing a search for the actual payment account proof stored in advance in a database or location accessible to the transaction management system 230. Authorization processing involves standard financial authorization processing via one or more payment processing networks 232 (eg, VISANET® networks operated by Visa, Inc., automated clearing house systems such as NACHA, etc.). Can be executed using. When the availability of funds is confirmed, the transaction management system sends a vendor payment authorization response message to vendor 208, the transaction is completed at sales location 212, and the customer payment authorization response message is sent to the customer's mobile device 202. Will be sent.

A situation in which a portable device 202 is used to obtain a token from a transaction management system 230 and a vendor 208 (or another portable device, or other interaction location device) captures a token from the portable device 108. In, the same processing can occur as described above.

In some embodiments, the payment system associated with the present invention may include multiple entities performing different processing functions typically provided by one or more transaction management systems described above. For example, in some circumstances, it is desirable for a plurality of entities (referred to herein as "wallet issuers") to issue and manage mobile payment applications relating to the present invention. For example, a financial institution or other entity may choose to publish and manage tasks and functions that provide customers with mobile payment applications. This will be multiple wallet issuers participating in the payment system of the present invention. Similarly, a financial institution or other entity may choose to provide a token issuing function on behalf of one or more vendors. That is, the entity can have an existing relationship with the vendor and can already be integrated with or have access to the vendor's sales location and other vendor systems. The subject may want to provide the trader with a token issuing function. This allows a plurality of token issuing authority to participate 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 issuers 250 and one or more wallet issuers 260 are shown instead of the transaction management system 230. The one shown in FIG. 3 (but in some embodiments, one or more transaction management systems 230 in a system operating with one or more wallet issuers 260 and one or more token issuer 250). , Still available). As shown in FIG. 3, the wallet issuer 260 can communicate with the portable device 202 via one or more network paths. In general, the wallet issuer 260 and each mobile device 202 operating the mobile payment application issued by the wallet issuer 260 can communicate (eg, the mobile payment application is the wallet issuer associated with the mobile device 202). Can be encoded to ensure reliable interaction and communication with 260). Further, the token issuing authority 250 communicates with one or more vendors 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 issuer 250 (eg, to complete a transaction involving both entities). Further, while the wallet issuer 260 is shown to communicate with one or more payment processing networks 232, in some embodiments, the token issuer is also indicated with one or more payment processing networks 232. You can communicate. Further details of transactions involving these entities will be provided below, along with a description of FIG.

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

In the registration process 400 of FIG. 4, the customer first registers with the registration server (which is, or can be associated with, the transaction management system 230 of FIG. 2 or the wallet issuer of FIG. 3). Start when interacting to start processing. For example, a customer may access a registration web page associated with a registration server or use the functionality of a mobile application to complete the registration process (on either a mobile device or other computer device). ) You can operate an internet browser. The registration web page can request the customer to provide a specific method to initiate the account generation process. For example, a customer may provide contact information, including one or more email addresses and telephone numbers, as well as name, address, and other contact information. A customer identifier or other unique record (or multiple records) can be established in a database associated with or accessible to transaction management system 230 or wallet issuer 260. The customer identifier can be used to uniquely identify the customer. The customer identifier is an alphanumeric identifier assigned by transaction management system 230 (depending on the embodiment, or wallet issuer 260, etc.), or information based on or provided by the customer (eg, mobile phone number). Alternatively, it can be an identifier associated with the portable device 202).

Processing continues at 404, where the customer establishes an account relationship with transaction management system 230 (or, depending on the embodiment, wallet issuer 260). In some embodiments, account generation comprises providing contact information and identifying information relevant to the customer, as well as information identifying one or more mobile devices with which the customer wants to make a transaction. Each portable device 202 may have, for example, a telephone number and / or another unique identifier (hardware serial number, ASIN (Amazon Standard Identification Number), advertising identifier in the case of iPhone, component serial number such as CPU serial number, etc. ). In some embodiments, the system is associated with a mobile device, in which the customer registers by downloading a payment application having a registration module, either from a browser on the mobile device or first on the mobile device. , Unique specific information (eg, hardware serial number, ASIN, advertising identifier, or other device identifier, etc.) can be captured.

Processing continues at 406, where the customer provides information about one or more payment devices or payment accounts that the customer wants to be associated with the payment system of the invention. In other words, the customer provides information about one or more payment accounts that the customer wants to associate with the transaction management system 230 (or, depending on the embodiment, the wallet issuer 260) the customer's account relationship. For example, a customer can enter information about one or more credit cards, debit cards, gift cards, bank accounts, check accounts, and so on. The information about each account includes the actual payment proof or enough information to process the transaction using that account. For example, with respect to a credit or debit card, the information can include a primary account number (or PAN (Permanent Account Number)), an expiration date, and a verification code. For bank accounts, the information can include a routing number and an account number. Other information, such as bank or issuer information, can also be entered at 406.

As a graphic example, a customer called "Jane" has entered details about four of her payment accounts that she wants to utilize in connection with the present invention. These are the primary account number (or PAN) of #######, the Chase Credit Card with a card expiration date of 05/12, the ABA number of ####### and ###### Webster Bank check account with ## account number, ######## PAN and 06/11 card expiration date Webster Bank Visa debit card, ###### PAN and 8 / Includes Starbucks gift cards with 10 expiration dates. Additional account identification information can be provided as needed (eg, in some embodiments, a card confirmation number can also be provided for the payment card). The data acquired during process 400 can be safely stored, for example, in a PCI compliant database. In some embodiments, by securely storing payment card data (including expiration date, verification code), payments made using the present invention are subject to discount exchange as a "card present" transaction. Can be done. For some embodiments, the customer may add, remove, or update account information as needed.

Processing continues at 408, where the customer can optionally establish one or more choices or rules in connection with the use of one or more accounts entered in 406. For example, a customer may specify one account as the "major" or default account. Other rules and choices can also be set up so that the account is efficiently and logically selected and used. For example, a customer can specify priorities or rules based on other accounts that indicate how a particular payment account should be treated for other payment accounts. Customers can also optionally specify usage restrictions or balance conditions that govern when and how the payment account should be presented. Customers can also specify the order of accounts displayed on their mobile phones based on which vendor they purchase from, the funds available in each account, or the rewards they receive by using each account. You can.

In some embodiments, rules (such as customer-designated rules) can allow payment processing to proceed faster or with fewer customer steps. For example, a customer can specify that a default payment account should be used when making a purchase at a particular vendor (a type of purchase, such as a purchase less than a certain amount). In such situations, a purchase transaction using the present invention can proceed without the customer having to select or confirm payment account options, which is automatically done by applying customer-specified rules. It is done in.

Those skilled in the art will read this disclosure to specify that a wide variety of account-level rules will allow customers to control how (and when) payment accounts are presented as payment options. You will understand what can be done.

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

When Jane uses her portable device to perform a transaction using the present invention, which payment account is available for the transaction management system 230 (or wallet issuer 260) for the transaction? Will compare the rules and choices Jane specified for the transaction details to recommend. For example, if Jane uses her portable device to buy a cup of coffee at Starbucks, the transaction management system allows her to 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 choice of payment options based on their overall choice and purpose of use. In addition, payment accounts that are not available or suitable for a particular transaction can optionally be provided with a transaction management system 230 (or wallet issuer 260) so that the customer does not have to be presented with such a payment account. ) Will be identified as such (for example, if Jane buys gas at a gas station, she will not be presented with a Starbucks gift card as a payment account for the transaction).

In some embodiments, processing can continue at 410 if the customer operates or uses a portable device (iPhone or Android phone) capable of operating applications related to the present invention. At 410, customers are prompted to download and install the application on their mobile device. The application allows customers to operate their mobile devices in order to perform payment transactions related to the present invention quickly and easily. For phones or devices that are incapable of running such applications, links or web pages to customers who can access them through a mobile phone browser so that they can perform payment transactions related to the present invention. , Can be generated or provided.

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

In some embodiments, such as those illustrated in FIG. 3, different entities, systems, or devices perform different transaction management functions. For example, in some embodiments, a plurality of interactions with a plurality of transactions, including a plurality of portable devices 202 and a plurality of vendors 208 (or other interaction locations such as ATMs, other portable devices, etc.). There can be a wallet issuer 260 and a plurality of token issuer 250. For example, one consumer obtains a mobile payment application on their mobile device 202 from their financial institution or other entity, and the financial institution or other entity gives these consumers a wallet issuer 260. You can act as (or use an agent that performs the function of the wallet issuer). A trader 208 may choose to interact with a token issuer 250 but not with others. Alternatively, the trader 208 may use a single token issuing authority. Each of these choices is a combination of entities participating in a given transaction between the consumer and the trader 208, with the technical challenge of ensuring that all participants are able to engage in the transaction without problems. offer. The embodiment provides a system and method by which a transaction can occur despite a potentially large and diverse number of participants.

See FIG. 5, which shows a further system diagram illustrating a portion of the system 500 in which the consumer operating the portable device 102 performs a transaction with the vendor 108. In the illustrated system 500, the portable device 102 operates a payment application (installed and configured via the process as shown in FIG. 4) provided by the wallet issuer 260. In the illustrated system, vendor 108 has or interacts with one or more issuing authority 250a-250n. For example, vendor 108 may have a relationship with one or more entities (financial institutions, vendors, sales location system vendors, etc.) who trust to provide tokens for transactions performed with respect to the present invention. .. In such a system, it would be technically difficult to make a transaction possible without the features of the present invention. Details of some embodiments that enable a transaction to be performed will be described in FIG. 5, following the processing steps shown as "1"-"6". In some embodiments, only six major interactions are shown, but each interaction can include multiple messages or communications between devices. For convenience and convenience of commentary, only higher level interactions are shown in FIG. However, various implementation options will be described below.

As shown, the consumer operating the portable device 102 wants to perform a transaction with the vendor 108. For example, the customer is in the vendor's checkout lane, where the item he wants to buy is recorded at the cashier by the clerk, and the customer can indicate that he wants to pay with his mobile application. Choosing a mobile payment option causes the vendor system to request a transaction token. In the example, the trader 108 uses several different token issuing authority 250a-n (for example, the trader 108 uses the token issuing authority 250a for some types of transactions, and the other token issuing authority 250a). 250b and 250n can be used). This is shown for illustration purposes only. Those skilled in the art will understand by reading this disclosure that many will only be able to interact with a single token-issuing authority 250.

In the illustrated embodiment illustrated in FIG. 5, vendor 108 has several relationships and in the transaction shown (in the interaction labeled "1"). , Requests the issuance of tokens from the token issuing authority 250b. The request can be requested in the message as a vendor payment authorization request message that sends information related to the transaction being processed to the token issuer 250b. Upon receiving the vendor payment authorization request message, the token issuer 250b generates or identifies a token for use in the transaction. The token issuer 250b can also generate transaction records in process related to the token. In some embodiments, the transaction record being processed can include information including a trader identifier, a terminal identifier, a transaction amount, and other data associated with the transaction being processed. For some embodiments, the tokens generated or acquired by the token issuing authority 250b include information that can be used to identify the token issuing authority 250b. As mentioned above, such information is in a formatted URL string (in some embodiments, the token issuer 250b is provided with the URL, along with information related to other transactions), in the URI. It can include based identifiers, tokenized string identifiers, and so on. The token (including the token identifier and the information identifying the token issuing authority) is returned to the trader 108 for presentation or communication with the portable device 102.

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

The vendor 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 portable device 102. Can be (shown as an interaction of "2"). Once captured, the mobile payment application on the mobile device 102 can be manipulated to decrypt the token in order to obtain the information contained therein (shown as an interaction of "3"). There is). In some embodiments, decryption of the token can include collaborative processing 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: the identification of the particular token issuer 250b who issued the token, the actual token value, any metadata provided with the token value.

In this regard in the transaction, the token issuer 250b has a transaction record in process, including transaction details, received from vendor 108. The transaction record being processed can be identified using the token issued or provided by the token issuer 250b. However, the token issuer 250b may not know at this point information about the customer or the payment mechanism used by the customer. The customer (via the mobile payment application on the mobile device 102) can have information about the transaction in process, as long as it is provided in the metadata decrypted in "3", and has token issuance authority. It can have a token value along with information that can be used to identify the person 250b. The wallet issuer 260 authenticates the customer with the portable device 102 and also has information related to the token received or captured by the portable device 102. In general, in this regard, the wallet issuer 260 also knows the identity of the token issuer 250b. The wallet issuer 260 also knows some items of transaction-related metadata (if those items are provided with a token). For example, consider an illustrated example where a token is encoded with a formatted URL string that has the following format: https: // <hostname / ipaddress>: <port> / <tokenIssuingAuthorityIdentifiter> / <issuedToken> / <transationMetaData>. The string received by the portable device 102 at "2" and decrypted at "3" can reveal the URL string formatted below: https://176.64.73.134:8663/pydt/y7uyjhd7 /USD/34000/MID01001,
It is identified as "pydt", accessible at https://176.64.73.134:8663 by the appropriate token issuer 250b to interact with the mobile device 102, mobile payment application and wallet issuer 260. It is possible to determine that the person has the authority to issue tokens. The token used to identify the transaction record being processed is "y7uyjhd7" and the transaction is in US $ 3,400 in US dollars at the vendor identified as "MID01001". In addition, the wallet issuer 260 can have location and other data received from the portable device 102.

In some embodiments, the process in "3" may not result in the portable device 102 having transaction information. For example, in some embodiments, the token obtained in "2" from vendor 108 may not include metadata (such as data that identifies the transaction amount). In such situations, one or more further interactions are needed. For example, one such further interaction is indicated as an interaction "4" in which the portable device 102 interacts with the wallet issuer 260 in a request for transaction details. The process in "4" can include the portable device 102 providing the wallet issuer 260 with a token value, along with information used to identify the token issuer 250b. The wallet issuer 260 issues a request to the token issue authority 250b, which requests transaction details related to the transaction record being processed, which is related to the token value acquired by the mobile device 102 in "2". Can be done. Processing in "4" (if the token acquired in "2" does not have or does not have enough metadata about the transaction) or (the token acquired in "2" is sufficient for the transaction) If you have the same metadata,) if you process in "3", the process can continue as described below.

On the mobile device 102, the wallet issuer 260, which interacts with the mobile payment application, can proceed to perform a process of determining which customer's payment account can be used for the transaction. For example, a wallet issuer 260 that stores customer choices and rules may only use some customer payment accounts for use by a vendor identified by "MID01001" (or based on vendor type and location). You can judge what you can do. The wallet issuer 260 can also determine that only one payment account is available to use to complete a transaction with an amount of US $ 3,400. The wallet issuer 260 notifies the customer which payment account is available for use in the transaction being processed and obtains a customer selection of one or more payment accounts to use to complete the transaction. Therefore, it can interact with mobile payment applications.

If the customer selects the desired account and confirms or accepts the transaction on the mobile device 102, the process is either the mobile device 102, the wallet issuer 260, or a combination of the mobile device 102 and the wallet issuer 260. Can proceed to interaction "5", which obtains transaction authorization from one or more payment processing networks 280 for the transaction and provides transaction authorization to the appropriate token issuer 250b. Such an interaction at "5" can include several messages. For example, when a customer selects the desired payment account to use to complete a transaction, a message is sent to identify the desired payment account to the wallet issuer 260 (according to some embodiments, the message is the actual payment account). Does not include payment account proofs, but rather includes proxies or identifiers that wallet issuer 260 can use to search for or identify the actual payment account proofs). The wallet issuer 260 constitutes a payment authorization request message with information including the actual payment account proof (PAN, account number, confirmation or confirmation data, expiration date, etc.), transaction amount, and vendor identifier. The payment authorization request message is sent to one or more payment networks for authorization processing. Once the transaction is authorized, the wallet issuer 260 can receive the authorization code and authorization response message sent to the appropriate token issuer 250b along with the token.

Upon receiving the authorization code and authorization response, the token issuing authority 250b uses the received token to identify the transaction record being processed and interacts with the vendor 108 to complete the transaction (“6””. ) Is executed. For example, in a payment-authorized situation, the token issuer 250b can send information confirming that the transaction has completed successfully, and the vendor 108 can have the transaction receipt printed at the location of the interaction. The wallet issuer 260 can also have the transaction receipt or other information transmitted to the mobile device 106.

In some situations, it may not be possible for the wallet issuer 260 to obtain payment authorization from the payment processing network 280 based on the information available to the wallet issuer 260. For example, in some embodiments, the token issuer 250 may not provide additional metadata related to the transaction, such as the vendor's identifier and / or the transaction amount. In such a case, it is possible to provide an embodiment that requires further communication between the wallet issuer 260 and the token issuing authority 250. For example, in some embodiments, when the wallet issuer 260 obtains a token from the portable device 102, the wallet issuer 260 establishes communication with the token issuer 250 and lacks metadata (eg,). , The vendor's identifier, and the transaction amount). The wallet issuer 260 can proceed as described above and obtain payment authorization from the payment processing network 280.

In yet another embodiment of the situation where the wallet issuer 260 is unable to obtain payment authorization from the payment processing network 280 based on the information available to the wallet issuer 260, the token issuer 250 obtains payment authorization. Can be done. For example, in some embodiments, the wallet issuer 260 gives those payment account certificates to the token issuer 250 (along with the token) when identifying suitable payment account certificates for use in a transaction. It can be passed, and the payment authorization message can be configured with the information from the transaction record being processed, along with the payment account proof received from the wallet issuer 260 to the token issuer. In any situation, the ability to complete a transaction gives the mobile device 102 and wallet issuer 260 the information used to identify the token issuer 250 (URL, URI or other data provided with the token). It is based on providing information used to identify a transaction (token), as well as information such as.

As mentioned above, in some embodiments, the portable device 102 can be manipulated to obtain a token, which is to the vendor 108 (or to another device or to a participant in a transaction). ) Can be provided. In such an embodiment, different entities, systems or devices can perform different transaction management functions. See FIG. 6, where one illustrated system is described. Together with FIG. 5, as in the embodiment described above, interact with a plurality of transactions, including a plurality of portable devices 202 and a plurality of vendors 208 (or other interaction locations such as ATMs, other portable devices, etc.). , A plurality of wallet issuers 260 and a plurality of token issue authority 250 can exist.

In FIG. 6, a further system diagram is shown, showing a portion of the system 600 in which the consumer operating the portable device constitutes a transaction with the vendor 108. In the illustrated system 600, the portable device 102 operates a payment application (installed and configured via a process as shown in FIG. 4) provided by the wallet issuer 260. In the illustrated system, the portable device 102 obtains a token from the token issuer 250b (in the transaction labeled as item "1"). In some embodiments, the user and device authentication process is performed with or before interaction "1" (eg, the user and device are authenticated by the wallet issuer 260). In some embodiments, when the mobile device 102 requests a token from the token issuer 250b, it can also provide information available to the token issuer 250b to communicate with the mobile device 102. (This will allow the token issuer 250b to send transaction details to the mobile device 102 within a message described below and labeled as item "4"). Upon receiving the token request, the token issuer 250b can generate a transaction record in process associated with the token. In some embodiments, the transaction record being processed is a wallet issuer identifier (used to identify the wallet issuer 260 associated with the mobile payment application of the mobile device 102), a customer identifier, and processing. It can contain information that includes other data associated with the transaction in it. In connection with some embodiments, the tokens generated or obtained by the token issuing authority 250b include information used to identify the token issuing authority 250b. As mentioned above, such information is in a formatted URL string, URI (in some embodiments, providing the URL to the token issuer 250b, along with information related to other transactions). It can include based identifiers, tokenized string identifiers, and so on. Tokens (including token values and information identifying the token-issuing authority, and, in some embodiments, some additional metadata) are used to present or communicate with vendor 108. It is returned to the portable device 102.

The portable device 102 can display or present the token as a QR code (or present it via a radio signal such as Bluetooth, NFC, etc.), and the vendor 108 (eg, a scanner or other reader) Can be prompted to capture the token (shown as an interaction of "2"). Once captured, vendor 108 can decrypt the token (shown as an interaction of "3") in order to obtain the information contained therein. In some embodiments, decryption of the token can include collaborative processing between the vendor 108 and another entity. The result of token decryption can be any or all of the following: Identification of the particular token issuer 250b who issued the token, the actual token value, any metadata provided with the token value.

The vendor 108 can generate a vendor payment authorization request message and perform a process for sending it to the token issuer 250b identified in the token (eg, via interaction "4"). .. The vendor payment authorization request message can send information related to the transaction being processed to the token issuing authority 250b together with the token value that can be obtained from the interaction of "2" and "3". The information can include vendor identifiers, terminal identifiers, transaction amounts, and other data related to the transaction being processed.

At this point in the transaction, the token issuing authority 250b has a transaction record in process including information received from the portable device 102 and transaction data in process including information received from vendor 108. The transaction record being processed can be identified using the token value issued and provided (and communicated to vendor 108) to the mobile device 102 by the token issuer 250b. The token issuing authority 250b can also have information that can be used to communicate information with the portable device 102 (eg, information such that it can communicate directly with the portable device 102 and / or the portable device 102. Any, or all, of this information, including information that makes it communicable with the portable device 102, through the wallet issuer 260 associated with, is obtained by an interaction labeled as item "1". Rukoto can). However, the token issuer 250b may not know at this point any information about the payment mechanism to be used by the customer. Moreover, in this regard, the portable device 102 may not know the details of the transaction at all (including information related to the vendor, the amount of the transaction, etc.). In some embodiments, the token issuer 250b raises additional messages related to interaction "4". A further message is a message between the token issuer 250b and the mobile device 102. In some embodiments, the message can be routed through the wallet issuer 260 associated with the portable device 102, while in other embodiments, the token can be routed. Direct communication between the issuing authority 250b and the portable device 102 can be enabled.

When the portable device 102 (and, in some embodiments, the wallet issuer 260) has information related to the transaction being processed, including, for example, information identifying the vendor 108, the amount of the transaction, and so on. Processing can continue in the interaction labeled "5".

In the process during the interaction shown as item "5", the wallet issuer 260 interacting with the mobile payment application on the mobile device 102 determines which customer's payment account can be used in the transaction. You can proceed to the execution of the processing to be performed. For example, the wallet issuer 260, which stores customer choices and rules, determines that only some customer payment accounts are available for use by the vendor (or based on the vendor's type or location). Can be done. The wallet issuer 260 can interact with the mobile payment application to inform the customer which payment account is available for use in the transaction being processed and to complete the transaction. You can get customer selections for one or more payment accounts to use.

Once the customer has selected the desired account and confirmed or accepted the transaction on the mobile device 102, the process of interaction "5" proceeds and the mobile device 102, wallet issuer 260, or mobile device 102 and wallet issuance. Any combination of parties 260 can obtain a transaction authorization from one or more payment processing networks 280 for a transaction and communicate with the appropriate token issuer 250b to provide the transaction authorization. Such an interaction at "5" can include several messages. For example, when a customer selects the desired payment account to use to complete a transaction, a message is sent to identify the desired payment account to the wallet issuer 260 (according to some embodiments, the message is: Does not include the actual payment account proof, but rather includes a proxy or identifier that can be used by the wallet issuer 260 to search for or identify the actual payment account proof). The wallet issuer 260 constitutes a payment authorization request message with information including the actual payment account proof (PAN, account number, confirmation or confirmation data, expiration date, etc.), transaction amount, and vendor identifier. The payment authorization request message is sent to one or more payment networks for the authorization process. When the transaction is authorized, the wallet issuer 260 receives the authorization code and authorization response message and sends it along with the token to the appropriate token issuer 250b.

Upon receiving the authorization code and authorization response, the token issuer 250b uses the received token to identify the transaction record being processed and interact with vendor 108 to complete the transaction ("" 6 ”) is executed. For example, in a payment-authorized situation, the token issuer 250b can send information and confirm that the transaction has completed successfully, and vendor 108 prints the transaction receipt at the location of the interaction. Can be made to. The wallet issuer 260 also causes the mobile device 106 to send a transaction receipt or other information.

In some situations, wallet issuer 260 may not be able to obtain payment authorization from payment processing network 280 based on the information available to wallet issuer 260. For example, in some embodiments, the token issuer 250 does not provide additional transaction-related metadata (trader identifier and / or transaction amount) with respect to the interaction of "4". , The portable device 102 and the wallet issuer 260 may not have provided additional transaction information. In that case, an embodiment may be provided that requires further communication between the wallet issuer 260 and the token issuer 250. For example, in some embodiments, when the wallet issuer 260 obtains the token from the mobile device 102, the wallet issuer 260 obtains the missing metadata (including, for example, the vendor's identifier and the transaction amount). Therefore, communication with the token issuing authority 250 can be established. The wallet issuer 260 can proceed as described above and obtain payment authorization from the payment processing network 280.

In yet another embodiment of the situation where the wallet issuer 260 is unable to obtain payment authorization from the payment processing network 280 based on the information available to the wallet issuer 260, the token issuer 250 , You can get payment authorization. For example, in some embodiments, the wallet issuer 260, once identified the appropriate payment account proofs to use in the transaction, passes those payment account proofs (along with the token) to the token issuer 250 and the token issuer. In addition, the payment authorization message can be configured with the information from the transaction record being processed, along with the payment account proof received from the wallet issuer 260. In any situation, the ability to complete a transaction is provided to the mobile device 102 and wallet issuer 260 with information (URL, URI, or token that can be used to identify the token issuer 250, etc. It is based on providing information used to identify a transaction (token), as well as information (such as data).

In the embodiment, a process is generated in a system having a plurality of transaction management systems, and further, a process is generated in a system having a plurality of entities executing different aspects of transaction management (wallet issuer, token issuance, etc.), and is carried. Which transaction management system (or other device or entity) communicates with, for each particular transaction, as a route or communication channel for use by the device to interact with the associated transaction management system. Can be easily and efficiently identified.

Thus, embodiments allow a wide variety of different transaction management systems and other entities and devices to be used in the payment systems of the present invention, to which transaction systems (to the portable devices participating in the payment system). Alternatively, correctly identify and determine whether to communicate with another device or subject) at the location of the transaction to complete the transaction with respect to the invention, based on the information captured in the acquired checkout token. It is possible to do.

The above description of processing here should not be considered to indicate a fixed order in which processing steps are performed. Rather, the processing steps can be performed in any realistic order, including concurrency of at least several steps. The present invention will be described in the context of certain exemplary embodiments, but various modifications, replacements, and modifications that are obvious to those skilled in the art will depart from the spirit and scope of the invention as set forth in the appended claims. It should be understood that what can be done in the embodiments of the disclosure without.

Claims (20)

To receive a payment authorization message from the vendor server by the token issuing authority, the payment authorization message includes information related to a transaction involving the vendor server and the customer's device.
Based on the analysis of the payment authorization message, the token issuing authority determines that the token needs to be provided to the vendor server for the transaction involving the vendor server and the customer's device. When,
The token issuing authority provides a token in response to the determination, and the token is used to identify the token issuing authority by the customer's device when decrypted. It is possible to include coded electronic information and
Sending the token to the vendor server by the token issuing authority
After the transmission, the token issuing authority receives the token and the authorization response message from the wallet issuing server.
Processing the transaction based on receiving the token and the authorization response message by the token issuing authority.
How to include. The method of claim 1, wherein the encoded electronic information includes a uniform resource locator (URL) or a uniform resource identifier (URI) that identifies the web address of the token issuing authority. The method of claim 2, wherein the URL or URI further comprises an electronic link to a directory server that provides additional information about the transaction. The method of claim 2, further comprising inducing the generation of an electronic receipt for the transaction after processing the transaction. The method of claim 4, further comprising transmitting the electronic receipt to the customer's device by the token issuing authority. The method of claim 1, wherein providing the token comprises generating the token by the token issuing authority. The method of claim 1, wherein providing the token comprises identifying or acquiring the token from a third party by the token issuing authority. The method of claim 1, wherein the encoded electronic information includes an Internet Protocol (IP) address of the token issuing authority. To generate a transaction record containing information related to the transaction by the token issuing authority.
By associating the transaction record with the token by the token issuing authority,
The method according to claim 1, further comprising. The method of claim 9, wherein the information associated with the transaction includes an identifier of the vendor server or the amount of the transaction. The method of claim 1, wherein the token can be electronically displayed on the customer's device as a machine-readable code. The method of claim 11, wherein the machine-readable code comprises a quick response (QR) code (the QR code is a registered trademark). 11. The method of claim 11, wherein the token can be wirelessly transmitted as a Bluetooth® signal or as a Near Field Communications (NFC) signal. With non-temporary memory
With one or more hardware processors combined with the non-temporary memory
Is a system that includes
The one or more hardware processors
The token issuing server receives a request from the vendor server to process a transaction involving the vendor server and the customer's mobile device.
The token issuing server generates a token containing decodable information in response to the received request, and the decodable information responds to being decrypted by the token issuing server. To provide an electronic address for
Sending the token to the vendor server by the token issuing server
Upon receiving the token and authorization code associated with the transaction from the wallet issuing server after the transmission.
Identifying the transaction based on at least the received token
To process the transaction in response to the identification,
It is configured to read an instruction from the non-temporary memory so that the system performs an operation including.
system. 14. The system of claim 14, wherein the operation further comprises causing the customer's mobile device to display an electronic receipt for the transaction. 14. The system of claim 14, wherein generating the token comprises generating a machine-readable code that includes the electronic address. The system according to claim 16, wherein the machine-readable code includes a uniform resource locator (URL) of the token issuing server, or a quick response (QR) code in which a uniform resource identifier (URI) is embedded. The above operation
The token issuing server generates a transaction record containing the identifier of the vendor server or the amount of the transaction.
By associating the transaction record with the token by the token issuing server,
14. The system of claim 14. In response to a request received from a vendor to execute a transaction, generate a token with the electronic address of the token issuing entity embedded in it.
To generate a transaction record containing the vendor's identifier or the transaction volume.
To associate the transaction record with the token
Sending the token to the vendor in the form of machine-readable code,
After the transmission, receiving the token and the message authorizing the transaction from the wallet issuing server, and
Identifying the transaction record associated with the token based on the receipt.
To process the transaction in response to the identification,
Contains machine-readable instructions to force the machine to perform actions, including
Non-temporary machine-readable medium. The electronic address includes a uniform resource locator (URL) or uniform resource identifier (URI) of the token issuing entity.
The machine-readable code includes a quick response (QR) code.
The non-transitory machine-readable medium of claim 19.

Images