阅读说明：本技术 用于提供统一交易接口的适配器 (Adapter for providing a unified transaction interface ) 是由 陈悦玺 M·科基切夫 P·马丁 于 2018-06-21 设计创作，主要内容包括：本发明的实施例涉及使得访问交易系统能够接受不同的通信协议。在一些实施例中,访问装置从便携式装置接收将通过在所述便携式装置与远程计算机之间交换交易信息而执行交易的指示,其中所述远程计算机被配置成使用第一通信协议进行通信。接下来,所述访问装置确定所述便携式装置被配置成使用第二通信协议进行通信。所述访问装置接着将所述便携式装置与所述远程计算机之间的通信从所述第二通信协议转换为所述第一通信协议,以协助所述便携式装置与所述远程计算机交换所述交易信息。(Embodiments of the present invention relate to enabling access to a transaction system to accept different communication protocols. In some embodiments, an access device receives an indication from a portable device that a transaction is to be performed by exchanging transaction information between the portable device and a remote computer, wherein the remote computer is configured to communicate using a first communication protocol. Next, the access device determines that the portable device is configured to communicate using a second communication protocol. The access device then converts communication between the portable device and the remote computer from the second communication protocol to the first communication protocol to assist the portable device in exchanging the transaction information with the remote computer.)

1. A method, comprising:

receiving, by an access device from a portable device, an indication that a transaction is to be performed by exchanging transaction information between the portable device and a remote computer, wherein the remote computer is configured to communicate using a first communication protocol;

determining, by the access device, that the portable device is configured to communicate using a second communication protocol; and

converting communication between the portable device and the remote computer from the second communication protocol to the first communication protocol to facilitate the portable device and the remote computer exchanging the transaction information.

2. The method of claim 1:

wherein the first communication protocol defines:

the access device is configured to receive a first set of communications from a first plurality of portable devices configured to communicate using the first communication protocol; and

a second set of communications that the access device is configured to transmit to the remote computer;

wherein the second communication protocol defines a third set of communications that the access device is configured to receive from a second plurality of portable devices configured to communicate using the second communication protocol; and is

Wherein converting the communication between the portable device and the remote computer from the second communication protocol to the first communication protocol comprises obtaining the third set of communications from the portable device and transmitting the second set of communications to the remote computer based on the third set of communications.

3. The method of claim 2, wherein the transaction is a first transaction, the transaction information is first transaction information, and the portable device is a first portable device; and is

Wherein the method further comprises:

receiving, from a second portable device or the remote computer, another indication that a second transaction is to be performed by exchanging second transaction information between the second portable device and the remote computer;

determining that the second portable device is configured to communicate using the first communication protocol; and

facilitating the second portable device to exchange the second transaction information with the remote computer using the first communication protocol and not using the second communication protocol.

4. The method of claim 3, wherein facilitating the second portable device to exchange the second transaction information with the remote computer using the first communication protocol and without using the second communication protocol comprises obtaining the first set of communications from the portable device and transmitting the second set of communications to the remote computer based on the first set of communications.

5. The method of claim 2:

wherein the first communication protocol further defines:

the remote computer is configured to transmit a fourth set of communications to the access device; and

the access device is configured to transmit a fifth set of communications to the first plurality of portable devices configured to communicate using the first communication protocol;

wherein the second communication protocol further defines a sixth set of communications that the access device is configured to transmit to the second plurality of portable devices configured to communicate using the second communication protocol; and is

Wherein converting the communication between the portable device and the remote computer from the second communication protocol to the first communication protocol further comprises receiving the fourth set of communications from the remote computer and transmitting the sixth set of communications to the portable device based on the fourth set of communications.

6. The method of claim 5, wherein the first set of communications, the second set of communications, the fourth set of communications, and the fifth set of communications are in XML or JSON format.

7. The method of claim 5, wherein the first set of communications and the fifth set of communications are in XML or JSON or ISO 7816 format, and the second set of communications and the fourth set of communications are in XML or JSON format.

8. The method of claim 1, wherein the remote computer is located remotely from the access device and communicates with the access device over a network.

9. The method of claim 1, wherein the first communication protocol is stateless and the second communication protocol is stateful.

10. The method of claim 1, wherein the indication is received from the portable device when the portable device is in:

inserting into an interface provided by the access device;

docking the interface;

pairing with the access device;

scanning by the interface; or

Is optically read.

11. The method of claim 1, wherein the method further comprises converting other communications between one or more other portable devices and the remote computer from one or more other communication protocols to the first communication protocol to facilitate the one or more other portable devices exchanging other transaction information with the remote computer.

12. An access device, comprising:

a processor, and

a computer-readable medium coupled to the processor, the computer-readable medium storing one or more instructions that when executed by the processor cause the processor to:

receiving, from a portable device, an indication that a transaction is to be performed by exchanging transaction information between the portable device and a remote computer, wherein the remote computer is configured to communicate using a first communication protocol;

determining that the portable device is configured to communicate using a second communication protocol; and

converting communication between the portable device and the remote computer from the second communication protocol to the first communication protocol to facilitate the portable device and the remote computer exchanging the transaction information.

13. The access device of claim 12:

wherein the first communication protocol defines:

the access device is configured to receive a first set of communications from a first plurality of portable devices configured to communicate using the first communication protocol; and

a second set of communications that the access device is configured to transmit to the remote computer;

wherein the second communication protocol defines a third set of communications that the access device is configured to receive from a second plurality of portable devices configured to communicate using the second communication protocol; and is

Wherein converting the communication between the portable device and the remote computer from the second communication protocol to the first communication protocol comprises obtaining the third set of communications from the portable device and transmitting the second set of communications to the remote computer based on the third set of communications.

14. The access device of claim 13, wherein the transaction is a first transaction, the transaction information is first transaction information, and the portable device is a first portable device; and is

Wherein the instructions further cause the processor to:

receiving, from a second portable device or the remote computer, another indication that a second transaction is to be performed by exchanging second transaction information between the second portable device and the remote computer;

determining that the second portable device is configured to communicate using the first communication protocol; and

facilitating the second portable device to exchange the second transaction information with the remote computer using the first communication protocol and not using the second communication protocol.

15. The access device of claim 14, wherein facilitating the second portable device to exchange the second transaction information with the remote computer using the first communication protocol and without using the second communication protocol comprises obtaining the first set of communications from the portable device and transmitting the second set of communications to the remote computer based on the first set of communications.

16. The access device of claim 13:

wherein the first communication protocol further defines:

the remote computer is configured to transmit a fourth set of communications to the access device; and

the access device is configured to transmit a fifth set of communications to the first plurality of portable devices configured to communicate using the first communication protocol;

wherein the second communication protocol further defines a sixth set of communications that the access device is configured to transmit to the second plurality of portable devices configured to communicate using the second communication protocol; and is

Wherein converting the communication between the portable device and the remote computer from the second communication protocol to the first communication protocol further comprises receiving the fourth set of communications from the remote computer and transmitting the sixth set of communications to the portable device based on the fourth set of communications.

17. The access device of claim 16, wherein the first set of communications, the second set of communications, the fourth set of communications, and the fifth set of communications are in XML or JSON format.

