RU2780821C2 - Adapter for providing unified transaction interface - Google Patents

Abstract

FIELD: communication.

SUBSTANCE: invention relates to the field of conducting an access transaction. An access device receives from a portable device an indication on that it is necessary to perform a transaction by means of transaction information exchange between the portable device and a remote computer. In this case, the remote computer is made with the possibility of performing communication using the first communication protocol. Then, the access device determines that the portable device is made with the possibility of performing communication using the second communication protocol. After that, the access device converts messages between the portable device and the remote computer from the second communication protocol to the first communication protocol to help the portable device and the remote computer to exchange transaction information.

EFFECT: provision of a possibility for access transaction system of reception of different communication protocols.

20 cl, 6 dwg

Description

[0001] This application claims the benefit and priority of U.S. Patent Application No. 15/631,716, filed June 23, 2017, which is incorporated herein by reference in its entirety.

BACKGROUND OF THE INVENTION

[0002] In the context of conducting an access transaction (e.g., a transaction to gain access to a building, a transaction to gain access to data inside a computer, a payment transaction) using a portable device (e.g., a contact card with a chip, a telephone with NFC functionality, a contactless credit card) and access terminal (eg, chip terminal, contactless terminal) at the resource provider (eg, in a secure building, merchant) there may be several communication protocols for conducting a transaction. Communication protocols can be defined by various characteristics. Some protocols may be stateless, while others may be stateful. Some protocols may define a specific ordered sequence of commands or messages that must be exchanged between the portable device and the access terminal in order to complete a transaction.

[0003] Due to such characteristics, communication protocols may not be compatible with each other. In particular, a portable device that is configured to use one communication protocol may not be able to transact with an access terminal that is configured to use a different communication protocol. In an example where a consumer intends to use a credit card to purchase an item in a store's checkout line, the credit card may not be usable in the store if the credit card relies on a stateful communication protocol while the access terminal is configured to perform stateless communication. . As a result, either the consumer is forced to turn to another payment method (eg, cash, check, or another type of credit card), or the store is forced to purchase and maintain a different type of access terminal.

[0004] Embodiments of the present invention address these and other problems individually and collectively.

SUMMARY OF THE INVENTION

[0005] Embodiments of the present invention relate to approaches for enabling access terminals and other types of access transaction systems to operate with different communication protocols. Approaches may include receiving by the access device from the portable device an indication that a transaction needs to be performed between the portable device and a remote computer (eg, a remote transaction processor). As one example, a consumer may attempt to purchase a physical item in a physical store by swiping their credit card into a card reader, where the card reader is connected to a payment acceptance (PA) service accessed via the cloud (i.e., .PA in the cloud). In this regard, purchasing an item may correspond to a transaction, a credit card may correspond to a portable device, swiping a credit card may correspond to a transaction instruction, a card reader may correspond to an access device, and PA in the cloud may be provided by a remote computer.

[0006] In some embodiments, in order to provide a PA in the cloud, the remote computer may include a transaction processing module that has functions, logic, or data used to process contact or contactless transactions initiated by portable devices interacting with access devices. The remote computer may be configured to communicate using the first communication protocol. For example, PA in the cloud can be seen as a Representational State Transfer (REST) service or a JavaScript Object Notation (JSON) service, while exchanging messages in a format that conforms to Extensible Markup Language (XML). ) or JSON occurs over the first communication protocol.

[0007] The access device then determines that the portable device is configured to communicate using the second communication protocol. For example, the portable device may be visible as a stateful service, with messages formatted as integrated circuit card commands (eg, conforming to ISO 7816) being exchanged over a second communication protocol. It should be noted that the terms "first", "second", etc. are not limiting, but can be used as labels to represent different devices or objects.

[0008] As such, the access device may play the role of an interpreter that allows a portable device that communicates via the second communication protocol to exchange transaction information with a remote computer that communicates via the first communication protocol. To do this, the access device may convert messages between the portable device and the remote computer from the second communication protocol to the first communication protocol to help the portable device and the remote computer exchange transaction information.

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

[0010] A better understanding of the essence and advantages of the embodiments of the present invention can be achieved with reference to the following detailed description and accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0011] FIG. 1 shows a block diagram of a system for conducting access transactions using various communication protocols, in accordance with some embodiments.

[0012] FIG. 2 is a block diagram of a remote computer according to some embodiments.

[0013] FIG. 3 is a block diagram of an access device according to some embodiments.

[0014] FIG. 4 is a flowchart showing an exemplary method for conducting access transactions using various communication protocols, in accordance with some embodiments.

[0015] FIG. 5, 6 is a sequence diagram showing operations for conducting access transactions using different communication protocols, in accordance with some embodiments.

IMPLEMENTATION OF THE INVENTION

[0016] Embodiments of the present invention relate to approaches for enabling access terminals and other types of access transaction systems to operate with different communication protocols. The methods may include receiving by the access device from the portable device an indication that a transaction needs to be performed between the portable device and the remote computer. As one example, a consumer may attempt to purchase a physical item in a physical store by swiping their credit card into a card reader, where the card reader is connected to a payment acceptance (PA) service accessed via the cloud (i.e., .PA in the cloud). In this regard, purchasing an item may correspond to a transaction, a credit card may correspond to a portable device, swiping a credit card may correspond to a transaction instruction, a card reader may correspond to an access device, and PA in the cloud may be provided by a remote computer.

[0017] In some embodiments, to provide PA in the cloud, the remote computer may include a transaction processing module that has functions, logic, or data used to process contact or contactless transactions initiated by portable devices that interact with access devices. The remote computer may be configured to communicate using the first communication protocol. For example, PA in the cloud can be seen as a Representational State Transfer (REST) service or a JavaScript Object Notation (JSON) service, while exchanging messages in a format that conforms to Extensible Markup Language (XML). ) or JSON occurs over the first communication protocol.

[0018] The access device then determines that the portable device is configured to communicate using the second communication protocol. It should be noted that the terms "first", "second", etc. are not limiting, but can be used as labels to represent different devices or objects. Returning to the above example, a credit card may be configured to communicate with a card reader via Near Field Communication (NFC), where messages take a format that is more compact, such as integrated circuit card commands (e.g., conforming to ISO 7816) .

[0019] As such, the access device may play the role of an interpreter that allows a portable device that communicates via the second communication protocol to exchange transaction information with a remote computer that communicates via the first communication protocol. To do this, the access device may convert messages between the portable device and the remote computer from the second communication protocol to the first communication protocol to help the portable device and the remote computer exchange transaction information.

[0020] In some embodiments, the access device may be adapted to determine whether the portable device is capable of communicating using a first communication protocol or a second communication protocol. If the portable device is configured to communicate using the first communication protocol (for example, if the credit card is a newer type of credit card), access devices may not need to perform as many conversion operations to transfer messages from the portable device to the remote computer as this this would be the case if the portable device were configured to communicate using the second protocol (eg, if the credit card is an older type of credit card). In doing so, the access device may enable a remote computer (eg, a PA in the cloud) to perform transactions with a wider range of portable devices.

[0021] Before discussing embodiments of the present invention, some terms will be described.

