Secure extended-range application data exchange

Abstract

An application data exchange technique can include a communication device establishing a communication channel with an access device, receiving an access device configuration file of the access device, and emulating a virtual access device on the communication device based on the access device configuration file. The virtual access device executing on the communication device can issue a set of application commands to a transaction applet executing on the communication device and receive a set of application data responses from the transaction applet in response to the set of application commands. The communication device can then generate a data packet by concatenating application data contained in the set of application data responses and transmit the data packet to the access device over the communication channel.

Description

[0001] This invention application is a divisional application of the invention patent application with international application number PCT / US2019 / 063251, international application date November 26, 2019, and Chinese national phase application number 201980079470.2, entitled "Application Data Exchange with Secure Extended Distance".

[0002] Cross-referencing related applications

[0003] This application claims priority to U.S. Non-Provisional Application No. 16 / 211,771, filed December 6, 2018, the contents of which are incorporated herein by reference in their entirety for all purposes. Background Technology

[0004] Near Field Communication (NFC) is a wireless communication technology that allows for data exchange at close range. Because NFC requires devices to be placed within a few inches of each other, NFC data exchange is quite secure and cannot be intercepted by a perpetrator at a distance. NFC's close-range requirement also means it is unlikely to suffer interference from objects along the communication path. Therefore, a stable connection can be achieved as long as the devices remain close to each other, and data can be exchanged through a series of uninterrupted round trips. However, NFC has a limited communication range and can be inconvenient for users, for example, by requiring them to remove an NFC-enabled communication device from their pocket and place it next to an NFC-enabled reader.

[0005] The embodiments of the present invention individually and collectively address these and other problems. Summary of the Invention

[0006] According to some embodiments, a technique for application data exchange may include: a user's communication device establishing a communication channel with an access device, receiving an access device configuration file from the access device, and simulating a virtual access device on the communication device based on the access device configuration file. The virtual access device executing on the communication device can issue a set of application commands to a transaction applet executing on the communication device, and receive a set of application data responses from the transaction applet in response to the set of application commands. The communication device can then generate a data packet by concatenating the application data contained in the set of application data responses, and send the data packet to the access device through the communication channel.

[0007] According to some embodiments, a communication device may include a processor and a memory, the memory being coupled to the processor and storing code that can be executed by the processor to cause the communication device to perform the techniques described above for application data exchange. Attached Figure Description

[0008] Figure 1 A block diagram of a system for secure extended-distance application data exchange is shown according to some embodiments.

[0009] Figure 2 A communication flowchart of a user's communication device that transacts with an access device according to some embodiments is shown.

[0010] Figure 3 An example communication flowchart is shown between a transaction application running on the same communication device and a virtual access device, according to some embodiments.

[0011] Figure 4 A flowchart is shown illustrating a process performed by a communication device for exchanging application data with an access device, according to some embodiments.

[0012] Figure 5 A block diagram of a communication device according to some embodiments is shown. Detailed Implementation