18. The access device of claim 16, wherein the first set of communications and the sixth set of communications are in XML or JSON or ISO 7816 format, and the second set of communications and the fourth set of communications are in XML or JSON format.

19. The access device of claim 12, wherein the indication is received from the portable device when the portable device is in:

inserting into an interface provided by the access device;

docking the interface;

pairing with the access device;

scanning by the interface; or

Is optically read.

20. A portable device, comprising:

a processor, and

a computer-readable medium coupled to the processor, the computer-readable medium storing one or more instructions that when executed by the processor cause the processor to:

providing an indication to an access device that a transaction is to be performed by exchanging transaction information between the portable device and a remote computer, wherein the remote computer is configured to communicate using a first communication protocol and the portable device is configured to communicate using a second communication protocol; and

exchanging the transaction information with the remote computer, wherein to assist the portable device to exchange the transaction information with the remote computer, the access device converts communication between the portable device and the remote computer from the second communication protocol to the first communication protocol.

Background

In the case of access transactions (e.g. transactions to access buildings, transactions for accessing data inside computers, payment transactions) at a resource provider (e.g. secure buildings, merchants) with portable devices (e.g. contact chip cards, NFC enabled phones, contactless credit cards) and access terminals (e.g. chip terminals, contactless terminals), there may be multiple communication protocols for conducting the transactions. The communication protocol may be defined by various features. Some protocols may be stateless, while others may be stateful. Some protocols may specify a particular sequential sequence of instructions or communications to be exchanged between the portable device and the access terminal in order to conduct a transaction.

Because of these characteristics, communication protocols may not be compatible with each other. In particular, a portable device configured to use one communication protocol may not be able to perform transactions with an access terminal configured to use a different communication protocol. In instances where a customer intends to use a credit card to purchase an item at a store checkout station, the credit card may not be available at the store if the credit card relies on a stateful communication protocol while the access terminal is configured to communicate in a stateless manner. As a result, the customer is forced to rely on a different payment method (e.g., cash, check, or another type of credit card) or the store is forced to purchase and maintain another type of access terminal

Embodiments of the present invention address these problems and others individually and collectively.

Disclosure of Invention

Embodiments of the present invention relate to techniques for enabling access terminals and other types of access transaction systems to operate using different communication protocols. The techniques may include receiving, by an access device from a portable device, an indication indicating that a transaction is to be performed between the portable device and a remote computer (e.g., a remote transaction processor). As one example, a customer may be attempting to purchase a physical item from a physical store by swiping a credit card to a card reader, where the card reader is communicatively coupled with a Payment Acceptance (PA) service accessible through a cloud (i.e., a PA in the cloud). In this regard, the purchase of the item may correspond to a transaction, the credit card may correspond to a portable device, the swiping of the credit card may correspond to an indication of the transaction, the card reader may correspond to an access device, and the PA in the cloud may be provided by a remote computer.

In some embodiments, to provide the PA in the cloud, the remote computer may host a transaction processing module having functionality, logic, or data for handling contact or contactless transactions initiated by a portable device interacting with the access device. The remote computer may be configured to communicate using a first communication protocol. For example, the PA in the cloud may be exposed as a representational state transfer (REST) service or a JavaScript object notation (JSON) service, where messages in extensible markup language (XML) or JSON format are exchanged over the first communication protocol.

Next, the access device determines that the portable device is configured to communicate using the second communication protocol. For example, the portable device may be exposed as a stateful service, wherein information in an integrated circuit card command (e.g., compliant with ISO 7816) format is exchanged over a second communication protocol. Note that the terms "first", "second", and the like are not restrictive, but may be used as labels to indicate different devices or objects.

Thus, the access device may play the role of an interpreter that enables a portable device communicating in the second communication protocol to exchange transaction information with a remote computer communicating in the first communication protocol. In so doing, the access device may convert communication between the portable device and the remote computer from the second communication protocol to the first communication protocol to facilitate the portable device and the remote computer to exchange the transaction information.

Other embodiments relate to systems, access devices, computer servers, portable communication devices, portable consumer devices, and computer-readable media associated with the methods described herein.

The nature and advantages of embodiments of the present invention may be better understood with reference to the following detailed description and accompanying drawings.

Drawings

Fig. 1 illustrates a block diagram of a system for conducting access transactions using different communication protocols, in accordance with some embodiments.

FIG. 2 depicts a block diagram of a remote computer, according to some embodiments.

Fig. 3 depicts a block diagram of an access device according to some embodiments.

FIG. 4 sets forth a flow chart illustrating an exemplary method for conducting an access transaction using different communication protocols according to some embodiments.

Fig. 5-6 illustrate sequence diagrams showing operations for performing access transactions using different communication protocols, in accordance with some embodiments.

Detailed Description

Embodiments of the present invention relate to techniques for enabling access terminals and other types of access transaction systems to operate using different communication protocols. The techniques may include receiving, by the access device from the portable device, an indication indicating that a transaction is to be performed between the portable device and a remote computer. As one example, a customer may be attempting to purchase a physical item from a physical store by swiping a credit card to a card reader, where the card reader is communicatively coupled with a Payment Acceptance (PA) service accessible through a cloud (i.e., a PA in the cloud). In this regard, the purchase of the item may correspond to a transaction, the credit card may correspond to a portable device, the swiping of the credit card may correspond to an indication of the transaction, the card reader may correspond to an access device, and the PA in the cloud may be provided by a remote computer.

In some embodiments, to provide the PA in the cloud, the remote computer may host a transaction processing module having functionality, logic, or data for handling contact or contactless transactions initiated by a portable device interacting with the access device. The remote computer may be configured to communicate using a first communication protocol. For example, the PA in the cloud may be exposed as a representational state transfer (REST) service or a JavaScript object notation (JSON) service, where messages in extensible markup language (XML) or JSON format are exchanged over the first communication protocol.

Next, the access device determines that the portable device is configured to communicate using the second communication protocol. Note that the terms "first", "second", and the like are not restrictive, but may be used as labels to indicate different devices or objects. Returning to the above example, a credit card may be configured to communicate with a reader via Near Field Communication (NFC), where the message is in a more compact format, such as an integrated circuit card command (e.g., compliant with ISO 7816).

Thus, the access device may play the role of an interpreter that enables a portable device communicating in the second communication protocol to exchange transaction information with a remote computer communicating in the first communication protocol. In so doing, the access device may convert communication between the portable device and the remote computer from the second communication protocol to the first communication protocol to facilitate the portable device and the remote computer to exchange the transaction information.

In some embodiments, the access device may be configured to determine whether the portable device is configured to communicate using the first communication protocol or the second communication protocol. If the portable device is configured to communicate using the first communication protocol (e.g., if the credit card is a newer type of credit card), the access device may not perform as many conversion operations to forward the communication from the portable device to the remote computer as if the portable device is configured to communicate using the second protocol (e.g., if the credit card is an older type of credit card). In doing so, the access device may enable a remote computer (e.g., a PA in the cloud) to conduct transactions with a wider variety of portable devices.

Before discussing embodiments of the present invention, some terminology will be described.