[0022] A "portable device" can be any suitable device that can be carried by a user. Examples of portable devices may include mobile communication devices (eg, mobile phones), payment devices (eg, credit cards, debit cards, etc.), user access devices such as badges, etc. A portable device may store sensitive information , such as payment credentials (for example, primary account numbers, tokens, expiration dates, etc.) and access credentials.

[0023] A "mobile communication device" may be an example of a "communication device" that can be easily transported. Examples of remote communication functionality include the use of a mobile (wireless) network, a wireless data network (e.g., 3G, 4G, or similar networks), Wi-Fi, Wi-Max, or any other communication medium that can provide network access, such like the Internet or a private network. Examples of mobile communication devices include mobile phones (e.g., cellular phones), personal digital assistants (PDAs), tablet computers, netbooks, laptop computers, personal music players, dedicated handheld readers, etc. Additional examples of mobile communication devices include wearable devices. , such as smart watches, fitness bands, electronic bracelets, rings, earrings, etc., as well as vehicles with remote communication functionality. In some embodiments, the mobile communications device may function as a payment device (eg, the mobile communications device may store and be able to transmit payment credentials for a transaction). Mobile communication devices may also include vehicles, such as cars, that have remote communication functionality.

[0024] A "payment device" may include any suitable device that can be used to conduct a financial transaction so as to provide payment credentials to the merchant. Suitable payment devices can be handheld and compact so that they can fit in a user's wallet and/or pocket (for example, they can be pocket-sized). Examples of payment devices may include smart cards, key fob devices (such as the Speedpass™ marketed by Exxon-Mobil Corp.), etc. Other examples of payment devices include payment cards, smart media, transponders, etc. 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 magnetic stripes. Such devices can operate either in contact or non-contact mode.

[0025] "Credential data" can be any suitable information that serves as a reliable proof of value, ownership, identity, or authority. The credential may be a string of numbers, letters, or any other suitable character, or any object or document that can serve as proof.

[0026] "Payment Credentials" may include any suitable information associated with an account (eg, a checking account and/or a 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"), username, expiration date, and verification codes such as CVV, dCVV, CVV2, dCVV2, and CVC3 values.

[0027] "Token" may be a replacement value for credential data. The token can 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.

[0028] A "payment token" may include an identifier for a checking account that is a replacement for an account identifier, such as a Primary Account Number (PAN). For example, a payment token may include a set of alphanumeric characters that can be used as a replacement for the original account identifier. For example, the marker "4900 0000 0000 0001" can be used instead of the PAN "4147 0900 0000 1234". In some embodiments, the payment token may be "format-preserving" and may have a numeric format that matches account identifiers used in existing transaction processing networks (eg, the ISO 8583 financial transaction message format). In some embodiments, a payment token may be used in place of a PAN to initiate, authorize, conduct, or complete a payment transaction or present original credentials in other systems where original credentials would normally be provided. In some embodiments, a payment token may be generated such that recovery of the original PAN or other account identifier from the value of the token cannot be computed. In addition, in some embodiments, the token format may be configured to allow a token-receiving entity to identify it as a token and to recognize the entity that issued the token.

[0029] The "User" may be an individual. In some embodiments, the 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.

[0030] A "resource provider" may be an entity that can provide a resource such as goods, services, information, and/or locations. Examples of resource providers include merchants, data providers, transportation agencies, government agencies, event and accommodation operators, etc.

[0031] A "vendor" can generally be an entity that is involved in transactions and can sell goods or services or provide access to goods or services.

[0032] An "acquirer" can typically be a business entity (eg, a commercial bank) that has a commercial relationship with a particular merchant or other entity. Some entities may act as both an issuer and an acquirer. Some embodiments may cover such single issuer-acquirer entities. The acquirer may control the acquirer's computer, which may also be referred to generically as a "transport computer".

[0033] An "Authorization Subject" may be an entity that authorizes a request. Examples of an authorization subject may be an issuer, a government agency, a document repository, an access administrator, etc. The authorization subject may control the authorization computer.

[0034] "Issuer" can generally refer to a business entity (eg, a bank) that maintains an account for a user. The issuer may also issue payment credentials to the consumer stored on a portable device such as a cellular phone, smart card, tablet or laptop computer.

[0035] An "access device" can be any suitable device that provides access to a remote system. The access device may also be used to communicate with a merchant's 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 the location of a merchant. The access device may be in any suitable form. Some examples of access devices include point-of-sale devices (e.g., POS terminals), cellular phones, personal digital assistants (PDAs), personal computers (PCs), tablet PCs, dedicated hand-held readers, set-top boxes, electronic cash registers (ECRs), automated teller machines (ATMs), virtual cash registers (VCRs), kiosks, security systems, access systems, etc. The access device may use any suitable contact or contactless mode of operation to send or receive data from a mobile communications device or payment device, or related data. 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 have any suitable contact or non-contact mode of operation. For example, to interact with a payment device and/or a mobile device, exemplary card readers may include radio frequency (RF) antennas, optical scanners, barcode readers, or magnetic stripe readers. In some embodiments, a cell phone, tablet, or other dedicated wireless device used as a POS terminal may be referred to as a mobile point of sale terminal or "mPOS terminal".

[0036]The "Authorization Request Message" may be an electronic message that requests authorization for a transaction. In some embodiments, it is sent to the transaction processing computer and/or the payment card issuer to request authorization for the transaction. Authorization request message according to some embodiments may conform to ISO 8583, which is a standard for systems that exchange electronic transaction information related to a payment made by a user using a payment device or checking account. The authorization request message may contain an issuer account identifier, which may be associated with a payment device or settlement account. The authorization request message may also contain additional data elements corresponding to "identifying information", including, by way of example only: service code, CVV (card verification code), dCVV (dynamic card verification code), PAN (primary account number or "account number"). number"), payment token, username, expiration date, etc. The authorization request message may also contain "transaction information", such as any information associated with the current transaction, such as transaction amount, merchant ID, location merchant, acquirer's bank identification number (BIN), card acceptor ID, information identifying items being purchased, etc., as well as any other information that may be used in determining whether a transaction should be identified and/or authorized.

[0037] An "Authorization Response Message" may be a message that responds to an authorization request. In some cases, it may be an electronic response to an authorization request message generated by the issuing financial institution or the transaction processing computer. The authorization response message may contain, by way of example only, one or more of the following status indicators: "approved" - the transaction has been approved; "rejection" - the transaction was not approved; or "call center" - a response that requires more information, while the seller must call a toll-free phone number for authorization. The authorization response message may also contain an authorization code, which may be a code that the credit card issuing bank returns in response to an authorization request message in an email (either directly or via a transaction processing computer) to a merchant's access device (e.g., equipment PA), which indicates the approval of the transaction. The code can serve as confirmation of authorization.

[0038] A "server computer" may include a powerful computer or a cluster of computers. For example, a server computer may be a large mainframe computer, a cluster of minicomputers, or a group of servers that function as one unit. In one example, the server computer may be a database server connected to a web server. The server computer may include one or more computing devices and may use any of a variety of computing structures, arrangements, and compilations to serve requests from one or more client computers.

[0039] "Memory" can be any suitable device or devices that can store electronic data. Suitable memory may include a readable medium that stores instructions that can be executed by the processor to implement the desired method. Examples of memory elements may include one or more memory chips, disk drives, etc. Such memory elements may operate in any suitable electrical, optical, and/or magnetic mode of operation.

[0040] "Processor" may refer to any suitable data computing device or devices. A processor may comprise one or more microprocessors working together to perform a desired function. The processor may include a CPU that includes at least one high speed data processor suitable for executing software components to execute user and/or system generated requests. The CPU may be a microprocessor such as an Athlon, Duron and/or Opteron from AMD; PowerPC from IBM and/or Motorola; Cell architecture processor from IBM and Sony; Celeron, Itanium, Pentium, Xeon and/or XScale from Intel; and/or similar processor(s).

A SYSTEM PROVIDING A UNIFIED TRANSACTION INTERFACE

[0041] FIG. 1 shows a block diagram of a system containing users 112-114, portable devices 102-104, an access device 106, a remote computer 108, and a communication network 120. Users 112-114, portable devices 102-104, and access device 106 are represented as located within 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 the second communication protocol. The portable devices 102 and 104 communicate with the access device 106, which in turn communicates with the remote computer 108 over the communication network 120. In particular, access device 106 can serve as an interpretive relay that allows a portable device (eg, portable device 102 or portable device 104) to exchange transaction information with remote computer 108 during a transaction.

[0042] In one example, users 112-114 may be consumers trying to buy something in a physical store; portable device 102 may be a newer type of credit card carried by user 112; portable device 104 may be an older type of credit card carried by user 114; access device 106 may be a card reader located in a store building; the communication network may be the Internet; remote computer 108 may provide PA in the cloud. In this example, user 112 may use portable device 102 to conduct a first transaction with access device 106 and remote computer 108, while user 114 may use portable device 104 to conduct a second transaction with access device 106 and remote computer 108.

[0043] When a transaction is initiated between portable device 102 and access device 106, portable device 102 and remote computer 108 may attempt to exchange transaction information. In some embodiments, the PA in the cloud may attempt to obtain checking account details from the portable device 102, while the portable device 102 may attempt to obtain transaction data (e.g., terminal transaction credentials, preferred language, transaction currency code, etc.) from the PA in the cloud. .). In order to free the remote computer 108 from having to deal with other communication protocols other than the first communication protocol, in embodiments, the access device 106 may be adapted to serve as a communication transformation or abstraction module, where the access device 106 intercepts, browses, converts and/or filters messages between the remote computer 108 and any portable device that attempts to complete a transaction with the remote computer 108.