[0013] Techniques for secure extended-range application data exchange are described. Extended-range application data exchange can be performed using longer-range wireless communication technologies, such as the Bluetooth protocol family including Bluetooth Low Energy (BLE). Compared to short-range implementations such as NFC, additional precautions are taken to ensure reliable and secure long-range data exchange. In some embodiments, devices communicating with each other can use digital certificates to authenticate each other and provide encryption for data exchange. To mitigate connection interruptions, the initiating device (e.g., a user's communication device) communicating with the target device (e.g., an access device) can locally emulate a virtual target device on the initiating device. The emulated virtual target device can interact locally with the initiating device, and application data, typically provided via a series of transmissions, can be locally cached on the initiating device and transmitted to the target device in a single or reduced number of transmissions.

[0014] Before discussing the details of the various embodiments, the following provides an explanation of the various terms.

[0015] A "wireless communication protocol" can refer to a specified technology that allows two or more devices to exchange data without requiring a physical wired connection between the devices. Wireless communication protocols can be standardized or proprietary. Examples of wireless communication protocols include Bluetooth, Bluetooth Low Energy (BLE), WiFi, WiFi Direct, Zigbee, Z-Wave, NFC, RFID, etc.

[0016] "Communication device" can refer to a device that includes one or more electronic components (e.g., integrated chips) that can communicate with another device or entity. For example, a communication device can be a computing device including at least one processor coupled to memory storing instructions or code for execution by a processor, and the communication device can include a communication interface such as a transceiver that allows the communication device to interact with other entities. A communication device can be a portable communication device that can be transported and operated by a user. A portable communication device can provide remote communication capabilities with a network. A portable communication device can be configured to send data or communications to and receive data or communications from other devices. A portable communication device can take the form of a mobile device such as a mobile phone (e.g., a smartphone, cellular phone, etc.), a tablet computer, a portable media player, a personal digital assistant device (PDA), a wearable device (e.g., a watch, bracelet, ring, glasses, a health monitoring device such as a fitness tracker, etc.), an electronic reader device, or in the form of a card (e.g., a smart card) or a pendant. Examples of portable communication devices also include portable computing devices (e.g., laptops, netbooks, ultrabooks, etc.). Portable communication devices may also take the form of vehicles (e.g., automobiles) or be integrated into vehicles (e.g., vehicle information systems). Other examples of communication devices may include Internet of Things (IoT) devices, smart devices and electronic devices, game consoles, etc. Communication devices may also include multiple devices or components (e.g., when a device can remotely access a network by being linked to another device—two devices together can be considered a communication device). Communication devices that can be communicatively coupled to each other within a network of devices may be referred to as "peer devices".

[0017] A "server computer" can include a powerful computer or cluster of computers. For example, a server computer can be a mainframe, a small computer cluster, or a group of servers operating like cells. In one instance, a server computer can be a database server coupled to a web server. A server computer can be coupled to a database and can include any hardware, software, other logic, or combination of the foregoing for serving requests from one or more client computers. A server computer can include one or more computing devices and can use any of a variety of computing architectures, arrangements, and compilations to serve requests from one or more client computers. In some embodiments, a server computer can be located remotely relative to a device communicating with the server computer, and the remote server computer can be referred to as a "cloud".

[0018] "Access device" can refer to a suitable device used to communicate with a resource provider. Access devices can generally be located in any suitable location, such as at the location of a service provider or merchant, or in a remote location (e.g., in the cloud). Examples of access devices can include point-of-sale (POS) devices, personal computers (PCs), tablet PCs, handheld dedicated readers, set-top boxes, electronic cash registers (ECRs), automated teller machines (ATMs), virtual cash registers (VCRs), kiosks, security systems, access systems, etc. Access devices can also be web servers, merchant computers, or transaction processing networks that can interact with a user's communication device. For example, a user's mobile device can also be used as an access device. Access devices can use any suitable contact or contactless operating mode to send or receive data using the communication device. Access devices can include a processor, computer-readable media, and a device reader. Device readers can include contact and / or contactless operating modes. For example, a card reader can include one or more radio frequency (RF) antennas, optical scanners, barcode readers, or magnetic stripe readers that interact with the communication device.

[0019] A "token" can be a substitute for sensitive information. A token can refer to information that can be transmitted or used in place of sensitive information. For example, a token can be a substitute for sensitive information such as an actual account identifier, and a token can be used to access an account in place of the actual account identifier. In a payment context, a payment token can be an identifier for a payment account and can act as a substitute for an actual account identifier (e.g., a master account number (PAN)). A token can include a string of alphanumeric characters that can be used as a substitute for the original account identifier. For example, the token "4900 0000 0000 0001" can be used in place of the master account number (PAN) "4147 0900 0000 1234". In some embodiments, the token can be "preserved format" and can have a numerical format consistent with account identifiers used in existing payment processing networks (e.g., the ISO 8583 Financial Transaction Message Format). In some embodiments, the token can be used in place of the PAN to initiate, authorize, process, or resolve payment transactions, or to represent the original document in other systems where the original document would typically be provided. In some embodiments, the token can be generated in a manner that prevents the reconstruction of the original sensitive information (e.g., the PAN) from being derived by algorithm or computation. For example, the token may include a random number, such that the PAN associated with the token cannot be derived from the token computationally. A lookup table can be used to associate the PAN with the corresponding token. In some embodiments, the token may be a non-payment token used as an alternative to other types of sensitive information.

[0020] "Issuer" typically refers to a commercial entity (e.g., a bank) that maintains a user's account (e.g., a financial account). The account may be registered in an application installed on the user's communication device, allowing the user to conduct transactions for that account through the communication device. "Merchant" typically refers to an entity that participates in transactions and can sell goods or services or provide access to goods or services. "Acquiring party" typically refers to a business entity (e.g., a commercial bank) that has a business relationship with a particular merchant or other entity. Some entities can perform both issuing and acquiring party functions. Some embodiments may cover such a single entity as an issuing-acquiring party.

[0021] An "access device" can be any suitable device for communicating with a merchant's computer or transaction processing network (e.g., a payment processing network) and for interacting with a consumer communication device. Access devices can typically be located anywhere suitable, such as at the merchant's location. Access devices can take any suitable form. Some examples of access devices include POS devices, cellular phones, PDAs, personal computers (PCs), tablets, handheld dedicated readers, set-top boxes, electronic cash registers (ECRs), automated teller machines (ATMs), virtual cash registers (VCRs), kiosks, security systems, access systems, websites, etc. Access devices can use any suitable contact or contactless operating mode to send or receive data from or associated with a consumer communication device. In some embodiments where the access device may include a point-of-sale (POS) terminal, any suitable POS terminal can be used, which may include a reader, a processor, and a computer-readable medium. 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 consumer communication device.

[0022] An "authorization request message" can be an electronic message sent to request authorization for a transaction. Authorization request messages can be sent to a payment processing network and / or the issuer of a payment card. According to some embodiments, authorization request messages may conform to ISO 8583, a standard for systems that exchange information related to electronic transactions associated with payments made by a user using a payment device or payment account. Authorization request messages may include information that can be used to identify an account. Authorization request messages may also include one or more additional data elements, such as a service code, expiration date, etc. Authorization request messages may also include transaction information, such as any information associated with the current transaction, such as the transaction amount, merchant identifier, merchant location, etc., and any other information that can be used to determine whether to identify and / or authorize the transaction. Authorization request messages may also include other information, such as information identifying the access device that generated the authorization request message, information about the location of the access device, etc.

[0023] An "authorization response message" can be an electronic message response to an authorization request message. The authorization response message can be generated by the issuing financial institution or a payment processing network. As an example only, the authorization response message may include one or more of the following status indicators: Approval - the transaction is approved; Rejection - the transaction is not approved; or Call Center - further information is pending, and the merchant must call the toll-free authorization number. The authorization response message may also include an authorization code, which can be a code indicating approval of the transaction that the credit card issuing bank sends back to the merchant's computer in response to the authorization request message in the electronic message (directly or via the payment processing network). The code can serve as proof of authorization. As described above, in some embodiments, the payment processing network may generate or forward authorization response messages to the merchant.

[0024] "Pre-provisioning" can include the process of providing data for use. For example, pre-provisioning can include providing, delivering, or enabling tokens and / or restricted use keys (LUKs) on a communication device. Pre-provisioning can be performed by an entity within or outside the transaction system. For example, in some embodiments, the issuer or transaction processing network can pre-provision tokens to mobile devices. Pre-provisioned tokens may have corresponding token data stored and maintained in a token vault or token registry. In some embodiments, the token vault or token registry can generate tokens that can later be pre-provisioned or delivered to a device. In some embodiments, the issuer can specify a token range from which token generation and pre-provisioning can occur. Furthermore, in some embodiments, the issuer can generate a token value and notify it to the token vault, providing token record information (e.g., token attributes) for storage in the token vault.

[0025] "User" can refer to an entity, such as a person, organization, or device or system associated with or operated by a person or organization that uses resources for a particular purpose. A user may have one or more accounts that can be used to access resources. A user may also be referred to as an account holder, consumer, subscriber, or cardholder, etc.

[0026] "Resources" can refer to services, projects, locations, data, information, or valuable items that help users achieve a purpose. Some resources may be restricted and may require users to have an account to access them. Examples of resources may include: software applications and related functions; online services, including cloud services; goods (virtual and / or physical objects) or services related to transactions; points, credits, and / or currencies that can be exchanged for other resources; electronic devices, such as servers, computers, mobile devices, gaming systems, etc.; transportation, such as vehicles or delivery services, such as the communication capabilities of wireless services; restricted areas; media content; etc.

[0027] "Account parameters" can refer to information associated with an account that can be used to conduct transactions on that account. Examples of account parameters may include information that can be used to identify a user's account (e.g., a real account identifier, a substitute account identifier, a token, etc.), data or information related to the account's state, one or more keys used to generate password information, data or information associated with one or more keys, etc. Account parameters can be semi-static or dynamic. Dynamic account parameters can be account parameters with a limited lifespan, which are no longer usable for transactions once they expire until they are replenished, refreshed, or updated. Dynamic account parameters can be replenished frequently during the account's lifetime. Semi-static account parameters can be account parameters with an extended lifetime than dynamic account parameters, which may not be replenished as frequently as dynamic account parameters, or may not be replenished at all during the account's lifetime. Examples of dynamic account parameters may include restricted-use keys, which can be used as encryption keys to generate transaction passwords. Examples of semi-static account parameters may include tokens as an alternative to the real account identifier.

[0028] A "key" can refer to a piece of information used in a cryptographic algorithm to transform input data into another representation. A cryptographic algorithm can be an encryption algorithm that transforms original data into an alternative representation, or a decryption algorithm that transforms encrypted information back into original data. Examples of cryptographic algorithms may include Triple Data Encryption Standard (TDES), Data Encryption Standard (DES), Advanced Encryption Standard (AES), etc. In some embodiments, the key may be a restricted-use key (LUK) subject to one or more restricted-use thresholds to limit the use of the LUK. Once the threshold is exceeded, the LUK becomes invalid, and further use of the LUK may require replenishment or updating of the LUK.

[0029] "Password" can refer to an encrypted representation of some information. The password can be used by the recipient, for example, by encrypting the underlying information using a valid key and comparing the result with the received password to determine whether the password generator has the correct key.

[0030] A "restricted usage threshold" can refer to a condition that limits the use of a piece of information. When basic conditions are met, the restricted usage threshold may be exceeded or exhausted. For example, a restricted usage threshold may include a lifetime, which indicates the amount of time a piece of information is valid. Once this amount of time has elapsed, the restricted usage threshold is exceeded or exhausted, and the information may become invalid and unusable. As another example, a restricted usage threshold may include the number of times a piece of information can be used. Once this number of times the information has been used is exceeded or exhausted, the restricted usage threshold is exceeded, and the information may become invalid and unusable.

[0031] The term “authentication” and its derivatives can refer to the process of verifying the credentials of endpoints (including but not limited to applications, people, devices, processes, and systems) to ensure that the endpoints are the objects they claim to be.

[0032] A "transaction processing network" can include a network of one or more devices capable of processing and routing transaction request and / or response messages. A transaction processing network can include a data processing subsystem and operations for supporting and delivering authorization services, exception handling services, transaction scoring services, and clearing and settlement services. An exemplary transaction processing network may include VisaNet. TM For example, VisaNet TM Such transaction processing networks can handle credit card transactions, debit card transactions, and other types of commercial transactions. Specifically, VisaNet... TM This may include the VIP system (Visa Integrated Payment System) for processing authorization requests and the Base II system for performing clearing and settlement services.

[0033] A "digital certificate" can refer to an electronic document used to prove ownership. A digital certificate may include a public key or information about the public key, along with the identity of the public key's owner, and a digital signature (e.g., data indicating that an entity whose listed owner actually possesses the public key). This digital signature may be a message encrypted using the verified entity's private key. The entity can decrypt the message using the verified entity's public key to identify the verified entity.

[0034] A "Certificate Authority" can refer to a trusted entity that issues certificates to other entities to prove their identity. For example, a Certificate Authority may issue digital certificates that include information about the cryptographic key and the identity of the key owner. Digital certificates can be signed by a Certificate Authority to prove the validity of the certificate's content. Examples of Certificate Authority entities may include network operators, network domain providers, transaction processors, or processing networks.

[0035] A "signature" can refer to an electronic signature of a message or some data. A digital signature can be a numeric data value, an alphanumeric data value, or any other type of data, including graphical representations. A digital signature can be a unique data value generated from a message and a private key using a cryptographic algorithm. In some embodiments, a verification algorithm using a public key can be used to verify the signature.

[0036] NFC technology enables users' communication devices to exchange application data with access devices for near-field transactions. The distance between the user's communication device and the access device communicating via NFC can be 4 cm or less, effectively preventing perpetrators at a distance from intercepting the data exchange. After some information is exchanged between the devices, the transaction is authorized. These exchanges can be a series of Application Protocol Data Unit (APDU) commands and responses. The round-trip NFC communication for processing a transaction can be completed in less than 500 milliseconds. However, despite these advantages, near-field solutions like NFC still require the user to be physically close to the access device, thus limiting the versatility and user experience of such solutions.

[0037] To enable more hands-free and seamless transaction mechanisms, longer-range wireless communication protocols, such as the Bluetooth protocol family including BLE, can be used. By employing longer-range wireless communication protocols, a user's communication device can communicate with an access device located at a certain distance. However, unlike NFC, the longer communication distance makes it vulnerable to malicious interception of data traffic and man-in-the-middle attacks. Longer communication distances also introduce pairing and reliability issues, and connections are easily lost when many devices are close to each other. To date, these drawbacks have prevented the widespread adoption of such longer-range wireless communication protocols for transactions or, more generally, for exchanging sensitive data. However, the techniques described in this paper can enhance the security and reliability of such longer-range wireless communication protocols, making them suitable for transactions and the exchange of sensitive data.

[0038] Figure 1 This diagram illustrates a block diagram of a system 100 for secure extended-distance application data exchange according to some embodiments. System 100 may include a user's communication device 102, an access device 104, and a Certificate Authority Server 110 operated by a Certificate Authority. Communication device 102 and access device 104 may reside in the same location (e.g., a merchant store location) and may form a peer-to-peer network 150 with other nearby users and / or other access devices operating using wireless communication protocols such as BLE or other suitable protocols. Certificate Authority Server 110 may be remotely located or located in the same location as peer-to-peer network 150. If located in the same location, Certificate Authority Server 110 may communicate with communication device 102 and / or access device 104 using the same wireless communication protocol as peer-to-peer network 150 (e.g., BLE), or if remotely located, it may use some other Internet-accessible wireless protocol such as WiFi or cellular network protocols.

[0039] The communication device 102 may be, for example, a mobile or wearable device, an Internet of Things (IoT) device, a vehicle information system, or other communication device, which may have a transaction application installed on the communication device to provide the ability to conduct transactions with access devices using wireless communication protocols. The transaction application may provide the ability to securely acquire and store account credentials and generate transaction data, such as transaction passwords, for conducting transactions. The transaction application may also access the networking stack to facilitate communication using wireless communication protocols such as BLE or other suitable protocols, and store network status information of the peer-to-peer network 150, enabling the communication device 102 to appropriately pair with nearby available access devices to exchange application data (e.g., for conducting transactions).

[0040] In some embodiments, account credentials obtained and stored by a transaction application on communication device 102 may include a token that serves as an alternative to the actual account identifier. For example, the transaction application may retrieve the account identifier by manual input or by retrieving it from an image (e.g., an image of a credit card captured by the camera of communication device 102) using optical character recognition. The transaction application may then use the account identifier to request a token from a remote token service provider. After authentication of the user and / or communication device 102, the remote token service provider may generate or otherwise retrieve a token mapped to the account identifier and transmit the token to communication device 102. In some embodiments, the remote token service provider may also provide a cryptographic key, such as a restricted access key for communication device 102. Communications involved in the tokenization process may be encrypted using encryption schemes such as opacity to prevent other processes performed on communication device 102 from intercepting or observing token requests and responses.

[0041] Once the token and / or password key are received by the transaction application, they can be stored in a secure environment on the communication device 102, such as a hardware secure element (e.g., a SIM card), or in a Trusted Execution Environment (TEE), such as those implemented by creating a virtual machine on the communication device. In some embodiments, software cryptographic methods, such as white-box cryptography, can be used to encrypt the token and / or password key for secure storage on the communication device 102. For transaction processing, the communication device 102 can pair with the access device 104 using a wireless communication protocol such as BLE, and the transaction application executing on the communication device 102 can retrieve the token and transmit it to the access device 104 to request transaction authorization. In some embodiments, the transaction application can also generate a transaction password using the password key and transmit the generated password along with the token to the access device 104.

[0042] One advantage of using extended-range wireless communication protocols such as BLE for transactions is that the longer distance can help reduce the number of queues and physical terminals at merchant locations. For example, by eliminating the requirement for users to be physically close to the access device, as is the case with NFC, a single access device can support multiple users located at different locations throughout the merchant's network. For Bluetooth-enabled access devices, up to seven connections can be allowed simultaneously. Therefore, up to seven users can potentially transact with the same access device at the same time. This is useful in environments such as restaurants (quick and full service) and / or shopping malls. Other scenarios may require one access device per user. For example, if a vehicle is attempting to pair with a fuel pump or parking meter, each access device should only pair with one user.

[0043] To allow communication device 102 to properly pair with access devices in any situation, a transaction application installed on communication device 102 may include a conflict resolver to obtain network status information of peer-to-peer network 150 and determine which access device in peer-to-peer network 150 is available. Network status information may include, for example, the number of access devices and user communication devices in peer-to-peer network 150, and which devices are connected to each other for data exchange. For example, in an environment with multiple users per access device, the conflict resolver may determine which access device in peer-to-peer network 150 is connected to the maximum number of user devices, and which access device in peer-to-peer network 150 is connected to fewer than the maximum number of user devices. The conflict resolver may then instruct communication device 102 to connect to an access device connected to fewer than the maximum number of user devices. In a scenario with one user per access device, the conflict resolver may determine which access device in peer-to-peer network 150 is in use and instruct communication device 102 to connect to an access device that is not currently paired with a user device.

[0044] Using extended-range wireless communication protocols can also expose the system to reliability issues due to interference and pairing problems. Therefore, the transaction application installed on communication device 102 may also include an integrity checker to verify that user communication device 102 and access device 104 have successfully exchanged data, and to retry message relays a predetermined or configurable number of times if any discrepancies exist. For example, data exchange may be packetized, and checksum and packet length information may be included in the packet header and / or packet trailer. The packet receiver can verify the length and checksum, and if verification of the length or checksum fails, request a retransmission of the packet. To improve data transmission speed, the transaction application installed on communication device 102 may also include a message formatter that can dynamically adjust the message or packet size in the network stack based on data size to change transmission speed and reduce overhead.

[0045] Access device 104 may be, for example, a standalone access device (e.g., a sales register, point-of-sale terminal, etc.), an embedded access device integrated into another system (e.g., a fuel pump, parking meter, information kiosk, etc.), or a communication device such as a mobile or tablet device. It may have a receiving application installed on the device to provide the functionality to transact with a user's communication device using a wireless communication protocol and to communicate with the merchant system and / or transaction processing network. The receiving application installed on access device 104 may provide the functionality to pair with communication device 102, obtain account credentials such as account identifiers, tokens, and / or passwords from communication device 102, and (e.g., via the merchant system) transmit the account credentials to the transaction processing network to obtain transaction authorization.

[0046] In some embodiments, the accepting application installed on access device 104 may include a connection processor to facilitate the establishment of a wireless connection with communication device 102. For example, if the wireless communication protocol used is BLE, the connection processor may configure access device 104 as a General Attributes (GATT) profile client, which can potentially accept up to seven connections simultaneously for multiple user use cases, and as a GATT peripheral device, which can only connect to one communication device for a single user per access device use case. The connection processor may also obtain network status information from peer-to-peer network 150 to understand the current pairing status and make decisions about accepting or rejecting new connections. In some embodiments, the accepting application installed on access device 104 may also include a broadcaster to broadcast transaction services offered by access device 104. For example, when communication device 102 approaches peer-to-peer network 150, communication device 102 may detect a signal (e.g., a beacon) broadcast by access device 104 to indicate support for the wireless transaction service, and communication device 102 may agree to use the service before establishing a secure connection with access device 104 for data exchange. Broadcasters can be used to handle broadcasting and consent functions.

[0047] One problem with using extended-range wireless communication protocols such as BLE is that longer communication distances make it easier for sensitive data, such as account credentials, to be intercepted. To ensure the protection of sensitive data such as account credentials, the receiving application installed on access device 104 may include a certificate processor to manage secure digital certificates obtained from a Certificate Authority (CA). When communication device 102 connects to access device 104, access device 104 can exchange certificates with communication device 102 and verify that the certificate was issued by a legitimate CA from communication device 102 and that the certificate is valid. Communication between communication device 102 and access device 104 can be encrypted using the public key included in the certificate and decrypted by a mutually trusted recipient with the assistance of the CA. The certificate processor can be used to facilitate the receipt and dissemination of certificate information and ensure that the certificate is stored on a device within a secure keystore execution environment, preventing the certificate from being extracted or reused by malicious processes or entities.

[0048] As described above, peer-to-peer network 150 may include communication devices (including communication device 102) and access devices (including access device 104) coupled to each other using wireless communication protocols such as BLE or other suitable protocols. Each device in peer-to-peer network 150 may provide platform services to maintain network state information when a new device joins the network, an existing device leaves the network, when devices pair up for a transaction, and / or when devices disconnect after a transaction is completed. For example, the conflict resolver of communication device 102 may rely on platform services to obtain and locally store the state of the device when it connects. These connections indicate that a user communication device is connected to an access device in peer-to-peer network 150. Each device in peer-to-peer network 150 may broadcast its pairing status to all other devices, so that each device can obtain the latest status of which access device it is connected to and which access device it wants to discard. Devices in peer-to-peer network 150 may also maintain a handshake registrar to record and save device pairings in the system, and may use a synchronization module to spread data from the registrar to all other devices.

[0049] A Certificate Authority (CA) 110 may be a trusted entity, such as an issuer or transaction processor, that provides certificates to access devices hosted by the merchant and user communication devices. CA 110 can provide services for verifying certificate validity and maintaining a Certificate Revocation List (CRLS). In some embodiments, to facilitate offline transactions, the certificate verification process can be performed periodically or at a different time than the transaction, so that an online process is not required each time a transaction is initiated. For example, CA 110 can issue a communication device digital certificate to communication device 102. Similarly, CA 110 can issue an access device digital certificate to access device 104. When communication device 102 first connects to access device 104 for a transaction, the devices can exchange digital certificates, and each device can verify the received digital certificate using CA 110. Thereafter, these devices can be placed in a list of mutually trusted devices (e.g., a whitelist), so that a digital certificate verification process is not required the next time the two devices transact. In some embodiments, entries on the trusted device list indicating that a particular device is trusted may expire after a predetermined period of time, after which a digital certificate verification process may need to be performed again to maintain mutual trust. In some embodiments, the list of entries may expire at the same time as the digital certificate, or before the digital certificate expires.

[0050] Figure 2 A communication flowchart of a user's communication device 202 (e.g., acting as an initiating device) transacting with an access device 204 (e.g., acting as a target device) according to some embodiments is shown. Prior to the transaction, each of the communication device 202 and the access device 204 may obtain a digital certificate from a Certificate Authority (CA) 210. For example, during the installation or initiation of a transaction application on the communication device 202, the communication device 202 may send a request for a digital certificate to the CA 210. The request may include user information for authenticating the user and / or the communication device 202. Upon authenticating the user and / or the communication device 202, the CA 210 may issue a communication device digital certificate and transmit it to the communication device 202, which may be stored in a secure storage device (e.g., a secure element, TEE, etc.) on the communication device 202. The communication device digital certificate may include a communication device public key that can be allocated by the communication device 202, and data encrypted with the communication device public key can be decrypted using a communication device private key stored on the communication device 202. The communication device digital certificate may also have an expiration date, and the communication device 202 may renew the communication device digital certificate with CA 210 when or before the expiration date.

[0051] Similarly, during the installation or initiation of an acceptance application on access device 204, access device 204 may send a request for a digital certificate to CA 210. The request may include merchant information regarding the merchant's operation of access device 204. Upon authenticating the merchant, CA 210 may issue an access device digital certificate and transmit it to access device 204. The access device digital certificate may include an access device public key that can be assigned by access device 204, and data encrypted with the access device public key can be decrypted using an access device private key stored on access device 204. The access device digital certificate may also have an expiration date, and access device 204 may renew the access device digital certificate with CA 210 when or before its expiration. In some embodiments, the access device digital certificate may have a longer lifespan than the communication device digital certificate.

[0052] When a user operating communication device 202 first enters a merchant location and approaches peer-to-peer network 250, communication device 202 can detect the presence of other devices in peer-to-peer network 250, such as access device 204, which can transact with communication device 202 using wireless communication protocols (e.g., BLE or other suitable protocols). For example, devices at the merchant location may periodically broadcast signals or beacons that broadcast wireless transaction services supported by the merchant location. Communication device 202 can detect the signals and identify that the transaction application on communication device 202 supports the broadcast wireless transaction service. Communication device 202 can then obtain network status information from one or more devices in peer-to-peer network 150 to allow communication device 202 to join peer-to-peer network 150. For example, communication device 202 can receive network status information indicating which devices are in peer-to-peer network 150 and which devices are grouped together in a device cluster. Communication device 202 may locally store a copy of network state information, update the network state information to add communication device 202 to peer-to-peer network 150, and transmit the updated information to one or more devices in peer-to-peer network 150 to join peer-to-peer network 150. Any change to the network state information initiated by any device in peer-to-peer network 150 may be propagated to all devices in peer-to-peer network 150, enabling these devices to update their local copies of the network state information.

[0053] When communication device 202 is ready to conduct a transaction, it can determine that access device 204 is available based on current network state information. Communication device 202 can transmit a connection request, including its digital certificate, to access device 204 at operation 252 to request the establishment of a secure connection. The digital certificate may include the public key of communication device 202 and is digitally signed by CA 210 to verify its authenticity. Upon receiving the connection request, access device 204, acting as the target device, can send a certificate verification request to CA 210 at operation 254 to request CA 210 to verify the communication device's digital certificate. For example, CA 210 can verify that the communication device's digital certificate was previously issued by CA 210, has not expired, and contains a valid digital signature signed by CA 210. While verifying the communication device's digital certificate, CA 210 can send a certificate verification response back to access device 204 at operation 256 to indicate whether the communication device's digital certificate is valid and authentic. In some embodiments, access device 204 can locally verify the communication device's digital certificate. For example, access device 204 may be equipped with the public key of CA 210 to verify the digital signature of the communication device's digital certificate. In some embodiments, to facilitate offline transactions, the certificate verification process may also be a periodic process, or performed at other times instead of during a transaction.

[0054] Once the communication device digital certificate of communication device 202 has been verified by CA 210 and / or access device 204, access device 204 can whitelist communication device 202 as an authenticated device. The whitelist of communication device 202 can remain valid for a predetermined period or until the communication device digital certificate expires, and access device 204 can omit verifying the communication device digital certificate of communication device 202 to conduct further transactions during the whitelist period. If the verification of the communication device digital certificate fails, access device 204 can blacklist communication device 202 as an unauthorized device and prevent communication device 202 from establishing a secure connection to transact with access device 204. The blacklist of communication device 202 can remain valid for a predetermined period or until a new communication device digital certificate from communication device 202 is verified. In some embodiments, the list of communication devices 202 may include part of network state information stored locally on access device 204, and access device 204 can push the updated device list to other devices in the peer network 250 at operation 258. When other devices in the peer-to-peer network 250 receive device list updates, the other devices may update their local lists to indicate whether authentication of communication device 202 can be omitted (e.g., whether to add it to a whitelist) or whether communication device 202 should be blocked (e.g., whether to add it to a blacklist).

[0055] At operation 262, in response to verification by communication device 202, access device 204 may provide its access device digital certificate and transaction amount to communication device 202. The access device digital certificate may include the public key of access device 204 and is digitally signed by CA 210 to determine its authenticity. In some embodiments, the transaction amount and access device digital certificate may be encrypted using the public key of communication device 202 received in operation 252, and communication device 202 may decrypt the information using its corresponding private key. Upon receiving and decrypting the access device digital certificate, communication device 202 may send a certificate verification request at operation 264 to request CA 210 to verify the access device digital certificate. For example, CA 210 may verify that the access device digital certificate was previously issued by CA 210, has not expired, and contains a valid digital signature signed by CA 210. Upon verifying the access device digital certificate, CA 210 may send a certificate verification response back to communication device 202 at operation 266 to indicate whether the access device digital certificate is valid and authentic. In some embodiments, communication device 202 can locally verify the access device's digital certificate. For example, communication device 202 may be equipped with the public key of CA210 to verify the digital signature of the access device's digital certificate. Then, communication device 202 may add access device 204 to a whitelist or blacklist depending on whether the access device's digital certificate has been verified, similar to the process for communication device digital certificates discussed above. At operation 268, communication device 202 may push a device list update to update the list of access device 204 to other devices in the peer-to-peer network 250 at operation 268.

[0056] After verifying the digital certificates of the communication device and the access device, mutual trust can be established between the communication device 202 and the access device 204. The user of the communication device 202 can confirm the transaction amount received in operation 262 and send a confirmation message at operation 272 to securely connect to the access device 204. In some embodiments, the confirmation message can be encrypted using the public key of the access device 204 received in operation 262. In response to receiving the confirmation message, the access device 204 can update its local network state information to indicate that it is now securely connected to the communication device 202 for transactions, and push the network state information update to the peer-to-peer network 250 at operation 274 so that other devices in the peer-to-peer network 250 know that the access device 204 is now in use.

[0057] At operation 276, access device 204 may provide an access device configuration file to communication device 202, enabling communication device 202 to emulate a virtual access device. The access device configuration file may be encrypted using the public key of communication device 202 and may include information such as terminal transaction data from access device 204 required by communication device 202 to complete a transaction. For example, the access device configuration file may include a transaction environment identifier (e.g., a proximity payment system environment (PPSE) name) identifying the transaction environment supported by access device 204, a priority list of application identifiers supported by access device 204, a terminal transaction identifier (TTQ) indicating the transaction type supported by access device 204 (e.g., chip card transaction), unpredictable numbers generated by access device 204 for the transaction, and / or other information required by communication device 202 to locally emulate access device 204 on communication device 202.

[0058] At operation 278, communication device 202 can decrypt the access device configuration file using its private key and locally simulate access device 204 on communication device 202 using the access device configuration file. By locally simulating access device 204 on communication device 202, a transaction application executing on communication device 202 can exchange application data with the virtual access device using a series of application commands and application data responses (e.g., APDU commands and responses) locally on communication device 202. Then, at operation 282, the application data responses can be concatenated into data packets by the virtual access device, encrypted using the public key of access device 204, and transmitted to the actual access device 204 in a single message. This reduces the number of messages sent between communication device 202 and access device 204, improving reliability when using extended-range wireless communication protocols such as BLE. In some embodiments, concatenated application data responses can be transmitted to access device 204 in multiple messages, and reliability can still be improved as long as the number of messages is less than the number of application data responses that would normally be required if communication device 202 sends application data responses directly to access device 204.

[0059] When access device 204 receives a data packet from a concatenated application data response, it can parse the packet, generate a transaction authorization request message, and send the message to the issuer to request transaction authorization. Then, access device 204 can disconnect from communication device 202, update its local network status information to indicate that the communication channel is now open for transactions with other devices, and push the network status information update to peer-to-peer network 250 at operation 284 to inform other devices in peer-to-peer network 250 of access device 204's availability.

[0060] Figure 3 An example communication flow is illustrated between a transaction application 332 executing on a communication device 330 and a virtual access device 334 locally simulated on the communication device 330, according to some embodiments. For example, the virtual access device 334 can be simulated based on an access device profile obtained from the actual access device with which the communication device 330 is transacting. Communication can take the form of application commands sent from the virtual access device 334 and application data responses sent from the transaction application 332 in response to the application commands. In some embodiments, the application commands and data responses can be in the form of APDU commands and responses. However, it should be understood that other messages, messaging protocols, or formats can be used to exchange application data for transacting.

[0061] To initiate application data exchange, virtual access device 334 can initiate a transaction by sending an available application request 302 to transaction application 332 to request information about which payment application identifiers (AIDs) are available. Each AID may correspond to a user's account and / or processing options associated with that account. In some embodiments, available application request 302 may be in the form of a PPSE selection command. Available application request 302 may include a payment environment identifier (e.g., a PPSE name) to identify the payment environment supported by virtual access device 334.

[0062] Upon receiving an available application request 302, transaction application 332 can identify and process the request by recognizing the payment environment identifier (e.g., PPSE name) included in the request, and respond by sending an available application response 304 back to virtual access device 334. The available application response 304 may include a list of available AIDs and may include the payment environment identifier (e.g., PPSE name) as a dedicated filename. In some embodiments, the available application response 304 may be in the form of a selected PPSE response and may include PPSE File Control Information (FCI). For example, the available application response 304 may include a directory entry for each available AID. If transaction application 332 supports only one AID, it may respond with a single directory entry for that supported AID. If transaction application 332 supports accounts with multiple AIDs, it may respond with a directory entry for each supported AID. Each directory entry may include information such as: AID, application tag associated with the AID (e.g., mnemonic associated with the AID), application priority indicator indicating the priority of the AID, kernel identifier indicating the kernel preferences of the application, and / or additional information related to a specific AID. Available application responses to 304 may also include other data such as FCI issuer discretionary data.

[0063] When the virtual access device 334 receives an available application response 304, it can select a suitable application from the list of applications received in the available application response 304 (e.g., by selecting an AID from the available AIDs received in the available application response 304). In some embodiments, the selected AID may be the highest priority AID on a priority list of application identifiers supported by the access device emulated by the virtual access device 334. The priority list of application identifiers may be obtained as part of an access device profile provided to the communication device 300 by the actual access device. The virtual access device 334 may send an application selection 306 with the selected AID to the transaction application 332 to continue the transaction. In some embodiments, the application selection 306 may be in the form of an AID selection command.

[0064] Upon receiving application selection 306, transaction application 332 may send terminal transaction data request 308 to request transaction data from virtual access device 334 to execute the transaction using the selected application / AID. In some embodiments, terminal transaction data request 308 may be in the form of an AID selection response and may include AID file control information (FCI) with the selected AID as a dedicated filename. Terminal transaction data request 308 may include a list of transaction data identifiers requesting appropriate data from virtual access device 334, and the list of transaction data identifiers may be in the form of a Processing Option Data Object List (PDOL). The transaction data requested by transaction application 332 in response to the transaction request may include terminal transaction qualifier (TTQ), authorized amount, other amounts, terminal country code, terminal verification result, transaction currency code, transaction data, transaction type, and / or unpredictable numbers. Terminal transaction data request 308 may also include other data, such as FCI issuer discretion data, application identifiers, and language preferences.

[0065] Upon receiving a terminal transaction data request 308, the virtual access device 334 may send the terminal transaction data 310 requested by the transaction application 332 to the transaction application 332. The terminal transaction data 310 provided by the virtual access device 334 may be obtained from an access device profile, which is obtained via communication device 300 from the actual access device simulated by the virtual access device 334. In some embodiments, the terminal transaction data 310 may be sent in the form of a Get Processing Option (GPO) command and may include terminal transaction data requested in a Processing Option Data Object List (PDOL). In some embodiments, the terminal transaction data 310 (e.g., a Terminal Transaction Qualifier (TTQ)) may include a transaction type indicator indicating the type of transaction supported by the access device. In some embodiments, the terminal transaction data 310 (e.g., the Terminal Transaction Qualifier TTQ) may also include a CVM request indicator indicating whether a Consumer Authentication Method (CVM) is required for the access device to process the transaction, and may also include one or more CVM type indicators indicating the type of CVM supported by the access device. Instances of CVMs that can be supported by access devices may include online PINs, signatures, and / or consumer device CVMs (CDCVMs) such as passwords used on communication device 300 to unlock the screen or transaction application 332.

[0066] Once the transaction application 332 receives the terminal transaction data 310, it can increment its Application Transaction Counter (ATC), generate dynamic transaction processing information using at least some of the received terminal transaction data 310, and send a set of transaction processing information 312, including the generated dynamic transaction processing information, to the virtual access device 334. In some embodiments, the transaction processing information 312 may be sent in the form of a GPO response. In some embodiments, the transaction processing information 312 may include one or more Application File Locators (AFLs) that can be used by the virtual access device 334 as file addresses to read account data stored on the communication device 300, and Application Exchange Features (AIPs) that can be used to indicate the capabilities of the transaction application 332.

[0067] In some embodiments, the AFL included in transaction processing information 312 may include a file address for reading account data, such as a transaction password dynamically generated from the access device using a restricted access key (LUK) and / or unpredictable numbers, track-2 equivalent data including a token or PAN, and additional data such as issuer application data (IAD), shape factor indicator (FFI), card transaction qualifier (CTQ), password information data (CID), updated ATC and / or application PAN serial number (PSN). In some embodiments, the issuer application data (IAD) may include a length indicator indicating the length of the IAD, a password version number (CVN) indicating the version of the transaction password, a derived key indicator (DKI) that can be used to identify the master key (e.g., the master key associated with the issuer used when generating the LUK), a card verification result (CVR), a wallet provider ID, and / or derived data, such as a key index used when generating the LUK. In some embodiments, transaction processing information 312 may include the aforementioned account data itself, rather than its corresponding AFL or a combination thereof. It should also be understood that, in some embodiments, the transaction processing information 312 sent from the transaction application 332 to the virtual access device 334 may include some or all of the information described above, and in some embodiments, may include additional information not specifically described.

[0068] After receiving transaction processing information 312, virtual access device 334 may send account data request 314 to transaction application 332 to read additional account data that may be stored on communication device 300. In some embodiments, account data request 314 may be in the form of a read record command and may include an application file locator (AFL) indicating the address or location of the account data that virtual access device 334 is attempting to read. The AFL included in account data request 314 may correspond to the AFL in transaction processing information 312 provided from transaction application 332 to virtual access device 334.

[0069] In response to receiving an account data request 314 from the virtual access device 334, the transaction application 332 may send account data 316 stored at a location indicated by the AFL to the virtual access device 334. In some embodiments, the account data 316 may be sent in the form of a read record response. The account data 316 may include, for example, account data elements discussed above and / or application usage controls indicating restrictions on the use and services permitted by the application by the issuer, the cardholder's name, consumer-specific data, the issuer's country code, the token requester ID (e.g., whether a token is used), and / or other account-related data accessible at the AFL location. It should be understood that in some embodiments, the account data 316 sent from the transaction application 332 to the virtual access device 334 may include some or all of the information described above, and in some embodiments, may include additional information not specifically described.

[0070] In some embodiments, there may be more than one pair of account data requests 314 and account data 316 communication exchanges between the virtual access device 334 and the transaction application 332. Once the virtual access device 334 has received the required data from the transaction processing information 312 and / or one or more account data 316 transmissions, some or all of the data elements in the transaction processing information 312 and / or one or more account data 316 transmissions may be concatenated by the virtual access device 334 to form a data packet. The data packet may include a checksum and a packet length indicator to indicate the length of the data packet. The data packet may be transmitted from the communication device 300 to the actual access device to allow the access device to generate a transaction authorization request message to request transaction authorization from the issuer. For example, in some embodiments, the transaction authorization request message may include at least track-2 equivalent data including a token or PAN and a transaction password generated using LUK, and may authorize the transaction at least based on a set of LUKs that have been correctly generated to verify the transaction password and that the LUKs used to generate the transaction password have not exhausted one or more restricted usage thresholds.

[0071] Figure 4A flowchart illustrating a process 400 performed by a communication device for exchanging application data with an access device, according to some embodiments, is shown. The communication device and the access device may be part of a peer-to-peer network of devices using a wireless communication protocol such as BLE, which has a longer communication range than NFC. Before establishing a communication channel to exchange application data, the communication device and the access device may exchange digital certificates issued by a Certificate Authority to establish mutual trust between the two devices. For example, to initiate a secure connection to perform data exchange, the communication device may transmit its digital certificate to the access device. The access device may verify the communication device's digital certificate before transmitting additional information about the access device, such as its access device profile, to the communication device. The communication device may also receive the access device's digital certificate from the access device and verify it before performing further functions to facilitate data exchange, such as emulation of the access device.

[0072] At operation 402, in response to the verification of the digital certificate, the communication device can establish a secure communication channel with the access device, for example, by sending an acknowledgment message to the access device to indicate that the digital certificate exchange was successful and the certificate is valid. In some embodiments, the acknowledgment message can be encrypted using the access device's public key, which is included in the access device's digital certificate transmitted to the communication device. Upon receiving the acknowledgment message, the access device can decrypt it using its private key, and if the acknowledgment message can be correctly decrypted, a secure connection with the communication device is permitted.

[0073] At operation 404, the communication device can receive an access device profile from the access device. The access device profile may include access device parameters to enable the communication device to locally emulate a virtual access device on its own, thereby reducing the amount of external transmission required to exchange application data between devices. For example, the access device profile may include a priority list of application identifiers supported by the access device, unpredictable numbers generated by the access device, and / or other terminal transaction data / parameters that the access device can use or provide to the communication device to obtain application data for completing a transaction. In some embodiments, the access device profile may be encrypted using the communication device public key included in the communication device digital certificate provided to the access device.

[0074] At operation 406, the communication device can locally simulate a virtual access device on its own body based on an access device configuration file. For example, the communication device can instantiate a virtual machine and execute programming code that provides access device functionality, such as issuing application commands (e.g., APDU commands) to a trading applet to obtain account data for a transaction. Information in the access device configuration file can allow the simulated virtual access device to generate appropriate commands based on the characteristics of the actual access device. In some embodiments, if the received access device configuration file is encrypted, the communication device can decrypt the access device configuration file using its private key.

[0075] At operation 408, the virtual access device executing on the communication device can issue a set of application commands to a transaction applet executing on the communication device, and at operation 410, receive a set of application data responses from the transaction applet in response to the set of application commands. In some embodiments, the application commands and data responses can be in the form of APDU commands and responses. In some embodiments, the virtual access device can wait for the application data response from the transaction applet after each application command before sending the next application command.

[0076] For example, as part of operation 408, the virtual access device may send a command to the trading applet requesting a list of application identifiers available to the trading applet, where each application identifier may correspond to an account or a set of processing options for an account. In response, as part of operation 410, the trading applet may provide a list of available application identifiers. Then, as part of operation 408, the virtual access device may send a select application identifier command to select an application identifier from the list of available application identifiers associated with the trading applet. The select application identifier command may be generated by the virtual access device based on a priority list of application identifiers included in the access device configuration file. The exchange of application commands and data responses may be based on information regarding... Figure 3The described communication exchange continues. For example, the communication exchange may also include the virtual access device sending application commands with unpredictable numbers to the transaction applet. The unpredictable numbers may be numbers generated by the actual access device and included in the access device's configuration file. The transaction applet may respond by sending application data responses including a transaction password generated by the transaction applet using the unpredictable numbers (e.g., by encrypting the unpredictable numbers at least using a restricted access key). In some embodiments, a set of application data responses may include a set of application file locators containing the memory address of account information, and a set of application commands may include a set of read log commands to read the account information using the application file locators. Each read log command may include an application file locator. The set of application data responses may also include a set of read log responses from the transaction applet containing account information corresponding to the AFL.

[0077] At operation 412, after the virtual access device obtains the necessary application data from the transaction applet, the communication device can generate a data packet by concatenating multiple application data elements contained in a set of application data responses (e.g., a read record response). For example, the application data response may include application data such as a token or PAN, a transaction password, account expiration information, and a reference. Figure 3 Other data elements are described, and these data elements can be concatenated into a data packet. A checksum can be calculated for these data elements, and the checksum, along with the length of the data packet, can be added to the header of the data packet.

[0078] At operation 414, the communication device can transmit data packets to an external access device using the established secure communication channel. In some embodiments, the data packets can be encrypted using an access device public key included in the access device digital certificate provided to the communication device. The access device then decrypts the data packets using its access device private key, checks the integrity of the data packets to ensure there are no transmission errors by recalculating the checksum and verifying the length of the data packets, parses the data packets, and generates an authorization request message to obtain transaction authorization. In some embodiments, if a transmission error is detected, the access device can send a retransmission request to the communication device to request the communication device to retransmit the data packets.

[0079] Figure 5A block diagram of a communication device 500 according to some embodiments is shown. In some embodiments, the communication device 500 may be a user-operated mobile device. The communication device 500 may include device hardware 510 coupled to memory 520. The device hardware 510 may include a processor 512 and a communication subsystem 514 having one or more transceivers 515, the communication subsystem being capable of communicating with external devices using wireless communication protocols such as BLE and user interface 516. In some embodiments, the device hardware 510 may include a display 518 (which may be part of the user interface 516). The processor 512 may be implemented as one or more integrated circuits (e.g., one or more single-core or multi-core microprocessors and / or microcontrollers) and is used to control the operation of the communication device 500. The processor 512 may execute various programs in response to program code or computer-readable code stored in memory 520 and may maintain multiple concurrently executing programs or processes. The user interface 516 may include any combination of input and output elements to allow a user to interact with the communication device 500 and invoke the functions of the communication device. In some embodiments, the user interface 516 may include components that can be used for input and output functions, such as a display 518.

[0080] Memory 520 can be implemented using any combination of any number of non-volatile memories (e.g., flash memory) and volatile memories (e.g., DRAM, SRAM) or any other non-transient storage media or media storing computer-executable code. Memory 520 may store an operating system (OS) 525 and an application environment 530, in which one or more applets and / or applications executed by processor 512 may reside. Application environment 530 may include a transaction applet 532, an emulator simulating a virtual access device 534, and a networking applet 536. In some embodiments, transaction applet 532, virtual access device 534, and / or networking applet 536 may be integrated as part of one or more applications, such as a transaction application (e.g., a wallet or payment application, a merchant application, etc.).

[0081] Transaction app 532 may be an app that uses, accesses, and / or stores sensitive information such as account credentials 533 (e.g., account identifier, token, etc.). Transaction app 532 may support multiple accounts and multiple application identifiers to support different transaction processing options. In some embodiments, user access to transaction app 532 may be protected by user authentication data such as passwords, PINs, etc. For example, when a user attempts to launch or execute transaction app 532, the user may be requested to enter valid user authentication data before the user has access to transaction app 532. Account credentials 533 may store sensitive information such as account credentials (e.g., PAN, token) and other account parameters such as restricted access keys used for transactions, and transaction app 532 may provide the ability to retrieve tokens and / or restricted access keys from a remote server. Transaction app 532 may include a cryptographic module to provide cryptographic functionality for the transaction app, such as encrypting and decrypting communications and / or generating transaction passwords. For example, the cryptographic module can use encryption algorithms such as DES, AES, TDES / TDEA, and / or hash functions such as SHA to implement and perform encryption / decryption operations on the transaction app 532. When the transaction app 532 accesses account credentials 533, such as tokens or restricted-use keys stored for transactions, the transaction application 533 can invoke the cryptographic module to generate a transaction cryptography based on the restricted-use key and / or token.

[0082] Virtual access device 534 may be an instance of a simulated access device executed on communication device 500. Virtual access device 534 may include, or have access to, an access device configuration file 535 obtained from an external access device simulated by communication device 500. Virtual access device 534 may provide access device functionality, such as selecting an application identifier to process a transaction, issuing application commands such as APDU commands to provide transaction parameters (transaction qualifiers, transaction amount, unpredictable numbers, etc.) to transaction applet 532 to complete the transaction, receiving application data responses from transaction applet 532, and generating one or more data packets based on responses transmitted from transaction applet 532 to the external access device.

[0083] Communication device 900 can use network applet 536 to join a device network and establish a secure channel with access devices for transactions. For example, network applet 536 can support wireless communication protocols such as BLE. Network applet 536 can detect nearby devices using the same wireless communication protocol and use the protocol to support transaction services. Network applet 536 can obtain network status information from other devices in the network and store it locally as network status information 537. Network status information 537 can include mappings of which devices in the network are grouped together in the device cluster, which communication device in the device network is currently paired with which access device for transactions, and which access devices in the device network are available. Communication device 500 can also use network status information 537 to direct access devices to perform application data exchange for transactions.

[0084] While BLE has been used as an exemplary wireless communication protocol to describe certain aspects of the techniques disclosed herein, it should be understood that the techniques described herein can be applied to other wireless communication protocols, including those using one or more radio frequencies as the transmission medium. Furthermore, although some aspects have been described in the context of transactions, the secure data exchange techniques disclosed herein can be applied to the transmission of other types of sensitive data.

[0085] The techniques described herein may relate to implementing one or more functions, processes, operations, or method steps. In some embodiments, the functions, processes, operations, or method steps may be implemented as the result of an instruction set or software code executed by a suitably programmed computing device, microprocessor, data processor, etc. The instruction set or software code may be stored in memory or other forms of data storage elements accessed by the computing device, microprocessor, etc. In other embodiments, the functions, processes, operations, or method steps may be implemented by firmware or a dedicated processor, integrated circuit, etc.

[0086] The methods and processes described herein are exemplary in nature, and the methods and processes according to some embodiments may perform one or more of the steps in a different order than that described herein, including one or more additional steps not specifically described, omitting one or more steps, combining one or more steps into a single step, dividing one or more steps into multiple steps, and / or any combination thereof.

[0087] Any software component or function described in this application may be implemented using, for example, conventional or object-oriented techniques and in any suitable computer language, such as Java, C++, or Perl, as software code to be executed by a processor. The software code may be stored as a series of instructions or commands on a computer-readable medium such as random access memory (RAM), read-only memory (ROM), magnetic media such as a hard disk drive or floppy disk, or optical media such as a CD-ROM. Any such computer-readable medium may reside on or within a single computing device and may exist on or within different computing devices within a system or network.

[0088] Without departing from the scope of the invention, one or more features of any embodiment may be combined with one or more features of any other embodiment.

[0089] Unless explicitly indicated otherwise, the use of “a” or “the” is intended to mean “one or more”.

Claims

1. A method for secure extended-range application data exchange, the method comprising: A communication channel is established between the access device and the communication equipment; The access device provides the access device configuration file to the communication device, wherein the communication device simulates a virtual access device based on the access device configuration file, and wherein the virtual access device issues an application command set to a transaction applet executed on the communication device, and receives an application data response set from the transaction applet in response to the application command set, and wherein the communication device generates a data packet by concatenating application data contained in the application data response set. The access device receives the data packet from the communication device via the communication channel; The access device generates an authorization request message containing the data in the data packet; as well as The authorization request message is sent to the authorization entity that authorizes the authorization request message.

2. The method of claim 1, further comprising: The access device provides an access device digital certificate to the communication device, wherein the communication device verifies the access device digital certificate before simulating the virtual access device.

3. The method of claim 2, wherein the access device digital certificate includes an access device public key, and the data packet is encrypted by the communication device using the access device public key.

4. The method of claim 1, wherein the communication device is a mobile phone.

5. The method of claim 1, wherein the access device configuration file includes a preferred list of application identifiers supported by the access device.

6. The method of claim 5, wherein the application command set includes a select application identifier command, the select application identifier command being generated by the virtual access device based on the priority list of application identifiers to select an application identifier from a list of available application identifiers associated with the transaction applet.

7. The method of claim 1, wherein the access device profile includes unpredictable numbers generated by the access device.

8. The method of claim 7, wherein the application data response set includes a transaction ciphertext generated by the transaction applet using the unpredictable number, the unpredictable number being provided to the transaction applet by the virtual access device.

9. The method of claim 1, wherein the data packet includes application data from multiple read record responses from the transaction applet.

10. The method of claim 1, wherein the communication channel is a wireless communication channel having a longer communication range than near field communication (NFC).

11. An access device, the access device comprising: processor; as well as The memory stores code that can be executed by the processor to perform operations including: Establish a communication channel with the communication equipment; The communication device provides the access device configuration file of the access device to the communication device, wherein the communication device simulates a virtual access device based on the access device configuration file, and wherein the virtual access device issues an application command set to a transaction applet executed on the communication device, and receives an application data response set from the transaction applet in response to the application command set, and wherein the communication device generates a data packet by concatenating application data contained in the application data response set. The data packet is received from the communication device via the communication channel; Generate an authorization request message containing the data in the data packet; as well as The authorization request message is sent to the authorization entity that authorizes the authorization request message.

12. The access device of claim 11, wherein the operation further comprises: The communication device is provided with an access device digital certificate, wherein the communication device verifies the access device digital certificate before simulating the virtual access device.

13. The access device of claim 12, wherein the access device digital certificate includes an access device public key, and the data packet is encrypted by the communication device using the access device public key.

14. The access device of claim 11, wherein the communication device is a mobile phone.

15. The access device of claim 11, wherein the access device configuration file includes a preferred list of application identifiers supported by the access device.

16. The access device of claim 15, wherein the set of application commands includes a select application identifier command, the select application identifier command being generated by the virtual access device based on the priority list of application identifiers to select an application identifier from a list of available application identifiers associated with the transaction applet.

17. The access device of claim 11, wherein the access device profile includes unpredictable numbers generated by the access device.

18. The access device of claim 17, wherein the application data response set includes a transaction ciphertext generated by the transaction applet using the unpredictable number, the unpredictable number being provided to the transaction applet by the virtual access device.

19. The access device of claim 11, wherein the data packet includes application data from a plurality of read record responses from the transaction applet.

20. The access device of claim 11, wherein the established communication channel is a wireless communication channel having a longer communication range than near field communication (NFC).

Images