A "portable device" may include any suitable device operable by a user. Examples of portable devices may include mobile communication devices (e.g., mobile phones), payment devices (e.g., credit cards, debit cards, etc.), user access devices such as access chest cards, and the like. The portable device may store sensitive information such as payment credentials (e.g., primary account number, token, expiration date, etc.) and access credentials.

A "mobile communication device" may be an example of a "communication device" that may be easily carried. Examples of remote communications capabilities include the use of a mobile telephone (wireless) network, a wireless data network (e.g., 3G, 4G, or the like), Wi-Fi, Wi-Max, or any other communications medium that can provide access to a network (e.g., the internet or a private network). Examples of mobile communication devices include mobile phones (e.g., cellular phones), PDAs, tablet computers, netbooks, laptop computers, personal music players, handheld dedicated readers, and the like. Other examples of mobile communication devices include wearable devices, such as smart watches, fitness bracelets, foot chains, rings, earrings, and the like, as well as automobiles with telecommunication capabilities. In some embodiments, the mobile communication device may function as a payment device (e.g., the mobile communication device may store and be able to transmit payment credentials for a transaction). The mobile communication device may also include a vehicle such as a car with telecommunications capabilities.

A "payment device" may include any suitable device that may be used to conduct a financial transaction, such as providing payment credentials to a merchant. Suitable payment devices may be hand-held and compact such that they can be placed into a user's wallet and/or pocket (e.g., may be pocket-sized). Example payment devices can include smart cards, key fob devices (e.g., Speedpass, available from Exxon-Mobil corp^TM) And the like. PaymentOther examples of devices include payment cards, smart media, transponders, and the like. If the payment device is in the form of a debit, credit or smart card, the payment device may also optionally have features such as a magnetic stripe. Such devices may operate in a contact or contactless mode.

A "credential" may be any suitable information that serves as reliable evidence of value, ownership, identity, or authorization. A credential may be a string of numbers, letters, or any other suitable character, and any object or document that may serve as a confirmation.

The "payment credentials" may include any suitable information associated with the account (e.g., a payment account and/or payment device associated with the account). Such information may be directly related to the account, or may be derived from information related to the account. Examples of account information may include a PAN (primary account number or "account number"), a username, an expiration date, and verification values, such as CVV, dCVV, CVV2, dCVV2, and CVC3 values.

The "token" may be a substitute value for the credential. The token may be a string of numbers, letters, or any other suitable character. Examples of tokens include payment tokens, access tokens, personal identification tokens, and the like.

The "payment token" may include an identifier of the payment account that is a substitute for an account identifier, such as a Primary Account Number (PAN). For example, the payment token may include a series of alphanumeric characters that may be used as a substitute for the primary account identifier. For example, the token "4900000000000001" may be used in place of PAN "4147090000001234". In some embodiments, the payment token may be "reserved format" and may have a numeric format (e.g., ISO8583 financial transaction message format) consistent with account identifiers used in existing transaction processing networks. In some embodiments, the payment token may be used in place of the PAN to initiate, authorize, settle, or resolve a payment transaction, or represent the original credential in other systems that would normally provide the original credential. In some embodiments, the payment token may be generated such that the recovery of the original PAN or other account identifier from the token value may not be computationally derivable. Further, in some embodiments, the token format may be configured to allow an entity receiving the token to identify it as a token and identify the entity that issued the token.

The "user" may comprise an individual. In some embodiments, a user may be associated with one or more personal accounts and/or mobile devices. In some embodiments, the user may also be referred to as a cardholder, account holder, or consumer.

A "resource provider" may be an entity that may provide resources such as goods, services, information, and/or locations. Examples of resource providers include merchants, data providers, transportation departments, government entities, site and home operators, and the like.

A "merchant" may generally be an entity that participates in a transaction and may sell or provide access to goods or services.

An "acquirer" can generally be a business entity (e.g., a commercial bank) that has a business relationship with a particular merchant or other entity. Some entities may perform the functions of both an issuer and an acquirer. Some embodiments may encompass such single entity issuer-acquirer. The acquirer may operate an acquirer computer, which may also be generally referred to as a "transmitting computer".

An "authorizing entity" may be the entity that authorizes the request. Examples of authorized entities may be issuers, government agencies, document repositories, access administrators, and the like. The authorizing entity may operate an authorizing computer.

An "issuer" may generally refer to a business entity (e.g., a bank) that maintains a user's account. The issuer may also issue payment credentials to the consumer that are stored on a portable device such as a cell phone, smart card, tablet, or laptop.

An "access device" may be any suitable device that provides access to a remote system. The access device may also be used to communicate with a merchant computer, a transaction processing computer, an authentication computer, or any other suitable system. The access device may generally be located at any suitable location, such as at a merchant location. The access means may take any suitable form. Some examples of access devices include POS or point-of-sale devices (e.g., POS terminals), cellular phones, PDAs, Personal Computers (PCs), tablet PCs, hand-held dedicated readers, set-top boxes, Electronic Cash Registers (ECRs), Automated Teller Machines (ATMs), Virtual Cash Registers (VCRs), kiosks, security systems, access systems, and the like. The access device may use any suitable contact or contactless mode of operation to send or receive data from or associated with the mobile communication device or payment device. In some embodiments where the access device may comprise a POS terminal, any suitable POS terminal may be used and may include a reader, a processor, and a computer readable medium. The reader may include any suitable contact or contactless mode of operation. For example, an exemplary reader may include a Radio Frequency (RF) antenna, an optical scanner, a barcode reader, or a magnetic stripe reader to interact with a payment device and/or a mobile device. In some embodiments, a cellular phone, tablet, or other dedicated wireless device used as a POS terminal may be referred to as a mobile point of sale or "mPOS" terminal.

An "authorization request message" may be an electronic message requesting authorization for a transaction. In some embodiments, an authorization request message is sent to the transaction processing computer and/or the issuer of the payment card to request authorization for the transaction. The authorization request message according to some embodiments may conform to ISO8583, which ISO8583 is a standard of systems for exchanging electronic transaction information associated with payments made by users using payment devices or payment accounts. The authorization request message may include an issuer account identifier that may be associated with the payment device or the payment account. The authorization request message may also include additional data elements corresponding to "identification information," including (by way of example only): a service code, a Card Verification Value (CVV), a dynamic card verification value (dCVV), a primary account number or "account number" (PAN), a payment token, a user name, a validity period, and so forth. The authorization request message may also include "transaction information," such as any information associated with the current transaction, such as the transaction amount, merchant identifier, merchant location, acquirer Bank Identification Number (BIN), card acceptor ID, information identifying the item being purchased, etc., and any other information that may be used to determine whether to identify and/or authorize the transaction.

The "authorization response message" may be a message in response to the authorization request. In some cases, the authorization response message may be an electronic message reply to the authorization request message generated by the issuing financial institution or the transaction processing computer. The authorization response message may include, for example, one or more of the following status indicators: approval-the transaction is approved; decline-transaction not approved; or call center-suspend more informative responses, the merchant must call the toll free authorized telephone number. The authorization response message may also include an authorization code, which may be a code indicating that the transaction is approved that the credit card issuing bank returned to the merchant's access device (e.g., PA equipment) in response to the authorization request message in the electronic message (either directly or through the transaction processing computer). The code may serve as proof of authorization.