[0044] Communication protocols between access device 106 and portable device 102 may depend on their respective functionality (e.g., what common protocol do they have, e.g., contact, contactless, NFC, Bluetooth, Wi-Fi, QR codes, etc.). d.). In embodiments, the access device 106 may be adapted to serve as a communication transform or abstraction module that protects the remote computer 108 from having to support multiple communication protocols, with one transform/abstract module for each type of portable device 102.

[0045] In particular, the access device 106 may be configured to communicate using different communication protocols (eg, both the first communication protocol and the second communication protocol). When receiving messages from the portable device over 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 messages to be compatible with the remote computer 108 (e.g., the first communication protocol) , and send converted messages. Similarly, when receiving messages from the remote computer 108, the access device 106 may convert the messages to a communication protocol that is incompatible with the remote computer 108 before sending the converted message to the portable device.

[0046] Returning to the above example, the user 114 may initiate a contact transaction by inserting the portable device 104 into the access device 106 such that first communication protocol messaging can occur between the portable device 104 and the access device 106. Since the exchange of messages between the portable device 104 and the access device 106 takes place over the second communication protocol, the access device 106 can convert the messages received from the portable device 104 to the first communication protocol and transmit the converted messages to the remote computer 108. The remote computer 108 can generate responses to converted messages and sends these responses in the form of messages according to the first communication protocol to the access device 106 . In response, access device 106 may convert messages received from remote computer 108 to a second communication protocol and transmit the converted messages to portable device 104.

[0047] At another point in time, the user 112 may initiate a contactless transaction by holding the portable device 102 close to the access device 106 such that first communication protocol messaging between the portable device 102 and the access device 106 can occur over NFC. In this case, access device 106 may determine that portable device 102 and remote computer 108 are using compatible communication protocols (eg, both are using the same communication protocol). Thus, since the exchange of messages between portable device 102 and access device 106 occurs over the first communication protocol, access device 106 can direct messages received from portable device 102 to remote computer 108 without performing conversion. Similarly, when messages are received from remote computer 108, access device 106 may direct messages to portable device 102 without performing conversion. In some embodiments, access device 106 may package messages exchanged between portable device 102 and remote computer 108.

[0048] In some embodiments, the first communication protocol may conform to the second generation Europay Master Visa (EMV) standard (EMV 2.0), while the second communication protocol may conform to the first generation EMV standard (EMV 1.0). Each EMV standard is associated with a number of payment schemes. Each payment scheme in EMV 1.0 defines its own payment processing module, where each module includes the functions, logic, or data used to process contact or contactless transactions performed using the associated payment scheme. When processing a transaction, the POS terminal will need to determine which payment processing module to use and then send to this module an exchange of commands with a portable device (whereby the commands are sent via messaging, and the commands contain data). EMV 1.0 may be a stateful communication protocol. In other words, EMV 1.0 payment processing modules can expect the exchange of commands to occur in a specific sequence.

[0049] EMV 2.0 may be a stateless data-based communication protocol that can be associated with a single processing module that can process different schemes. However, typically a POS terminal that is capable of processing EMV 2.0 transactions may not be able to process EMV 1.0 transactions. Instead of a merchant using a first POS terminal for EMV 1.0 transactions and a second POS terminal for EMV 2.0 transactions, some embodiments may allow the merchant to use a single physical card reader (i.e., access device 106) that is configured to process any payment scheme associated with the EMV 1.0 communication protocol or the EMV 2.0 communication protocol. The card reader may be communicatively connected to a PA in the cloud (ie, remote computer 108) that processes payments over one communication protocol (eg, the first communication protocol).

[0050] Thus, in response to initiating a credit/debit card transaction, the card reader may be responsible for identifying the communications protocol (e.g., EMV 1.0 or EMV 2.0), payment scheme, and/or payment processing module to be used based on credit card. If the identified communication protocol, payment scheme, or processing module is incompatible with Cloud PA, the card reader will translate or convert messages from the card to a format that is compatible with Cloud PA. At the same time, the PA in the cloud can be responsible for processing the payment based on the converted/translated messages. In this respect, the card reader may be referred to as a thin client. The resulting separation of concerns can lead to many modular components (eg, thin client and PA in the cloud) containing software that is generally less complex than (1) the software of a single component (eg, a single local POS terminal, where a local POS is an entire PA system that is entirely contained within a physical store) that is capable of processing payments using any communication protocol, or (2) multiple local POS software (e.g., the first POS to process EMV 1.0 transactions and a second POS terminal for processing EMV 2.0 transactions).

[0051] In some embodiments, EMV 2.0 may be based on REST or JSON. For example, messages conforming to EMV 2.0 may be formatted according to XML or JSON, and such messages may be transmitted and/or received from a REST interface.