A "server computer" may include a powerful computer or cluster of computers. For example, a server computer may be a mainframe, a minicomputer cluster, or a group of servers functioning as a unit. In one example, the server computer may be a database server coupled to a network server. The server computer may include one or more computing devices and may service requests from one or more client computers using any of a variety of computing structures, arrangements, and compilations.

The "memory" may be any suitable device that can store electronic data. Suitable memory may include a non-transitory computer-readable medium that stores instructions executable by a processor to implement a desired method. Examples of memory may include one or more memory chips, disk drives, and the like. Such memories may operate using any suitable electrical, optical, and/or magnetic operating modes.

A "processor" may refer to any suitable data computing device. The processor may include one or more microprocessors that work together to implement the desired functionality. The processor may comprise a CPU including at least one high speed data processor sufficient to execute program components for performing user and/or system generated requests. The CPU may be a microprocessor, such as AMD's fast dragon (Athlon), drill dragon (Duron), and/or gosauron (Opteron); PowerPC from IBM and/or Motorola; cell processors by IBM and Sony (Sony); intel (Intel) sialon (Celeron), Itanium (Itanium), Pentium (Pentium), to strong (Xeon) and/or XScale; and/or the like.

I. System for providing a unified transaction interface

FIG. 1 shows a block diagram of a system including a user 112, a portable device 102, a 104, an access device 106, a remote computer 108, and a communication network 120. The user 112, the portable device 102, the access device 106, and the user 114 are depicted as being located within the area 150. Portable device 102 and remote computer 108 may be configured to communicate using a first communication protocol, while portable device 104 may be configured to communicate using a second communication protocol. Portable devices 102 and 104 exchange communications with access device 106, which in turn exchanges communications with remote computer 108 via communications network 120. In particular, the access device 106 may serve as an interpretation relay that enables a portable device (e.g., portable device 102 or portable device 104) to exchange transaction information with the remote computer 108 during a transaction.

In one example, the user 112 and 114 may be a customer attempting to purchase something at a brick and mortar store, the portable device 102 may be a newer type of credit card carried by the user 112, the portable device 104 may be an older type of credit card carried by the user 114, the access device 106 may be a card reader device located in a store building, the communication network may be the internet, and the remote computer 108 may provide the PA in the cloud. In this example, the user 112 may use the portable device 102 to conduct a first transaction with the access device 106 and the remote computer 108, while the user 114 may use the portable device 104 to conduct a second transaction with the access device 106 and the remote computer 108.

When a transaction is initiated between the portable device 102 and the access device 106, the portable device 102 and the remote computer 108 may attempt to exchange transaction information. In some embodiments, the PA in the cloud may seek to obtain payment account details from the portable device 102, while the portable device 102 may seek to obtain transaction data (e.g., terminal transaction compliance, language preference, transaction currency code, etc.) from the PA in the cloud. To protect the remote computer 108 from handling other communication protocols than the first communication protocol, embodiments may configure the access device 106 to act as a communication translation or abstraction module, where the access device 106 intercepts, screens, translates, and/or filters communications between the remote computer 108 and any portable devices attempting to perform transactions with the remote computer 108.

The communication protocol between the access device 106 and the portable device 102 may depend on their respective capabilities (e.g., what protocol they commonly employ, e.g., contact, contactless, NFC, bluetooth, Wi-Fi, QR code, etc.). Embodiments may configure the access device 106 to act as a communication translation or abstraction module that prevents the remote computer 108 from supporting multiple communication protocols, one translation/abstraction module for each type of portable device 102.

In particular, the access device 106 may use different communication protocols (e.g., a first communication protocol and a second communication protocol). Upon receiving a communication from the portable device under a communication protocol that is incompatible with the remote computer 108 (e.g., the second communication protocol), the access device 106 may convert the received communication to be compatible with the remote computer 108 (e.g., compliant with the first communication protocol) and forward the converted communication. Likewise, when receiving communications from remote computer 108, access device 106 may convert the communications to a communication protocol that is incompatible with remote computer 108 before forwarding the converted communications to the portable device.

Returning to the above example, the user 114 may initiate a contact transaction by inserting the portable device 104 into the access device 106 to exchange communications under the first communication protocol between the portable device 104 and the access device 106. Since communications under the second communication protocol are exchanged between the portable device 104 and the access device 106, the access device 106 may convert communications received from the portable device 104 to the first communication protocol and transmit the converted communications to the remote computer 108. The remote computer 108 may generate responses to the converted communications and send the responses to the access device 106 in the form of communications under the first communication protocol. In response, the access device 106 may convert the communication received from the remote computer 108 to the second communication protocol and transmit the converted communication to the portable device 104.

At various points in time, the user 112 may initiate a contactless transaction by holding the portable device 102 in proximity to the access device 106 in order to exchange communications under the first communication protocol between the portable device 102 and the access device 106 via NFC. In this example, access device 106 may determine that portable device 102 and remote computer 108 use compatible communication protocols (e.g., both use the same communication protocol). Thus, because communications under the first communication protocol are exchanged between the portable device 102 and the access device 106, the access device 106 may forward communications received from the portable device 102 to the remote computer 108 without performing a translation. Likewise, upon receiving a communication from remote computer 108, access device 106 may forward the communication to portable device 102 without performing a conversion. In some embodiments, the access device 106 may package communications exchanged between the portable device 102 and the remote computer 108.

In some embodiments, the first communication protocol may correspond to the EuroPay Master Visa (EMV) second generation standard (EMV 2.0), and the second communication protocol may correspond to the EMV first generation standard (EMV 1.0). Each EMV standard is associated with a number of payment schemes. Each payment scheme in EMV1.0 defines its own payment processing module, where each module includes functionality, logic, or data for handling contact or contactless transactions performed using the associated payment scheme. In processing the transaction, the POS terminal will need to determine which payment processing module to use, and then have that module exchange commands with the portable device (where the commands are sent via the exchanged communications and include data). EMV1.0 may be a stateful communication protocol. In other words, the EMV1.0 payment processing module may wish to exchange commands in a particular order.

EMV 2.0 may be a stateless data driven communication protocol that may be associated with a single processing module that may handle different protocols. In general, however, a POS terminal configured to handle EMV 2.0 transactions may not be able to handle EMV1.0 transactions. Rather than having the merchant operate a first POS terminal for EMV1.0 transactions and a second POS terminal for EMV 2.0 transactions, some embodiments may allow the merchant to operate a single physical card reader (i.e., access device 106) capable of handling any payment scheme associated with either the EMV1.0 communication protocol or the EMV 2.0 communication protocol. The card reader may be communicatively coupled to a PA (i.e., remote computer 108) in the cloud that handles payment processing via a single communication protocol (e.g., a first communication protocol).

Thus, in response to a transaction initiated by a credit/debit card, the card reader may be responsible for identifying the communication protocol (e.g., EMV1.0 or EMV 2.0), the payment scheme, and/or the payment processing module based on the credit card usage. If the identified communication protocol, payment scheme, or processing module is not compatible with the PA in the cloud, the card reader will translate or convert the communication from the card into a format compatible with the PA in the cloud. Meanwhile, the PA in the cloud may be responsible for processing payments according to the converted/translated communications. In this regard, the card reader may be referred to as a thin client. The resulting correlated separation may result in multiple modular components (e.g., thin clients and PAs in the cloud), including software that is less complex overall than (1) a single component configured to process payments using any communication protocol (e.g., a single local POS terminal, where the local POS terminal is a complete PA system contained entirely within a physical store) or (2) multiple local POS terminals (e.g., a first POS terminal that handles EMV1.0 transactions and a second POS terminal that handles EMV 2.0 transactions).

In some embodiments, EMV 2.0 may be based on REST or JSON. For example, EMV 2.0 compliant communications may be in XML or JSON format, and/or such communications may be transmitted/received from other interfaces.

Generally, updates to the payment processing logic may be more common than updates to the communication protocol. Thus, relocating the payment processing software from the local POS terminal to the PA in the cloud may more easily update the payment processing logic, as the payment processing network operator no longer needs to update the local POS terminal (e.g., perform any updates by actually accessing the card reader).

The area 150 may correspond to a physical location of the resource provider (e.g., a brick and mortar store) where the portable device 102 and 104 are placed in close proximity (e.g., inches or feet) to the access device 106 to perform the transaction. However, the arrangement depicted in fig. 1 is not intended to be limiting. In other embodiments, for example, the portable device 102 and 104 may be remotely located from the access device 106.

The access device 106 may correspond to one or more access devices located at a resource provider location. For example, the access device 106 may be a physical card reader for extracting transaction information from a credit or debit card used by a customer of the store. The card reader may act as a thin client connected to the remote computer 108 through the internet (e.g., where the card reader is connected to the internet (i.e., communication network 120) through a Wi-Fi connection or an ethernet connection). In general, the access device 106 may provide a unified transaction interface that enables the remote computer 102 to conduct transactions with a wider range of portable devices. In contrast to local PA systems, some embodiments may be implemented in two physically separate devices: the PA functionality is split between the access device 106 and the remote computer 108. In particular, the access device 106 may include logic for communicating with the portable device through various communication protocols, managing status and/or flow (e.g., as applicable to the status communication protocol), and translating communications from one protocol to another. It should be noted that the state or flow of the state communication protocol may affect how the state communication protocol is used to communicate information. In particular, the state or flow of a state communication protocol may specify the number of commands to send, the order of the commands, and which commands carry which data. The access device 106 is discussed in further detail below with respect to fig. 3.

Remote computer 108 may correspond to a cloud-based system or one or more server computer systems located remotely from area 150, possibly including logic for conducting transactions with portable devices (e.g., payment processing logic). In some embodiments, the remote computer 108 may host a payment processing module referred to as a "PA in the cloud. In particular, the PA in the cloud may be a unified payment processing module capable of handling transactions performed using one or more payment schemes under EMV 2.0. Remote computer 108 is discussed in further detail below with respect to FIG. 2.

The portable devices 102 and 104 may each be a portable device as defined above, wherein the portable device 102 is configured to perform transactions using a first communication protocol and the portable device 104 is configured to perform transactions using a second communication protocol. For example, portable device 102 may be a newer type of credit or debit card compatible with EMV 2.0, while portable device 104 may be an older type of credit or debit card compatible with EMV 1.0.

Access device 106 and remote computer 108 may be communicatively coupled to communication network 120. The communication network 120 may be of any type and may include one or more communication networks. Examples of communication network 120 include, but are not limited to, the internet, a Wide Area Network (WAN), a Local Area Network (LAN), an ethernet, a public or private network, a wired network, a wireless network, and the like, as well as combinations thereof. Different communication protocols may be used to facilitate communication, including wired and wireless protocols, such as the IEEE802.XX suite of protocols, TCP/IP, IPX, SAN, AppleTalk, Bluetooth, and others. In general, communication network 120 may include any communication network or infrastructure that facilitates communication between computing devices.

FIG. 2 illustrates a block diagram of a remote computer 108 including an exemplary server computer 202, according to an embodiment. The server computer 202 is illustrated as including a plurality of hardware and software modules (204) and 230). However, it should be appreciated that this is provided for illustrative purposes only, and that each module and associated functionality may be provided and/or performed by the same or different components. That is, the server computer 202 may perform some of the relevant functions and steps described herein with reference to the remote computer 108 by using any suitable combination of software instructions and/or hardware configurations. It should be noted that although fig. 2 (and other systems described herein) illustrate all modules located on a single device, it is not meant to limit the disclosure thereto. Further, a system for implementing the functionality described herein may have more or fewer than all of these components. Additionally, some modules may be located on other devices, such as a remote server or other local device that is functionally connected to the component(s) of the server computer. In some cases, the software module may be located on a virtual machine or container.

The server computer 202 is shown to include a processor 204, a system memory 206 (which may include any combination of volatile and/or non-volatile memory such as cache memory, RAM, DRAM, ROM, flash memory, or any other suitable storage device), and an external communication interface 208. Further, one or more of the modules 210 and 220 may be disposed within one or more of the components of the system memory 206, or may be disposed externally. As mentioned above, the software and hardware modules shown in fig. 2 (and other systems described herein) are provided for purposes of illustration only, and the configuration is not intended to be limiting. Processor 204, system memory 206, and/or external communication interface 208 may be used in conjunction with any of the modules described below to provide the desired functionality. Some example modules and related functionality may be as follows:

the communication module 210 may be configured or programmed to perform some or all of the functionality associated with receiving, sending, and generating electronic messages for transmission to or from any of the entities shown in fig. 2 via the remote computer 108. When the server computer 202 receives an electronic message via the external communication interface 208, it may be passed to the communication module 210. Communication module 210 may identify and resolve relevant data based on the particular messaging protocol used in remote computer 108. The communication module 210 may then transmit the received information to the appropriate module within the server computer 202 (e.g., via the data bus 248). The communication module 210 may also receive information from one or more of the modules in the server computer 202, and generate an electronic message in an appropriate data format in conformance with the transmission protocol used in the remote computer 108, such that the message may be sent to one or more components within the system 100 (e.g., to the access device 106). The electronic message may then be passed to external communication interface 208 for transmission.

The data communication manager 228 may be programmed and/or configured to perform functions associated with (1) preparing and managing a list of data objects requested by the transaction processing module and providing the requested data objects received from the portable device, and (2) managing and responding to data object requests of the portable device by populating the access device with messages sent to the access device having corresponding data objects obtained from the transaction processing module.

In particular, the transaction processing module may notify the data communications manager 228 regarding its data request status. If the transaction processing module requires data of the portable device, the data communication manager list may include a corresponding data identifier. Otherwise, the data communication manager list may be empty. At the same time, the portable device may notify the data communication manager 228 about its data request status. If the portable device requests data from a remote computer, the portable device list may include corresponding data identifiers. The portable device list may be empty if the portable device has no immediate data request. In addition, the portable device may provide the data object requested by the data communication manager.

The data communication manager may synchronize data exchanges between the portable device and the remote computer 108 to optimize performance and minimize the amount of communications exchanged with the portable device. In addition, the data manager may request the secure channel manager 230 to send a secure communication to the portable device. When a communication channel is established using the portable device, the portable device and/or the transaction processing module may notify the data communication manager 228 of its security level preferences, thus directing the data communication manager 228 to interact with the secure channel manager 230 accordingly.