[0052] In general, updates to payment processing logic may be more common than updates to communication protocols. Accordingly, moving payment processing software from on-premises POS to PAs in the cloud can make it easier to update the payment processing logic, as the payment processing network operator will no longer need to update on-premises POS (for example, by physically accessing card readers to perform any updates).

[0053] Area 150 may correspond to a physical location of a resource provider (eg, a physical store) where portable devices 102-104 are placed in close proximity (eg, several inches or feet) to access device 106 to perform transactions. However, the circuit shown in Fig. 1 is not intended to be limited. In other embodiments, for example, portable devices 102-104 may be located remotely from access device 106.

[0054] Access device 106 may correspond to one or more access devices located at the location of the resource provider. For example, access device 106 may be a physical card reader used to retrieve transaction information from credit cards or debit cards used by consumers in a store. The card reader may act as a thin client that is connected to the remote computer 108 via the Internet (eg, where the card reader is connected to the Internet (i.e., communications network 120) via a Wi-Fi connection or an Ethernet connection). In general, the access device 106 may provide a unified transaction interface that allows the remote computer 102 to conduct transactions with a wider range of portable devices. Compared to local PA systems, in some embodiments, PA functionality may be shared between two physically disconnected devices: access device 106 and remote computer 108. In particular, access device 106 may contain logic for communicating with portable devices over different communication protocols, managing state and/or flow (eg, for stateful communication protocols); and converting messages from one protocol to another. It should be noted that the state or flow of the stateful communication protocol may affect how information is transmitted using the stateful communication protocol. In particular, the state or flow of the stateful communication protocol may specify the number of commands to be sent, the sequence of commands, and what data is carried in which commands. Access device 106 is described in more detail below with respect to FIG. 3.

[0055] Remote computer 108, which may correspond to a cloud system or one or more server computer systems that are located remotely in relation to area 150, may contain logic for conducting transactions using portable devices (eg, payment processing logic). In some embodiments, remote computer 108 may include a payment processing module referred to as "PA in the cloud". In particular, the PA in the cloud may be a unified payment processing module configured to process transactions performed using one or more EMV 2.0 payment schemes. Remote computer 108 is described in more detail below with respect to FIG. 2.

[0056] Each of the portable devices 102-104 may be a portable device as described above, where the portable device 102 is adapted to carry out transactions using a first communication protocol, while the portable device 104 is adapted to carry out transactions using a second communication protocol. For example, portable device 102 may be a newer EMV 2.0 compliant credit card or debit card, while portable device 104 may be an older EMV 1.0 compliant credit or debit card.

[0057] Access device 106 and remote computer 108 may be communicatively connected to communication network 120. The communication network 120 may be of any type and may comprise one or more communication networks. Examples of communications network 120 include, without limitation, the Internet, a wide area network (WAN), a local area network (LAN), an Ethernet network, a public or private network, a wired network, a wireless network, and the like, and combinations thereof. . Various communication protocols may be used to facilitate the transmission of messages, including both wired and wireless protocols such as the IEEE 802.XX protocol suite, TCP/IP, IPX, SAN, AppleTalk, Bluetooth, and other protocols. In general, communications network 120 may include any communications network or infrastructure that facilitates the transfer of messages between computing devices.

[0058] FIG. 2 is a block diagram of a remote computer 108 including an exemplary server computer 202 according to the embodiments. Server computer 202 is depicted as containing a plurality of hardware and software modules (204-230). However, it should be understood that this is for illustrative purposes only and each of the modules and related functionality may be provided and/or performed by the same or different components. That is, server computer 202 may perform some of the relevant functions and steps described herein with reference to remote computer 108 through the use of any suitable combination of software instructions and/or hardware configurations. It should be noted that although in FIG. 2 (and in another system described herein) shows that all modules are located on the same device, the present invention is not intended to be limited to this. In addition, a system for implementing the functionality described herein may have additional components or less than all of these components. Additionally, some modules may be located on other devices, such as a remote server or other local devices, operatively associated with the component(s) of the server computer. In some cases, program modules may be located in a virtual machine or in a container.

[0059] The server computer 202 is shown as including a processor 204, system memory 206 (which may include any combination of volatile and/or non-volatile memory such as, for example, buffer memory, RAM, DRAM, ROM, flash memory, or any other suitable device memory) and an external communication interface 208. In addition, one or more modules 210-220 may be located in one or more components of the system memory 206 or may be located outside. As noted above, the software and hardware modules shown in FIG. 2 (and other systems described in this document) are provided for illustrative purposes only and the configurations are not intended to be limiting. Processor 204, system memory 206, and/or external communications interface 208 may be used in conjunction with any of the modules described below to provide the desired functionality. Some illustrative modules and related functionality may be as follows:

[0060] Communications module 210 may be adapted or programmed to perform some or all of the functions associated with receiving, sending, and generating electronic messages for transmission on remote computer 108 to any of the entities shown in FIG. 2, or from them. When an email is received by the server computer 202 via the external communication interface 208, it may be transmitted to the communication module 210. The communication module 210 may identify and parse the appropriate data based on the particular messaging protocol used on the remote computer 108. The communication module 210 may then transmit any received information to the appropriate module within the server computer 202 (eg, via data bus line 248). The communication module 210 may also receive information from one or more modules in the server computer 202 and generate an electronic message in an appropriate data format according to the transmission protocol used in the remote computer 108, such that the message can be sent to one or more entities in the system 100 ( for example, to the access device 106). The email may then be transmitted to the external communication interface 208 for transmission.

[0061] The communication manager 228 may be programmed and/or adapted to perform functions related to (1) preparing and managing the 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 requests for portable device data objects by populating a message sent to the access device with the appropriate data objects received from the transaction processing module.

[0062] In particular, the transaction processing module may inform the communication manager 228 of the statuses of its data requests. If the transaction processing module needs data from a portable device, the data transfer manager's list may contain appropriate data identifiers. Otherwise, the data transfer manager list may be empty. At this time, the portable device may inform the data manager 228 of the status of its data requests. If the portable device is requesting data from a remote computer, the portable device list may contain the corresponding data identifiers. If the portable device does not have an urgent data request, the portable device list may be empty. Additionally, the portable device may provide the data objects requested by the data manager.

[0063] The communications manager may synchronize communication between the portable device and the remote computer 108 to optimize performance and minimize the number of messages exchanged with the portable device. Additionally, the data manager may request the secure channel manager 230 to send secure messages to the portable device. When the communication channel with the portable device is established, the portable device and/or the transaction processing module can inform the communication manager 228 of its security level preferences, thereby instructing the communication manager 228 to interact with the secure channel manager 230 accordingly.

[0064] The secure channel manager 230 may be programmed and/or adapted to perform functions related to securing communication with the portable device in a manner that is transparent to the communication manager 228 and the transaction processing module.

[0065] FIG. 3 is a block diagram of an access device 106 including an exemplary computer 302 according to embodiments. Computer 302 is depicted as containing a plurality of hardware and software modules (304-314). However, it should be understood that this is for illustrative purposes only and each of the modules and related functionality may be provided and/or performed by the same or different components. That is, computer 302 may, for example, perform some of the relevant functions and steps described herein with reference to access device 106 through the use of any suitable combination of software instructions and/or hardware configurations.