The secure channel manager 230 may be programmed and/or configured to perform functions related to the portable device's exchange of protected data with the portable device that are transparent to the data communication manager 228 and the transaction processing module.

Fig. 3 illustrates a block diagram of an access device 106 including an example computer 302, in accordance with some embodiments. Computer 302 is illustrated as including a number of hardware and software modules (304-314). However, it should be appreciated that this is provided for illustrative purposes only, and that each module and associated functionality may be provided and/or performed by the same or different components. That is, computer 302 may perform some of the relevant functions and steps described herein with reference to access device 106, for example, by using any suitable combination of software instructions and/or hardware configurations.

Computer 302 is shown including a processor 304, a system memory 306, and an external communication interface 308. Further, one or more of the modules 310 and 314 may be disposed within one or more of the components of the system memory 306, or may be disposed externally. Processor 304, system memory 306, and/or external communication interface 308 may be used in conjunction with any of the modules described below to provide the desired functionality. Some example modules and related functionality may be as follows.

The communication module 310 may be configured or programmed to perform some or all of the functionality associated with receiving, sending, and generating electronic messages for transmission to or from any of the entities shown in fig. 3 at the access device 106. When computer 302 receives an electronic message via external communication interface 308, it may be passed to communication module 310. The communication module 310 may identify and resolve the relevant data based on the particular messaging protocol used in the access device 106. The communication module 310 may then transmit the received information to the appropriate module within the server computer 302 (e.g., via the data bus 328). The communication module 310 may also receive information from one or more of the modules in the computer 302 and generate an electronic message in an appropriate data format in conformity with the transmission protocol used in the access device 106 so that the message may be sent to one or more components within the system 100 (e.g., to the remote computer 108). The electronic message may then be passed to the external communication interface 308 for transmission.

The communication module 310 may be configured or programmed to perform some or all of the functions of communicating with a portable device. In particular, the communication module 310 may be responsible for (1) establishing, maintaining, and terminating sessions with portable devices, (2) allowing messages to be exchanged within a given session, and (3) allowing multiple sessions to coexist. The protocol conversion module 312 may be configured or programmed to perform and convert communications sent between the portable device and the remote computer 108 from one communication protocol (e.g., a first communication protocol) to a second communication protocol. Protocol conversion module 312 may be responsible for determining what communication protocol (e.g., EMV1.0 or EMV 2.0) a particular device is configured to use. Depending on this determination, the protocol conversion module 312 may handle the conversion of communications exchanged as a transaction, if desired. For example, communications from the portable device 104 may be received by the communication module 310. Based on determining that the portable device 104 uses the second communication protocol and the remote computer 108 uses the first communication protocol, the protocol conversion module may convert the communication from the second communication protocol to the first communication protocol before forwarding the converted communication to the remote computer 108.

In particular, the protocol conversion module 312 may be responsible for (1) requesting the communication module 310 to establish, maintain, and terminate a session with the portable device, and (2) synchronizing the exchange of messages between the portable device and the remote computer 108 to optimize performance and minimize the amount of communications exchanged with the remote computer.

To this end, the protocol conversion module 312 may be configured or programmed to (1) create, format, and exchange as many messages as possible in a given session to perform as many data requests as possible from a remote computer, and (2) create, format, and exchange as many messages as possible in a given session to perform as many data requests as possible from a portable device.

The data conversion module 314 may be configured or programmed to perform some or all of the functions related to converting data sent between the portable device and the remote computer 108 from one data format (e.g., associated with a first communication protocol) to another data format (e.g., associated with a second communication protocol). The data conversion module 314 may be responsible for determining what communication protocol (e.g., EMV1.0 or EMV 2.0) a particular portable device is configured to use. Based on this determination, the data conversion module 314 may handle the conversion of data exchanged for the transaction, as required. For example, communications from the portable device 104 may be received by the communication module 310. Based on determining that the portable device 104 uses the second communication protocol and the remote computer 108 uses the first communication protocol, the data conversion module may convert a data format associated with the second communication protocol to a format suitable for the first communication protocol and then forward the converted data to the remote computer 108.

Processing transactions in a unified transaction interface

FIG. 4 sets forth a flow chart illustrating an exemplary method for conducting an access transaction using different communication protocols according to some embodiments.

At step 402, an access device receives an indication that a transaction is to be performed between a portable device and a remote computer, wherein the remote computer is configured to communicate using a first communication protocol. The indication may be generated from a variety of inputs, including: inserting the portable device into an interface provided by the access device (e.g., inserting an encrypted chip card into a card reader), docking the portable device to the interface (e.g., docking the mobile phone to a reader), swiping the portable device over the interface (e.g., swiping a credit card into a slot provided by the card reader), pairing the portable device with the access device, scanning the portable device with the interface, or optically reading the portable device with the interface/access device.

In some embodiments, a first communication protocol may define a first set of communications (e.g., selecting a first application on a card, providing a first set of data, and requesting a second set of data from the card), the access device being configured to exchange with a particular set of portable devices configured to communicate using the first communication protocol. For example, a first communication protocol may correspond to EMV 2.0, and a particular set of portable devices configured to communicate using the first communication protocol may correspond to a newer type of credit card. In some embodiments, the communications may include application layer communications that define data objects and data flows (e.g., TCP/IP, bluetooth, ISO 7816) when the transport layer communications define a message format, regardless of the data being exchanged.

The first communication protocol may further define a second set of communications that the access device is configured to exchange with the remote computer, a fourth set of communications that the remote computer is configured to exchange with the access device (e.g., a first transaction processing flow), and a fifth set of communications that the access device is configured to exchange with a portable device configured to communicate using the first communication protocol.

The first set of communications and the second set of communications may be the same as an embodiment that is a simple relay when both the portable device and the remote computer use the same communication protocol. However, some embodiments may have the access device perform translation on communications to optimize performance and minimize the amount of communications exchanged with the remote computer (e.g., package communications in an object or packaging interface) and/or to accommodate a particular transport protocol (e.g., TCP/IP, bluetooth, ISO 7816), even when the portable device and the remote computer use the same communication protocol. In these embodiments, the first set of communications may be different from the second set of communications.

At decision 404, the access device determines whether the portable device is configured to communicate using the first communication protocol or the second communication protocol. In some cases, the first communication protocol is stateless and the second communication protocol is stateful. In some embodiments, the access device may transmit a first communication to the portable device, wherein the first communication conforms to a first communication protocol. If the portable device provides a response that conforms to the first communication protocol, the access device may determine that the portable device is configured to communicate using the first communication protocol and the method proceeds to step 406. On the other hand, if the portable device provides an error response or no response, the access device may determine that the portable device is configured to communicate using the second communication protocol and the method proceeds to step 408.

In some embodiments, the second communication protocol may define a third set of communications (e.g., selecting a second application on the card, providing a third set of data, and requesting a fourth set of data from the card) that the access device is configured to receive from a particular portable device configured to communicate using the second communication protocol. For example, the second communication protocol may correspond to EMV1.0, and a particular set of portable devices configured to communicate using the second communication protocol may correspond to an older type of credit card. The second communication protocol may further define a sixth set of communications (e.g., a second transaction processing flow) that the access device is configured to exchange with a portable device configured to communicate using the second communication protocol.

Generally, the sets of communications may include communications requesting data, communications authenticating data, and communications transmitting data.

In step 406, upon determining that both the portable device and the remote computer use the first communication protocol, the access device assists the portable device and the remote computer in exchanging transaction information using the first communication protocol without using the second communication protocol. In this regard, the access device may exchange a first set of communications with the portable device and transmit a second set of communications to the remote computer based on the first set of communications. The access device may also receive a fourth set of communications from the remote computer and transmit a fifth set of communications to the portable device based on the fourth set of communications. In some embodiments, the access device may relay communications between the portable device and the remote computer without performing any transformations. In other embodiments, the access device may perform transformations on communications between the portable device and the remote computer.

At step 408, upon determining that the portable device and the remote computer use different communication protocols, the access device facilitates the portable device and the remote computer to exchange transaction information by converting one or more communications between the portable device and the remote computer from a first communication protocol to a second communication protocol or from the second communication protocol to a first communication protocol. In particular, the access device may obtain a third set of communications from the portable device and transmit a second set of communications to the remote computer based on the third set of communications. Additionally, the access device may receive a fourth set of communications from the remote computer and transmit a sixth set of communications to the portable device based on the fourth set of communications.

It should be noted that during or after the process of exchanging transaction data between the portable device and the remote computer, one or more authorization request messages may be generated and transmitted to the payment processing network, which may include forwarding the authorization request messages to the acquirer and/or issuer.

Fig. 5-6 illustrate sequence diagrams of operations for performing transactions using different communication protocols, in accordance with some embodiments. Fig. 5 illustrates a transaction conducted between a portable device configured to use a first communication protocol and configured to use the first communication protocol. As shown in FIG. 5, system 500 includes remote computer 502, access device 504, and portable device 506. Note that in some embodiments, remote computer 502, access device 504, portable device 506 may be similar to remote computer 108, access device 106, and portable device 102, respectively.

At step 520, the access device 504 receives a communication from the remote computer 502 to initiate selection of an application for which to perform a transaction. In some embodiments, the access device 504 may have forwarded an indication that a transaction is to be conducted between the remote computer 502 and the portable device 506. The indication may result from a physical interaction between the portable device 506 and the access device 504 (e.g., swiping a credit card on a card reader). At this point, the remote computer (i.e., the PA in the cloud) may determine the applications on the portable device 506 that are available to perform the transaction.

In step 522, the access device 504 forwards the communication in step 520 to the portable device 506 as a "select EMV" command. If the portable device fails to respond correctly to the command, or rejects the command, the access device 504 may determine that the portable device uses the second communication protocol instead of the first communication protocol and may communicate with the portable device 506 using the second communication protocol, as discussed in further detail below with respect to FIG. 6.

At step 524, because the portable device 506 uses EMV 2.0, the access device 504 may receive a communication confirming that the portable device 506 uses the first communication protocol. In some embodiments, the portable device response may also include a request for server data from the remote computer 502.

At step 526, access device 504 forwards the portable device's confirmation of use of the first communication protocol, and any eventual POS data request from portable device 506, to remote computer 502.

Step 552-. To conduct a transaction, remote computer 502 and portable device 506 may seek to obtain transaction information from each other. For example, portable device 506 may wish to know what type of card verification method is supported by remote computer 502. At the same time, the remote computer may wish to obtain a Primary Account Number (PAN), expiration date, country code, and other account information related to the portable device 506.

Because EMV 2.0 is a data-driven communication protocol, different card data or combinations of POS data may be requested or provided in a single communication. In particular, a single communication may request data and provide the data in response to an earlier request. For example, communications from remote computer 502 to portable device 506 may include requests for card data and POS data responsive to POS data requests made by portable device 506. This ability to mix data and data requests in a single communication may reduce the total number of communications exchanged, which may increase speed and reduce the complexity of processing transactions. It should be noted that step 552-558 may be repeated multiple times depending on the transaction information that needs to be exchanged.

At step 552, the access device 504 may receive a communication from the remote computer 502 requesting card data from the portable device 506. The communication may also include POS data. In some embodiments, remote computer 502 provides the POS data requested by portable device 506 in step 524. In some embodiments, remote computer 502 provides all POS data available at that stage to access device 504, regardless of the portable device data request.

At step 554, access device 504 may forward the card data request and POS data to portable device 506. In some embodiments, access device 504 may package the card data request in a list of data objects requested from portable device 506. In some embodiments, access device 504 only provides POS data sets requested by the portable device in previous communications.

At step 556, the access device 504 may receive another communication from the portable device 506 containing the card data requested in the previous step. In some embodiments, the portable device 506 only provides the card data set requested in the last step.

In step 556, access device 504 may request a communication from portable device 506 requesting POS data. In some embodiments, portable device 506 packages the POS data request in a list of data objects requested from remote computer 502.

At step 558, the access device 504 may forward the card data and POS data request to the remote computer 502. In some embodiments, access device 504 may have received POS data requested by portable device 506 in a previous communication with remote computer 502, and may be able to provide them without additional communication with remote computer 502. In some embodiments, access device 504 simply forwards to remote computer 502 a data request from portable device 506 for POS data that it has not yet received.

Fig. 6 illustrates a transaction conducted between a remote computer configured to use a first communication protocol (e.g., EMV 2.0) and a portable device configured to use a second communication protocol (e.g., EMV 1.0). As shown in FIG. 6, system 600 includes remote computer 602, access device 604, and portable device 606. It should be noted that in some embodiments, remote computer 602, access device 604, and portable device 606 may be similar to remote computer 108, access device 106, and portable device 104,.

At step 620, the access device 604 receives a communication from the remote computer 602 to begin selecting an application with which to perform a transaction. At this point, the remote computer may determine the applications on the portable device 606 that are available to perform the transaction.

At step 622, access device 604 may transition to the communication of portable device 606 at step 620 and transmit a "select EMV 1.0" command to the portable device. In some embodiments, access device 604 may have transmitted a "select EMV 2.0" command to portable device 606 using a first communication protocol (e.g., EMV 2.0) to attempt to communicate with portable device 606. However, since the portable device 606 rejects the "select EMV 2.0" command or does not respond properly, the access device 604 may communicate with the portable device 606 using a second communication protocol (e.g., EMV 1.0).

At step 624, the portable device 606 may respond to the access device 604 that it is using the second communication protocol (e.g., EMV 1.0). In some embodiments, the portable device response may also include a request for certain POS data from the remote computer 602. In some embodiments, the portable device POS data request may be implicit in the second communication protocol and explicitly constructed by the access device 604.

At step 626, access device 604 may transmit a communication to remote computer 602 with the first communication protocol instructing portable device 606 to use the second communication protocol (e.g., EMV1.0) and possibly have some POS data request. However, the fact that the portable device 606 does not support the first communication protocol may not change the behavior of the remote computer 602. Instead, the remote computer 602 may rely on the access device 604 to isolate the remote computer 602 from any differences between the first communication protocol and the second communication protocol.