[0066] Computer 302 is shown as including a processor 304, system memory 306, and an external communication interface 308. Moreover, one or more modules 310-314 may be located in one or more components of the system memory 306 or may be located outside. Processor 304, system memory 306, and/or external communications interface 308 may be used in conjunction with any of the modules described below to provide the desired functionality. Some illustrative modules and related functionality may be as follows.

[0067] The communication module 310 may be adapted or programmed to perform some or all of the functions associated with receiving, sending, and generating electronic messages for transmission on the access device 106 to any of the entities shown in FIG. 3, or from them. When an electronic message is received by the computer 302 via the external communication interface 308, it may be transmitted to the communication module 310. The communication module 310 can identify and parse the relevant data based on the particular messaging protocol used on the access device 106 . Communications module 310 may then transmit any received information to an appropriate module within computer 302 (eg, via data bus line 328). The communication module 310 may also receive information from one or more modules in the computer 302 and generate an electronic message in an appropriate data format according to the transmission protocol used on the access device 106 so that the message can be sent to one or more entities in the system 100 (for example, , to a remote computer 108). The email may then be transmitted to the external communication interface 308 for transmission.

[0068] Communications module 310 may be adapted or programmed to perform some or all of the functions associated with communicating with portable devices. In particular, communication module 310 may be responsible for (1) establishing, maintaining, and terminating a session with a portable device, (2) enabling messaging within a given session, and (3) allowing multiple sessions to co-exist. Protocol conversion module 312 may be adapted or programmed to perform some or all of the functions associated with converting messages transmitted between portable devices and remote computer 108 from one communication protocol (eg, a first communication protocol) to another (eg, a second communication protocol). Protocol conversion module 312 may be responsible for determining which communication protocol (eg, EMV 1.0 or EMV 2.0) is adapted to use a particular device. Based on this determination, the protocol mapping module 312 can translate the messages exchanged for the transaction if there was a request. For example, a message originating from portable device 104 may be received by communication module 310. Based on the determination that the portable device 104 uses the second communication protocol while the remote computer 108 uses the first communication protocol, the protocol conversion module can convert messages from the second communication protocol to the first communication protocol before forwarding the converted messages to the remote computer 108.

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

[0070] To this end, the protocol conversion module 312 can be adapted or programmed to (1) create, format and exchange the necessary number of messages within a given session to fulfill as many requests for data from a remote computer as possible and (2) create, format and produce exchanging the necessary number of messages within a given session to fulfill as many data requests from the portable device as possible.

[0071] Data conversion module 314 may be adapted or programmed to perform some or all of the functions associated with converting data transmitted between portable devices and remote computer 108 from one data format (eg, associated with the first communication protocol) to another (eg, format associated with the second communication protocol). The data conversion module 314 may be responsible for determining which communication protocol (eg, EMV 1.0 or EMV 2.0) is adapted to use a particular portable device. Based on this determination, the data conversion module 314 can perform the conversion of the data exchanged for the transaction if there was a request. For example, a message originating from portable device 104 may be received by communication module 310. Based on the determination that the portable device 104 uses the second communication protocol while the remote computer 108 uses the first communication protocol, the data conversion module can convert the data format associated with the second communication protocol to a format suitable for the first communication protocol before sending the converted data to a remote computer 108.

IMPLEMENTATION OF TRANSACTIONS ON A UNIFIED TRANSACTION INTERFACE

[0072] FIG. 4 is a flowchart showing an exemplary method for conducting access transactions using various communication protocols, in accordance with some embodiments.

[0073] At step 402, the access device receives an indication that it is necessary to perform a transaction between the portable device and a remote computer, where the remote computer is configured to communicate using the first communication protocol. The hint can be generated from a variety of inputs, including: inserting a handheld device into an interface provided by an access device (e.g., inserting a PIN card into a card reader), touching a handheld device to an interface (e.g., touching a mobile phone to a reader) , swiping the portable device through the interface (eg, swiping a credit card through a slot provided by a card reader), connecting the portable device to an access device, scanning with the portable device interface, or optically reading the portable device with the interface/access device.

[0074] In some embodiments, the first communication protocol may define a first set of messages (e.g., selecting a first application on a card, providing a first set of data to a card, and requesting a second set of data from a card) that an access device is adapted to exchange with a particular set of portable devices, which are adapted to communicate using the first communication protocol. For example, the first communication protocol may be in accordance with EMV 2.0, and a particular set of portable devices that are capable of communicating using the first communication protocol may be in accordance with newer types of credit cards. In some embodiments, communication may include application layer communication and transport layer communication, where application layer communication defines data objects and data flows, while transport layer communication defines message formats (e.g., TCP/IP, Bluetooth, ISO 7816), independent of data. that are being exchanged.

[0075] The first communication protocol may further define a second set of messages that the access device is adapted to exchange with the remote computer; a fourth set of messages (eg, a first transaction processing thread) that the remote computer is configured to exchange with the access device; and a fifth set of messages that the access device is adapted to exchange with portable devices that are adapted to communicate using the first communication protocol.

[0076] In embodiments where the access device serves as a simple relay, when both the portable device and the remote computer use the same communication protocol, the first set of messages and the second set of messages may be the same. However, in some embodiments, the access device may perform transformations on messages to optimize performance and minimize the number of messages exchanged with the remote computer (for example, packing messages into an object or packing interface) and/or to adapt to specific transport protocols (for example , TCP/IP, Bluetooth, ISO 7816), even when the portable device and the remote computer use the same communication protocol. In such embodiments, the first set of messages may be different from the second set of messages.

[0077] At decision block 404, the access device determines whether the portable device is capable of communicating using the first communication protocol or the second communication protocol. In some cases, the first communication protocol is a stateless protocol, while the second communication protocol is a stateful protocol. In some embodiments, the access device may transmit the first message to the portable device, where the first message corresponds to the first communication protocol. If the portable device provides a response that matches the first communication protocol, then 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 incorrect response or no response, the access device may determine that the portable device is capable of communicating using the second communication protocol, and the method proceeds to step 408.

[0078] In some embodiments, the second communication protocol may define a third set of messages (eg, select a second application on the card, provide a third set of data to the card, and request a fourth set of data from the card) that the access device is adapted to receive from a particular set of portable devices, which are adapted to communicate using the second communication protocol. For example, the second communication protocol may be in accordance with EMV 1.0, and a particular set of portable devices that are capable of communicating using the second communication protocol may be in accordance with older type credit cards. The second communication protocol may further define a sixth set of messages (eg, a second transaction flow) that the access device is adapted to exchange with portable devices that are adapted to communicate using the second communication protocol.

In general, message sets can contain messages for requesting data, messages for checking data, messages for sending data.

[0079] In step 406, after determining that both the portable device and the remote computer are using the first communication protocol, the access device assists the portable device and the remote computer in exchanging transaction information using the first communication protocol and without using the second communication protocol. In this regard, the access device may exchange the first set of messages with the portable device and, based on the first set of messages, transmit the second set of messages to the remote computer. The access device may also receive the fourth set of messages from the remote computer and, based on the fourth set of messages, transmit the fifth set of messages to the portable device. In some embodiments, the access device may relay messages between the portable device and the remote computer without performing any conversions. In other embodiments, the access device may perform message translations between the portable device and the remote computer.