Similar to step 552- > 558 of FIG. 5, step 648- > 656 describes a series of exchanges of transaction information between the remote computer 602 and the portable device 606, which is facilitated by the access device 604. Although the transaction information exchanged here may have similarities to the transaction information exchanged in fig. 5, the format of the transaction information transmission may be different. In particular, remote computer 602 may request card data and provide POS data in a manner consistent with EMV 2.0, while portable device 606 may request POS data and provide card data in a manner consistent with EMV 1.0. In this regard, access device 604 may handle the transition of EMV 2.0 communications to EMV1.0 communications, as well as the transition of EMV1.0 communications to EMV1.0 communications.

At step 648, the access device 604 may receive a communication from the remote computer 602 requesting the card data requested from the portable device 606. The communication may additionally include some POS data. In some embodiments, the remote computer 602 provides the POS data requested by the portable device 606 in step 624. In some embodiments, the remote computer 602 provides all POS data available at that stage to the access device 604, regardless of the portable device data request.

At step 660, the access device 604 may convert the communication received from the remote computer 602 in step 648 in the first communication protocol (e.g., EMV 2.0) to a communication in the second communication protocol (e.g., EMV 1.0). In some embodiments, the access device 604 may translate all POS data provided by the remote computer 602 and all card data requests sought by the remote computer 602. In some embodiments, the access device 604 may only convert a subset of the card data requested by the remote computer 602 and may only convert a subset of the received POS data that conforms to the second communication protocol (e.g., EMV 1.0). Access device 604 may then transmit the EMV1.0 communication to portable device 606.

At step 662, the access device 604 may receive a communication in a second communication protocol (e.g., EMV1.0) from the portable device 606, wherein the communication includes the requested card data. In some embodiments, the portable device response may also include a request for certain POS data from the remote computer 602. In some embodiments, the portable device POS data request may be implicit and explicitly constructed by the access device 604.

At step 664, the access device 604 may convert communications received in the second communication protocol (e.g., EMV1.0), extract the card data provided by the portable device 606 at step 662, and convert the card data to communications in the first communication protocol (e.g., EMV 2.0). In some embodiments, the access device 604 may receive all card data requested by the remote computer 602 in a single communication and may continue to exchange communications with the portable device 606 until all card data sought by the remote computer 602 is received.

In some embodiments, the portable device response may also include a request for certain POS data from the remote computer 602. In some embodiments, the portable device POS data request may be implicit and explicitly constructed by the access device 604.

At step 666, the access device 604 may forward the card data and POS data request to the remote computer 602. In some embodiments, the access device 604 may have received the requested POS data in a previous communication with the remote computer 602, and may be able to provide them without additional communication with the remote computer 602. In some embodiments, the access device 604 simply forwards a data request to the remote computer 602 for POS data that it has not yet received.

The various participants and elements described herein with reference to fig. 1-6 can operate one or more computer devices to facilitate the functionality described herein. Any of the elements in fig. 1-6, including any servers or databases, may use any suitable number of subsystems to facilitate the functionality described herein.

In fig. 5-6, after data is exchanged between the remote computer 502, 602 and the portable device 506, 606, an authorization request message may be generated by the remote computer 502, 602. An "authorization request message" may be an electronic message sent to the payment processing network and/or the issuer of the payment card to request authorization for a transaction. The authorization request message according to some embodiments may conform to ISO8583, which is a standard of systems for exchanging electronic transaction information associated with payments made by consumers using payment devices or payment accounts. The authorization request message may include an issuer account identifier that may be associated with the payment device or the payment account. The authorization request message may also include additional data elements corresponding to "identification information," including (by way of example only): a service code, a CVV (card verification value), a dCVV (dynamic card verification value), an expiration date, etc. The authorization request message may also include "transaction information," such as any information associated with the mobile transaction, such as the transaction amount, merchant identifier, merchant location, etc., and any other information that may be used to determine whether to identify and/or authorize the transaction.

The authorization request message may be transmitted to the issuer computer via the acquirer computer and the payment processing network. The issuer computer may approve or deny the transaction and may generate an authorization response message. The "authorization response message" may be an electronic message reply to the authorization request message generated by the issuing financial institution or the payment processing network. The authorization response message may include, for example, one or more of the following status indicators: approval-the transaction is approved; decline-transaction not approved; or call center-suspend more informative responses, the merchant must call the toll free authorized telephone number. The authorization response message may also include an authorization code, which may be a code indicating that the transaction is approved that the credit card issuing bank returned to the merchant's access device (e.g., POS device) in response to the authorization request message in the electronic message (either directly or through the payment processing network). The code may serve as proof of authorization. As described above, in some embodiments, the payment processing network may generate or forward an authorization response message to the merchant. The authorization response message may be transmitted back to the remote computer 502, 602 via the payment processing network and the acquirer computer. The remote computer 502 may further transmit an authorization response message back to the access device.

Examples of such subsystems or components are interconnected via a system bus. Additional subsystems such as a printer, keyboard, fixed disk (or other memory including computer-readable media), monitor coupled to a display adapter, and other devices are shown. Peripheral devices and input/output (I/O) devices coupled to an I/O controller, which may be a processor or any suitable controller, may be connected to the computer system by any number of means known in the art, such as serial ports. For example, a serial port or external interface can be used to connect the computer device to a wide area network (such as the internet), a mouse input device, or a scanner. The interconnection via a system bus allows the central processor to communicate with each subsystem and to control the execution of instructions from the system memory or the fixed disk and the exchange of information between subsystems. The system memory and/or fixed disk may embody a computer readable medium.

In addition, while the present invention has been described using a particular combination of hardware and software in the form of control logic and programming code and instructions, it should be recognized that other combinations of hardware and software are also within the scope of the present invention. The present invention can be implemented by only hardware or only software or using a combination thereof.

Any of the software components or functions described in this application may be implemented as software code executed by a processor using any suitable computer language, such as, for example, Java, C + + or Perl using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions or commands on a computer readable medium, such as a Random Access Memory (RAM), a Read Only Memory (ROM), a magnetic medium such as a hard drive or floppy disk, or an optical medium such as a CD-ROM. Any such computer-readable media may reside on or within a single computing device, and may exist on or within different computing devices within a system or network.

The above description is illustrative and not restrictive. Many variations of the invention will become apparent to those skilled in the art upon reading the present disclosure. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the pending claims along with their full scope or equivalents.

Any of the methods described herein may be performed in whole or in part with a computer system that includes one or more processors that may be configured to perform the steps. Thus, embodiments may relate to a computer system configured to perform the steps of any of the methods described herein, possibly with different components performing the respective steps or groups of the respective steps. Although presented in numbered steps, the steps of the methods herein may be performed simultaneously or in a different order. Additionally, portions of these steps may be used with portions of other steps of other methods. Further, all or a portion of the steps may be optional. Additionally, any of the steps of any of the methods may be performed by modules, units, circuits, or other means that perform the steps.

One or more features of any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the invention.

The recitation of "a", "an" or "the" is intended to mean "one or more" unless specifically indicated to the contrary.

All patents, patent applications, publications, and descriptions mentioned above are incorporated herein by reference in their entirety for all purposes. No admission is made that they are prior art.