[0080] At 408, after determining that the portable device and the remote computer are using different communication protocols, the access device assists the portable device and the remote computer in exchanging transaction information by converting one or more messages between the portable device and the remote computer from the first communication protocol to the second communication protocol or from the second communication protocol to the first communication protocol. In particular, the access device may receive the third set of messages from the portable device and, based on the third set of messages, transmit the second set of messages to the remote computer. Additionally, the access device may receive a fourth set of messages from the remote computer and, based on the fourth set of messages, transmit a sixth set of messages to the portable device.

[0081] 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 sending authorization request messages to the acquirer and/or issuer.

[0082] FIG. 5-6 is a sequence diagram showing operations for conducting transactions using different communication protocols, in accordance with some embodiments. In FIG. 5 shows a transaction between a remote computer configured to use the first communication protocol and a portable device 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. It should be noted that in some embodiments, remote computer 502, access device 504, and portable device 506 may be similar to remote computer 108, access device 106, and portable device 102. respectively.

[0083] At block 520, the access device 504 receives a message from the remote computer 502 to begin selecting an application with which to transact. In some embodiments, the access device 504 may have already sent an indication that a transaction needs to be made between the remote computer 502 and the portable device 506. The indication may have been caused by physical interaction between the portable device 506 and the access device 504 (e.g., by swiping a credit card through the device). card swiping). At this point, the remote computer (ie, the PA in the cloud) can determine which applications are available on the portable device 506 to perform a transaction with them.

[0084] At step 522, the access device 504 forwards the message from step 520 to the portable device 506 in the form of a "select EMV" command. If the portable device fails to correctly respond to this command or rejects this command, the access device 504 may determine that the portable device is using the second communication protocol and not the first communication protocol, and may begin to communicate with the portable device 506 using the second communication protocol, as discussed in more detail with respect to FIG. 6 below.

[0085] At step 524, since the portable device 506 is using EMV 2.0, the access device 504 may receive a confirmation message that the portable device 506 is using the first communication protocol. In some embodiments, the portable device response may also include a request for server data from the remote computer 502.

[0086] At step 526, the access device 504 sends an acknowledgment that the portable device is using the first communication protocol to the remote computer 502, along with any possible requests for POS data from the portable device 506.

[0087] Steps 552-558 describe the sequence of transaction information exchanges between the remote computer 502 and the portable device 506 that the access device 504 assists with. To conduct a transaction, remote computer 502 and portable device 506 may attempt to obtain transaction information from each other. For example, the portable device 506 may want to know what type of card verification methods are supported by the remote computer 502. In doing so, the remote computer may want to obtain a primary account number (PAN), expiration date, country code, and other account information associated with the portable device. 506.

[0088] Because EMV 2.0 is a data-based communication protocol, different combinations of card data or POS data can be requested or provided in a single message. In particular, a single message can either request data or provide data in response to an earlier request. For example, a message from remote computer 502 to portable device 506 may contain both a request for card data and POS data that responds to a POS data request made by portable device 506. This ability to mix and match data and data requests in a single message can reduce the total number of messages being exchanged, which can increase the speed and reduce the complexity of transaction processing. It should be noted that steps 552-558 may be repeated many times depending on the transaction information to be exchanged.

[0089] At 552, access device 504 may receive from remote computer 502 a message that requests card data from portable device 506. The message may further comprise POS data. In some embodiments, the remote computer 502 provides the POS data that was requested by the portable device 506 at step 524. In some embodiments, the remote computer 502 provides to the access device 504 all POS data that is available at this step, regardless of the portable device data requests.

[0090] 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, the device 504 access can only provide a set of POS data that was requested by the portable device in the previous message.

[0091] At step 556, the access device 504 may receive another message from the portable device 506 containing the card data requested in the previous step. In some embodiments, portable device 506 may only provide the set of map data that was requested in the previous step.

[0092] At 556, the access device 504 may receive a message from the portable device 506 that requests POS data. In some embodiments, the portable device 506 packages the POS data request in a list of data objects requested from the remote computer 502.

[0093] At 558, access device 504 may send card data and POS data requests to remote computer 502. In some embodiments, access device 504 may have already received in a previous message from remote computer 502 the POS data requested by portable device 506, and may have the ability to provide them without additional communication with the remote computer 502. In some embodiments, the access device 504 may send data requests from the portable device 502 to the remote computer 502 only for POS data that it has not yet received.

[0094] FIG. 6 shows a transaction between a remote computer configured to use a first communication protocol (eg, EMV 2.0) and a portable device adapted to use a second communication protocol (eg, 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. respectively.

[0095] At step 620, the access device 604 receives a message from the remote computer 602 to start selecting an application with which to perform a transaction. At this point, the remote computer can determine which applications are available on the portable device 606 to perform a transaction with them.

[0096] At step 622, the access device 604 may convert the message from step 620 to the portable device 606 and send a "select EMV1.0" command to the portable device. In some embodiments, access device 604 may send a "select EMV2.0" command to portable device 606 in an attempt to communicate with portable device 606 using a first communication protocol (eg, EMV 2.0). However, since portable device 606 rejected the Select EMV2.0 command or responded incorrectly, access device 604 could revert back to communicating with portable device 606 using a second communication protocol (eg, EMV 1.0).

[0097] At 624, portable device 606 may respond to access device 604 that it is using a second communication protocol (eg, 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 requests may be implicit in the second communication protocol and be explicitly created by the access device 604.

[0098] At 626, access device 604 may send a message to remote computer 602 over a first communication protocol indicating that portable device 606 is using a second communication protocol (eg, EMV 1.0) and may have some requests for POS data. However, the fact that portable device 606 does not support the first communication protocol cannot change the behavior of remote computer 602. Instead, remote computer 602 can rely on access device 604 to insulate remote computer 602 from any differences between the first and second communication protocols.

[0099] Similar to steps 552-558 in FIG. 5, steps 648-656 describe the flow of transaction information exchanges between remote computer 602 and portable device 606 that access device 604 assists. Although the transaction information exchanged here may have similarities to the transaction information exchanged in FIG. 5, the formats in which the transaction information is transmitted may vary. In particular, remote computer 602 may request card data and provide POS data in a manner that complies with EMV 2.0, while portable device 606 may request POS data and provide card data in a manner that complies with EMV 1.0. In this regard, the access device 604 can map EMV 2.0 messages to EMV 1.0 messages and map EMV 1.0 messages to EMV 1.0 messages.

[0100] At 648, access device 604 may receive from remote computer 602 a message that requests card data requested from portable device 606. The message may further include some POS data. In some embodiments, the remote computer 602 provides the POS data that was requested by the portable device 606 at step 624. In some embodiments, the remote computer 602 provides to the access device 604 all POS data that is available at this step, regardless of the portable device data requests.

[0101] At 660, access device 604 may convert a message received over a first communication protocol (eg, EMV 2.0) from remote computer 602 at 648 into a message over a second communication protocol (eg, EMV 1.0). In some embodiments, access device 604 may convert all POS data provided by remote computer 602 and all card data requests requested by remote computer 602. In some embodiments, access device 604 may only convert a subset of card data requested by remote computer 602, and only a subset of received POS data that satisfies a second communication protocol (eg, EMV 1.0). The access device 604 may then transmit the EMV 1.0 message to the portable device 606.

[0102] At 662, access device 604 may receive a second communication protocol (eg, EMV 1.0) message from portable device 606, where the message contains 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 requests for portable device POS data may be implicit and explicitly created by the access device 604.

[0103] In step 664, the access device 604 may convert the message received over the second communication protocol (eg, EMV 1.0), retrieve the card data provided by the portable device 606 in step 662, and convert the card data into a message over the first communication protocol (eg, EMV 2.0 ). In some embodiments, the access device 604 may not receive all of the card data requested by the remote computer 602 in a single message and may continue to exchange messages with the portable device 606 until all of the card data requested by the remote computer 602 has been received.

[0104] In some embodiments, the portable device's response may also include a request for certain POS data from the remote computer 602. In some embodiments, the requests for portable device POS data may be implicit and explicitly created by the access device 604.

[0105] At 666, access device 604 may send card data and POS data requests to remote computer 602. In some embodiments, access device 604 may have already received the requested POS data in a previous message from remote computer 602 and may be able to provide it without exchanging additional messages with remote computer 602. In some embodiments, access device 604 may only send data requests to remote computer 602 for POS data that it has not yet received.

[0106] The various participants and elements described herein with reference to FIG. 1-6 may use one or more computing devices to provide the functions described herein. Any of the elements shown in Fig. 1-6, including any servers or databases, may use any suitable number of subsystems to provide the functionality described in this document.

[0107] In FIG. 5-6, after communication between the remote computers 502, 602 and the portable device 506, 606, an authorization request message may be generated by the remote computers 502, 602. An "Authorization request message" may be an electronic message that is sent to the payment processing network and /or the issuer of the payment card for the purpose of requesting transaction authorization. The authorization request message, in some embodiments, may conform to ISO 8583, which is a standard for systems that exchange electronic transaction information associated with a payment made by a consumer using a payment device or checking account. The authorization request message may contain an issuer account identifier, which may be associated with a payment device or settlement account. The authorization request message may also contain additional data elements corresponding to "identity information", including, by way of example only: service code, CVV (card authentication code), dCVV (dynamic card authentication code), expiration date, etc. e. The authorization request message may also contain "transaction information", such as any information related to the current transaction, such as transaction amount, merchant ID, merchant location, etc., as well as any other information that may be used in determining whether a transaction should be identified and/or authorized.

[0108] The authorization request message may be transmitted to the issuer's computer via the acquirer's computer and the payment processing network. The issuer's computer may approve or reject the transaction and may generate an authorization response message. The “Authorization Response Message” may be an electronic response to an authorization request message generated by the issuing financial institution or payment processing network. The authorization response message may contain, by way of example only, one or more of the following status indicators: "approval" - the transaction has been approved; "rejection" - the transaction was not approved; or "call center" is a response that requires more information, and the seller must call a toll-free phone number for authorization. The authorization response message may also contain an authorization code, which may be a code that the credit card issuing bank returns in response to an authorization request message in an email (either directly or through a payment processing network) to a merchant's access device ( e.g. , POS-equipment), which indicates the approval of the transaction. The code can serve as confirmation of authorization. As noted 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 sent back to the remote computers 502, 602 via the payment processing network and the acquirer computer. The remote computers 502 may optionally send an authorization response message back to the access device.

[0109] Examples of such subsystems or components are interconnected via a system bus. Additional subsystems are shown, such as a printer, a keyboard, a fixed disk (or other storage device containing machine-readable media), a monitor that is connected to a display adapter, and others. Peripherals and input/output (I/O) devices that are connected to an I/O controller (which may be a processor or other suitable controller) may be connected to the computer system by any number of means known in the art, such as like a serial port. For example, a serial port or external interface may be used to connect the computing device to a wide area network such as the Internet, a mouse input device, or a scanner. A system bus connection allows the CPU to communicate with each subsystem and control the execution of commands from system memory or a fixed disk, as well as the exchange of information between subsystems. The system memory and/or the fixed disk may be a computer readable medium.

[0110] In addition, although the present invention has been described in terms of a specific combination of hardware and software in the form of control logic and program code and instructions, it should be understood that other combinations of hardware and software are also within the scope of the present invention. The present invention may be implemented in hardware only, or in software only, or combinations thereof.

[0111] Any of the software components or functions described herein may be implemented as program code to be executed by a processor using any suitable computer language such as, for example, Java, C++, or Perl, using, for example, traditional or object-oriented approaches. The program code may be stored as a sequence of instructions or instructions on a computer readable medium such as random access memory (RAM), read only memory (ROM), magnetic media such as a hard disk or floppy disk, or optical media such as a CD-ROM. ROM. Any such computer-readable medium may reside on or within a single computing device and may be present on or within different computing devices within a system or network.

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

[0113] Any of the methods described herein may be wholly or partially performed by a computer system containing one or more processors that can be adapted to perform the steps. Thus, embodiments may relate to computer systems adapted to perform the steps of any of the methods described herein, potentially with different components performing the respective steps or the respective group of steps. Although the steps are presented numbered, the steps of the methods herein may be performed simultaneously or in a different order. In addition, portions of these steps may be used with portions of other steps from other methods. Also, the entire step or parts of it may be optional. In addition, any of the steps of any of the methods may be performed by modules, blocks, circuits, or other means to perform these steps.

[0114] One or more features from any embodiment can be combined with one or more features from any other embodiment without departing from the scope of the present invention.

[0115] Singular forms mean "one or more" unless otherwise noted separately.

[0116] All patents, patent applications, publications and descriptions mentioned above are incorporated herein by reference in their entirety for all purposes. None of these documents is accepted as a prototype.

Claims (90)

1. A method for conducting transactions, through an access device, between a remote computer operating in a cloud computing environment and a portable device, comprising the steps of: receiving, by means of the access device, from a portable device in the vicinity of the access 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 perform point-of-sale terminal processing and communicate using the first communication protocol , the portable device and the remote computer are configured to request data from each other through the access device, the access device provides a unified interface that allows the remote computer to transact with a number of portable devices that use a number of appropriate communication protocols; determine by the access device that the portable device is configured to communicate using the second communication protocol; converting, by means of the access device, the card data request received from the remote computer from the first communication protocol to the second communication protocol; transmitting, by means of the access device, a converted request for card data to the portable device; converting, by means of the access device, the card data received from the portable device from the second communication protocol to the first communication protocol; and transfer the converted card data to the remote computer, wherein the remote computer generates and transmits an authorization request message for the transaction to the resource provider computer based in part on receiving the converted card data. 2. The method according to claim 1, in which the first communication protocol defines: a first set of transmissions that the access device is configured to receive from a first plurality of portable devices configured to communicate using the first communication protocol, and a second set of transmissions that the access device is configured to transmit to the remote computer; wherein the second communication protocol defines a third set of transmissions that the access device is configured to receive from a second plurality of portable devices configured to communicate using the second communication protocol; and wherein the conversion of transmissions between the portable device and the remote computer from the second communication protocol to the first communication protocol comprises receiving a third set of transmissions from the portable device and transmitting, based on the third transmission set, the second set of transmissions to the remote computer. 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 wherein the method further comprises the steps of: receiving from the second portable device or the remote computer another indication that a second transaction needs to be performed by exchanging second transaction information between the second portable device and the remote computer, the second portable device and the remote computer are configured to request the second data from each other via the access device; determining that the second portable device is configured to communicate using the first communication protocol; and assisting the remote computer in requesting the second card data from the second portable device via the access device; and facilitating the second portable device to transmit the second card data to the remote computer through the access device, wherein receiving the second card data causes the remote computer to generate and transmit a second authorization request message for the second transaction to the second resource provider computer. 4. The method of claim 3, wherein said facilitating the second portable device and the remote computer uses a first communication protocol rather than a second communication protocol, and wherein said facilitating the portable device comprises receiving a first set of transmissions from the portable device and transmitting based on the first set of transfers, the second set of transfers to the remote computer. 5. The method according to claim 2, in which the first communication protocol further defines: a fourth set of transmissions that the remote computer is configured to transmit to the access device, and a fifth set of transmissions that the access device is configured to transmit to a first plurality of portable devices configured to communicate using the first communication protocol; wherein the second communication protocol further defines a sixth set of transmissions that the access device is configured to transmit to a second plurality of portable devices configured to communicate using the second communication protocol; and wherein converting transmissions between the portable device and the remote computer from the second communication protocol to the first communication protocol further comprises receiving a fourth set of transmissions from the remote computer and transmitting, based on the fourth set of transmissions, a sixth set of transmissions to the portable device. 6. The method of claim 5, wherein the first set of gears, the second set of gears, the fourth set of gears, and the fifth set of gears are in XML or JSON format. 7. The method of claim 5, wherein the first set of gears and the fifth set of gears are in XML or JSON or ISO 7816 format, while the second set of gears and the fourth gear set 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, and the access device functions as a thin client. 9. The method of claim 1, wherein said indication is received from the portable device when the portable device: inserted into the interface provided in the access device; applied to this interface; interfaces with the access device; scanned through said interface; or read optically. 10. The method of claim 1 further comprising converting other communications between the one or more other portable devices and the remote computer from the one or more other communication protocols to a first communication protocol to facilitate the one or more other portable devices and the remote computer in the exchange of information of another transaction. 11. The method of claim 1, further comprising the steps of: receiving, via the access device, from the remote computer a command to start selecting an application; converting, by means of the access device, a command to start selecting an application from the first communication protocol to the second communication protocol; transmitting, by means of the access device, a converted command to start application selection to the portable device; receiving, by means of the access device, a response message from the portable device; converting, by means of the access device, a response message from the second communication protocol to the first communication protocol, the response message containing an indication of a request for server data; and transmitting the converted response message to the remote computer. 12. The method of claim 1, wherein the first communication protocol is a stateless protocol and the second communication protocol is a stateful protocol, and wherein the method further comprises maintaining, by means of the access device, a state associated with the second communication protocol, wherein the access device is configured to influence the sequence of message transmissions according to the stateful protocol and the state maintained in the access device. 13. Access device configured to provide transactions between a portable device and a remote computer operating in a cloud computing environment, while the access device contains: 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 perform operations to: providing a unified interface that allows a remote computer to conduct transactions with a number of portable devices that use a number of appropriate communication protocols; receiving from the portable device an indication that a transaction needs to be performed between the portable device and the remote computer, wherein the remote computer is configured to process the point of sale terminal and communicate using the first communication protocol, the portable device and the remote computer are configured to request data each other through a unified access device interface; determining that the portable device is configured to communicate using the second communication protocol; converting the card data request received from the remote computer from the first communication protocol to the second communication protocol; transmitting to the portable device the converted card data request; converting the card data received from the portable device from the second communication protocol to the first communication protocol; and transferring converted map data to a remote computer, wherein the remote computer generates and transmits an authorization request message for the transaction to the resource provider computer based in part on receiving the converted card data. 14. The access device according to claim 13, wherein the first communication protocol defines: a first set of transmissions that the access device is configured to receive from a first plurality of portable devices configured to communicate using the first communication protocol, and a second set of transmissions that the access device is configured to transmit to the remote computer; wherein the second communication protocol defines a third set of transmissions that the access device is configured to receive from a second plurality of portable devices configured to communicate using the second communication protocol; and wherein converting transmissions between the portable device and the remote computer from the second communication protocol to the first communication protocol comprises receiving a third transmission set from the portable device and transmitting, based on the third transmission set, the second transmission set to the remote computer. 15. The access device according to claim 14, wherein the transaction is the first transaction and the portable device is the first portable device; and while the instructions additionally instruct the processor to perform operations for: receiving another indication from the second portable device or the remote computer that a second transaction needs to be performed between the second portable device and the remote computer, the second portable device and the remote computer are configured to request the second data from each other via the access device; determining that the second portable device is configured to communicate using the first communication protocol; assisting the remote computer in requesting the second card data from the second portable device via the access device; and facilitating the second portable device to transmit the second card data to the remote computer via the access device, wherein the remote computer's receipt of the second card data causes the remote computer to generate and transmit a second authorization request message for the second transaction to the resource provider's second computer. 16. The access device of claim 15, wherein facilitating the second portable device and the remote computer uses a first communication protocol rather than a second communication protocol, and wherein said facilitating the portable device comprises receiving a first set of transmissions from the portable device and transmitting based on the first set of transmissions second set of transfers to the remote computer. 17. The access device according to claim 14, wherein the first communication protocol further defines: a fourth set of transmissions that the remote computer is configured to transmit to the access device, and a fifth set of transmissions that the access device is configured to transmit to a first plurality of portable devices configured to communicate using the first communication protocol; wherein the second communication protocol further defines a sixth set of transmissions that the access device is configured to transmit to a second plurality of portable devices configured to communicate using the second communication protocol; and wherein converting transmissions between the portable device and the remote computer from the second communication protocol to the first communication protocol further comprises receiving a fourth transmission set from the remote computer and transmitting, based on the fourth transmission set, the sixth transmission set to the portable device. 18. The access device of claim 13, wherein said indication is received from the portable device when the portable device: inserted into the interface provided in the access device; applied to this interface; interfaces with the access device; scanned through said interface; or read optically. 19. The access device of claim 13, wherein the access device functions as a thin client. 20. A portable device configured to conduct transactions, through an access device, with a remote computer operating in a cloud computing environment, while the portable device contains: 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 perform operations to: providing an indication to the access device that it is necessary to perform a transaction by exchanging transaction information between a portable device and a remote computer, while the access device provides a unified interface that allows the remote computer to conduct transactions with a number of portable devices that use a number of appropriate communication protocols, the remote computer is configured to process the point of sale terminal and communicate using the first communication protocol, and the portable device and the remote computer are configured to request data from each other via the access device, the portable device is further configured to communicate using the second communication protocol ; and exchanging transaction information with the remote computer through one or more requests transmitted through the access device, wherein the access device converts the first request between the portable device and the remote computer from the second communication protocol to the first communication protocol and the second request between the portable device and the remote computer from the first a communication protocol to a second communication protocol, and wherein exchanging transaction information causes the remote computer to generate and transmit an authorization request message for the transaction.

Images