Data transfer using virtual terminal

Abstract

Techniques are described herein for using a virtual terminal on a device to handle data transfers. These techniques provide for establishing a virtual terminal for touchless transfer of data, encrypting the data, and rewrapping the data in a manner that protects the user's personal information on the device and in transfer, while providing the information to a server for further processing.

Description

[Technical field]

[0001] (CROSS REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of and priority to U.S. Provisional Patent Application No. 63 / 307,626, filed February 07, 2022, U.S. Provisional Patent Application No. 17 / 952,093, filed September 23, 2022, U.S. Provisional Patent Application No. 17 / 952,094, filed September 23, 2022, and U.S. Provisional Patent Application No. 17 / 952,100, filed September 23, 2022, each of which is incorporated by reference in its entirety for all purposes. [Background technology]

[0002] Electronic devices, especially portable electronic user devices, are rapidly becoming more and more prevalent in any modern society. Such devices may be used as terminals to transmit data to each other. The transmitted data may require encryption and decryption to protect sensitive data. [Brief description of the drawings]

[0003] [Figure 1] FIG. 1 shows a block diagram for implementing the techniques described herein, according to one embodiment of the disclosure.

[0004] [Diagram 2] FIG. 1 shows a sequence diagram for explaining the techniques described herein, according to one embodiment of the present disclosure.

[0005] [Diagram 3] FIG. 1 shows a block diagram for illustrating the techniques described herein, according to one embodiment of the present disclosure.

[0006] [Figure 4] FIG. 1 shows a sequence diagram for explaining the techniques described herein, according to one embodiment of the present disclosure.

[0007] [Diagram 5] 1 illustrates a sequence diagram for performing the techniques described herein, according to one embodiment of the present disclosure.

[0008] [Figure 6] FIG. 1 shows a sequence diagram for explaining the techniques described herein, according to one embodiment of the present disclosure.

[0009] [Figure 7] 1 illustrates a sequence diagram for performing the techniques described herein, according to one embodiment of the present disclosure.

[0010] [Figure 8] 1 illustrates a sequence diagram for performing the techniques described herein, according to one embodiment of the present disclosure.

[0011] [Figure 9] 1 shows a flow diagram for carrying out the techniques described herein, according to one embodiment of the present disclosure.

[0012] [Figure 10] 1 illustrates a sequence diagram for performing the techniques described herein, according to one embodiment of the present disclosure.

[0013] [Figure 11] FIG. 1 shows a block diagram for implementing the techniques described herein, according to one embodiment of the disclosure.

[0014] [Figure 12] 1 shows a flow diagram for carrying out the techniques described herein, according to one embodiment of the present disclosure.

[0015] [Figure 13] 1 shows a flow diagram for carrying out the techniques described herein, according to one embodiment of the present disclosure.

[0016] [Figure 14] 1 shows a flow diagram for carrying out the techniques described herein, according to one embodiment of the present disclosure.

[0017] [Figure 15] 1 illustrates an example architecture or environment configured to implement the techniques described herein, according to embodiments of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0018] In the following description, various embodiments are described. For purposes of explanation, specific configurations and details are set forth in order to provide a thorough understanding of the embodiments. However, it will be apparent to one skilled in the art that the embodiments may be practiced without the specific details. Furthermore, well-known features may be omitted or simplified so as not to obscure the embodiments being described.

[0019] Examples of the present disclosure are directed, among other things, to methods, systems, devices, and computer-readable media that provide techniques for transmitting data using a virtual terminal. Unlike traditional data transmission, the techniques described herein enable a virtual terminal on a multi-purpose device (e.g., a mobile device, a smartphone, a tablet, etc.) that secures and encrypts data for transmission. A system including a virtual terminal includes a reader application (e.g., a data reader application), an internal near-field data transceiver device (e.g., an internal data reader such as a Near Field Communication (NFC) chip), a secure element, and a terminal profile identifier (Terminal Profile Identifier). The virtual terminal may be configured to include a data reader (e.g., a data reader that reads data from a physical device or equipment). The near-field data receiving device may not be a component of an external connection device (e.g., a dongle) but rather be integrated into a general-purpose device. In some cases, transferring data using the virtual terminal may include transferring information regarding a transaction with an item / information source. In some embodiments, the virtual terminal may be used as a data reader (e.g., a data reader that reads data from a physical device or equipment). In some examples, the virtual terminal may provide no other functionality than reading and processing data in a tightly integrated hardware module (e.g., a secure element) that may be designed for data security. A virtual terminal system may include a data reader and / or user input / output (I / O) (e.g., a screen / buttons), but may or may not include some or all of the networking configurations for processing the transaction. There are many different potential configurations, all denoted as terminals, with varying degrees of logic included in different areas of the processing chain.

[0020] The technology described herein provides a mobile contactless data transfer device solution that allows a user to accept data transfers using a multi-purpose device (e.g., a mobile device, a smartphone, a tablet, etc.). In some examples, the item / information source may log into the source application (e.g., using source login credentials). Once logged in, the source application may interface with the reader application to facilitate receipt of data for the data transfer transaction. The mobile data transfer technology may be enabled through (1) a third-party mobile data transfer application (source app) that integrates with a first-party (e.g., device-specific) data reader application on the application processor of the source's eligible mobile device using one or more application programming interfaces (APIs) (collectively, front-end integration), and (2) a third-party data transfer system that integrates with a back-end platform (back-end platform) using APIs (collectively, back-end integration). Two separate sets of APIs may be provided, one for third-party developers of source apps and one for data transfer service providers (DTSPs) that contract with the source to facilitate processing of the source's transactions. The source application is source-oriented and may enable the source to accept contactless data transfers from a user using either digital or physical closed-loop transaction equipment or open-loop data transfer equipment.

[0021] The techniques described herein include (1) performing certain authentication checks as required by one or more relevant security standards, etc., to verify the integrity of the data transfer solution (e.g., verifying that the operating system (OS) and various application / kernel configurations on the device processing the data transfer as well as the source eligible device have not been modified); (2) a secure element within the mobile device that is capable of generating (e.g., via ECIES) a transaction-specific shared encryption key (also referred to herein as a transaction key) that the secure element can use to encrypt certain transaction information (e.g., personal data) collected by the secure element from the user's data transfer device (e.g., physical or digital devices on different mobile devices); and (3) the transaction key is then encrypted by the backend platform such that the encrypted transaction information and the encrypted transaction key are used to generate an encrypted transaction blob. (3) the encrypted transaction blob may be sent from the secure element to a data reader application (e.g., an application for the DTSP), where additional metadata may be encrypted by a public key known by the backend platform (also referred to herein as a transport server public key) and then added to the encrypted transaction blob to create an encrypted reader blob; (4) the encrypted reader blob may be sent from the data reader application on the source eligible mobile device (via front-end integration) to the source application, and then from the source application to the DTSP's data transport system, and then from the DTSP's data transport system (via back-end integration) to the back-end platform; (4) upon receiving the encrypted reader blob, the back-end platform may:To verify that the encrypted reader blob has been verified, the metadata in the encrypted reader blob may be decrypted using a private key (also referred to herein as the transport server private key); (5) once verified, the backend platform may decrypt the transaction key (using the PAN server private key) and re-encrypt it using a key encryption key (KEK) (e.g., via ECIES) shared between the hardware security module in the DTSP's data transfer system and the hardware security module ("DTSP HSM") and the corresponding hardware security module of the backend platform via a key exchange process (also referred to herein as a key ceremony) performed during implementation of the backend integration (collectively, "key rewrap"); (5) the encrypted transaction information and re-encrypted transaction key may be sent back to the source's designated data transfer system via the backend integration (in some cases, the source's designated data transfer system may be the DTSP, but in other cases, the source may manage this itself (e.g., integrating directly with the backend API to act as the DTSP)); (6) upon receiving the encrypted transaction information and encrypted shared key, the DTSP may re-encrypt the transaction information and encrypted shared key using a key encryption key (KEK) (e.g., via ECIES) shared between the hardware security module in the DTSP's data transfer system and the hardware security module ("DTSP HSM") and the corresponding hardware security module of the backend platform via a key exchange process (also referred to herein as a key ceremony) performed during implementation of the backend integration (collectively, "key rewrap"); (6) the encrypted transaction information and re-encrypted transaction key may be sent back to the source's designated data transfer system via the backend integration (in some cases, the source's designated data transfer system may be the DTSP, but in other cases, the source may manage this itself (e.g., integrating directly with the backend API to act as the DTSP)); The KEK in the HSM can be used to decrypt the encrypted shared key, and then the decrypted transaction key can be used to decrypt the encrypted transaction information.

[0022] Information about the source's day-to-day business operations (eg, user permissions and transaction history) is sent directly from the DTSP's data transfer system to the source application without going through the backend platform.

[0023] Referring now to the drawings, FIG. 1 illustrates an example block diagram 100 with example systems and components for implementing the virtual terminal technology described herein. The device 110 includes a source app 112 (e.g., an application) that interacts with an SDK 114 to send first data 180 to the reader 120. Prior to receiving the first data 180, the reader 120 can interact with a terminal backend 130 to initialize a virtual terminal 126. The virtual terminal 126 is hosted within a secure element 124. The secure element 124 is a system designed to enhance security as described herein. The secure element 124 receives second data 182 that may detail how the data transfer may be provided to a source associated with the source app 112.

[0024] The virtual terminal 126 can generate transaction data using the first data 180 and the second data 182. The secure element 124 (and the virtual terminal 126) can also communicate with the terminal backend 130 for various security and encryption features described herein to encrypt the transaction data. In some implementations, the secure element 124 communicates with the terminal backend 130 via the reader 120, and the communication is encrypted. The virtual terminal 126 can encrypt the transaction data using a transaction key known only by the virtual terminal 126 and / or the secure element 124. The transaction key is then encrypted by the PAN server public key (corresponding to the PAN server private key held by the terminal backend 130 and / or the rewrap backend 150), as described herein. Thus, the virtual terminal 126 has a transaction key encrypted by the PAN server public key and transaction data encrypted by the transaction key. The virtual terminal can generate an encrypted transaction blob 184 from the encrypted transaction key and the encrypted transaction data. The encrypted transaction blob 184 can include additional metadata. The use of encrypted transaction blobs 184 can prevent transaction data from being exposed outside of the secure element 124 before the DTSP 140 can process the transaction data.

[0025] The virtual terminal 126 then sends the encrypted transaction blob 184 to the reader 120. The reader 120 includes additional metadata about the data transfer encrypted using the transport server public key described herein. The encrypted metadata (using the transport server public key) and the encrypted transaction blob 184 are used to generate the encrypted reader blob 186. In some implementations, the encrypted transaction blob 184 can also be encrypted by the transport server public key. The use of the encrypted transaction blob 184 can allow the rewrap backend 150 to check the encrypted metadata to verify the transaction data without decrypting the transaction data. In some implementations, the combination of the reader 120, the secure element 124, and the virtual terminal 126 can be referred to as a virtual terminal system.

[0026] The reader 120 can send the encrypted reader blob 186 to the source app 112. The source app 112 can send the encrypted reader blob 186 to the data transfer service provider (DTSP) 140 along with an authorization request 188 for the transaction. The DTSP 140 is unable to decrypt some or all of the encrypted reader blob 186 and sends it to the rewrap backend 150 for decryption. In some implementations, the rewrap backend 150 can decrypt the encrypted metadata of the encrypted reader blob 186 using a transport server private key (corresponding to the transport server public key) and verify various portions of the metadata to verify that the encrypted reader blob is authorized by the DTSP 140, the source app 112, and / or the terminal backend 130 as described herein. This allows the rewrap backend 150 to verify the transaction and / or data transfer corresponding to the encrypted reader blob 186 (and associated encrypted transaction blob 184) without seeing the underlying unencrypted transaction data. This can ensure the privacy of the underlying transaction data because the source app 112 and the rewrap backend 150 never decrypt the transaction data encrypted by the transaction key. In some implementations, the rewrap backend 150 can also internally decrypt the encrypted transaction blob 184 to verify and verify various portions of the additional metadata and transaction data.

[0027] Once the rewrap backend 150 verifies the metadata of the encrypted reader blob 186, the rewrap backend 150 can re-encrypt the transaction key with the KEK, which is a symmetric key known by the DTSP, so that the DTSP can decrypt the transaction key (using the KEK) and then decrypt the transaction data (using the transaction key). However, the transaction key is currently encrypted with the PAN server public key. The rewrap backend 150 can decrypt the transaction key using the PAN server private key (which corresponds to the PAN server public key). The rewrap backend 150 then re-encrypts the transaction key with the KEK. In some implementations, the KEK of the rewrap backend 150 may be referred to as the rewrap KEK and the KEK of the DTSP 140 may be referred to as the DTSP KEK. In some implementations, the rewrap KEK and the DTSP KEK are symmetric keys whose functions are essentially identical. The re-encrypted transaction key may be referred to as the rewrapped transaction key. The re-encryption may be referred to as a rewrap.

[0028] The rewrap backend 150 then generates rewrapped encrypted transaction data 192, which includes the rewrapped transaction key and the encrypted transaction data. In some implementations, the rewrap backend 150 can generate the rewrapped encrypted transaction data 192 by encrypting both the transaction key and the encrypted transaction data (encrypted by the transaction key) with a KEK (as described herein). In this manner, the rewrap backend decrypts the various forms of encryption and then re-encrypts the transaction data. The rewrap backend 150 can send the rewrapped encrypted transaction data 190 to the DTSP 140.

[0029] The DTSP 140 can decrypt the rewrapped encrypted transaction data 190 using the KEK and then process the data transfer. In some examples, the data transfer service provider can work with the data transfer processor 160 by sending to the data transfer processor 160 for processing. An example data transfer processor is a payment processor. Once the data transfer is processed or authorized, the data transfer service provider 140 can send an authorization response 192 to the source app 112. This can indicate that the second data has been verified and authorized, the transaction has been authorized, and the transaction has been completed.

[0030] In some cases, the source app 112 is a source-facing application that may be responsible for initiating the data transfer. An exemplary source app is a merchant app that may be responsible for initiating the sale or settlement. The source app may be used to generate the first data 180. In some implementations, the first data 180 may include data regarding the cost of the transaction, a description of the goods or services, a description of the time and place of the transaction, etc. Through the use of the SDK 114, the source app 112 may communicate with the reader 120 and initialize the virtual terminal 126. For example, when a user initiates a transaction, the source app 112 may contact the reader 120 via the SDK 114. In initializing the virtual terminal 126, the reader 120 initializes a particular virtual terminal 126 associated with the source app 112 and the DTSP 140. Thus, different virtual terminals 126 need to be initialized to communicate with different pairs of source apps 112 and DTSPs 140.

[0031] In some examples, the source may be ready to initiate a transaction (e.g., to receive a data transfer), so the user may press "start transaction." Some transactions may involve a payment, such that a user (e.g., a customer) may enter some value (e.g., $10) and press "payment." In response, the system may contact a software development kit (SDK) 114 and invoke a function (e.g., "transact"). In some examples, the SDK 114 is an implementation of the API described above with respect to front-end integration. The SDK 114 may then pass the first data to the reader 120.

[0032] Prior to the transaction, the reader 120 must be initialized and configured as described herein. The reader 120 may be specific to a particular pairing of the source app 112 and the DTSP 140. The reader 120 may then initiate the instrument reader. The instrument reader may be an application (e.g., corresponding to a second application when the source app is the first application) and may control a user interface (UI) of the device 110 that presents an instrument reader UI. In some examples, the instrument reader UI may be presented above the source app UI, and the instrument reader UI may display information to the user identifying the requested data value (e.g., $10), the name of the source, and how / where to place the instrument (e.g., where to tap the user's instrument). In some implementations, the instrument reader is a card reader. In some cases, a source logo or a default logo (e.g., based on a merchant category code (MCC)) may be displayed.

[0033] In some implementations, the device can be a payment device or card (e.g., a credit card, a digital wallet application containing digital payment information, etc.). In some implementations, the device can be read by a device reader and the second data 182 is sent to the secure element 124 for processing. In some implementations, the reader 120 never receives the second data 182. In some implementations, the reader 120 never receives the second data 182 in an unencrypted form.

[0034] The secure element 124 receives both the first data 180 and the second data 182. The secure element 124 is designed for data security and ensures the security and integrity of the transaction data as described herein. The secure element 124 hosts the virtual terminal 126. The virtual terminal 126 generates the transaction data from the first data 180 and the second data 182. The virtual terminal 126 can apply several layers of security and encryption as described herein. The virtual terminal 126 can encrypt the transaction data with a key known only by the secure element 124, known as the transaction key. The secure element then encrypts the transaction key using the PAN session public key. The virtual terminal 126 receives / generates the PAN session public key during initialization of the virtual terminal 126 as described herein. The PAN session public key corresponds to the PAN session private key held by the terminal backend 130 and / or the rewrap backend 150. In some implementations, the PAN session public key is used to encrypt additional metadata. The encrypted transaction data (encrypted by the transaction key), the encrypted transaction key (encrypted by the PAN session public key), and additional metadata are used to generate an encrypted transaction blob 184. The metadata may include various security and encryption information in addition to the transaction data, and may also be encrypted. The metadata may also include other data such as a description of the time and location of the transaction, an encryption description and time, etc.

[0035] After the secure element 124 generates the encrypted transaction blob 184, it can send the encrypted transaction blob 184 (sometimes referred to as an encrypted blob) back to the reader 120. The reader 120 can then add additional metadata and further encryption to generate an encrypted reader blob 186. The metadata can be used to verify the transaction. In some implementations, the metadata is encrypted with a transport server public key, but the encrypted transaction blob 184 is not further encrypted. The transport server public key can be generated during initialization of the reader 120 and corresponds to a transport server private key held by the terminal backend 130 and / or the rewrap backend 150. The reader 120 can send the encrypted reader blob 186 to the source app 112, and the device reader application UI can be closed with the source application running (and displayed on the UI), and the source application has the encrypted reader blob 186. In some embodiments, the device reader application UI is closed once authorization for the transaction is received by the source app 112.

[0036] Because the encrypted transaction blob 184 is encrypted with a transaction key known only by the virtual terminal 126, the source app 112 and the DTSP 140 cannot decrypt the transaction data. Further explanation of the encryption performed on the transaction data by the virtual terminal 126 of the secure element 124 is described herein.

[0037] There are two system backends that cooperate with the virtual terminal to encrypt and decrypt transaction data. The system backends can provide security for the data in accordance with security standards (e.g., PCI CPoC standards (collectively, CPoC Validation)). The first backend can be referred to as the terminal backend 130 or contactless payment (Customer off-the-shelf Device (COTS)) (CPOC) (which may also be referred to as a Mobile Payment on COD (MPOC) backend). The terminal backend 130 can also be referred to herein as a device reader backend. In some implementations, the terminal backend 130 is configured to initialize the virtual terminal 126 prior to data transfer (e.g., of a device or other data transfer device). As part of the initialization, the terminal backend 126 can verify and / or perform a number of required initialization processes as described herein. These initialization processes can include verifying the virtual terminal token, generating a session token, sending the virtual terminal configuration to the secure element, performing authentication checks, etc., as described herein.

[0038] The second backend may be referred to as a rewrap backend 150, an equipment data processor backend, or a data transfer rewrap backend. The rewrap backend 150 handles the rewrap process using the transport server private key to decrypt the encrypted reader blob 186 and inspect the metadata therein, as described herein. Using the metadata, the rewrap backend may verify that the data transfer was authorized by the DTSP 140, the source app 112, and / or the terminal backend 130. In addition to the metadata, the encrypted reader blob 186 also includes an encrypted transaction blob with an encrypted transaction key (encrypted by the PAN session public key) and encrypted transaction data (encrypted by the transaction key). Once the metadata is verified, the rewrap backend 150 may decrypt the encrypted transaction key (encrypted by the PAN session public key) using the corresponding PAN session private key. The rewrap backend 150 then re-encrypts the transaction key using the KEK to generate a re-encrypted transaction key. The re-encrypted transaction key and the transport key encrypted transaction data may be referred to as re-wrapped encrypted transaction data 190, which may be decrypted by the DTSP 140. Referring again to the virtual terminal 126 and associated terminal backend 130, the terminal backend 130 cooperates with the virtual terminal 126 to securely encrypt the transaction data within the secure element 124.

[0039] After receiving the encrypted reader blob 186 from the reader 120, the source app 112 can send the encrypted reader blob 186 along with an authorization request 188 to the DTSP 140 to determine if the transaction is authorized. In some examples, the DTSP 140 may be the same entity that created the source app 112, or may be controlled by the same entity, however, may be a completely different entity. For example, the source may create an account on the source app 112, such that the source does not own the source app, but uses the source app to facilitate data transfer and other data transfer issues. The source app 112 may then be operated by the same or a different entity as the DTSP 140.

[0040] In some implementations, the DTSP 140 cannot decrypt the encrypted leader blob 186 upon receipt from the source app 112 because the decryption keys (transport server private key and PAN server private key) of the encrypted leader blob 186 are not known to the DTSP 140. This is part of the security of the encryption of the transaction data. Similarly, the source app 112 does not have the key to decrypt the encrypted leader blob 186. These features help ensure the security of the encrypted leader blob 186. However, the DTSP 140 can send the encrypted leader blob 186 to the rewrap backend 150 for decryption.

[0041] In some examples, a DTSP may be a payment service provider such as a bank (or, alternatively, a bank affiliate), or a corporate entity such as an acquirer processor or payment facilitator or aggregator that is unlicensed or licensed as a non-bank financial institution (such as a money transmitter). In addition, transaction information may be transmitted: (1) from the user, through the user's payment device, to a secure element in the source's (e.g., merchant's) mobile device, (2) from the secure element to the card reader application, (3) from the card reader application to the source application via a front-end integration, (4) from the source application to the DTSP's payment system, (5) from the DTSP's payment system to a back-end platform via a back-end integration, (6) from the back-end platform to the DTSP's payment system via a back-end integration, (7) (a) from the DTSP to the acquirer processor to the payment network if the DTSP is not an acquirer processor (e.g., a payment facilitator or payment aggregator), or (b) from the DTSP directly to the payment network if the DTSP is an acquirer processor, (8) from the payment network to the issuing bank or issuer processor for authorization, and / or (9) directly back to the source app through the DTSP's system along with the authorization results. In some implementations, neither the application / device provider nor the back-end platform sees any of the consumer's sensitive payment information.

[0042] The rewrap backend 150 accesses the appropriate keys (transport server private key and PAN server private key) to decrypt the encrypted reader blob 186. In some implementations, the rewrap backend 150 can use the corresponding private key (for the public key used to encrypt the encrypted reader blob 186 and the encrypted transaction blob 184) that encrypted the encrypted transaction key used to encrypt the transaction data, encrypt it with a key known by the DTSP, and return the rewrapped encrypted transaction data 190 to the DTSP. This is called rewrapping and is covered in more detail below. In some implementations, rewrapping can mean that the "transaction key" can be unwrapped by decrypting the transaction key via the PAN session private key (corresponding to the PAN session public key used to encrypt the transaction key) and rewrapped using the backend KEK. The DTSP can unwrap the transaction key using the DTSP KEK (corresponding to the backend KEK). The DTSP can then use the transaction key to decrypt the transaction data. Once this process is complete, the DTSP may have the transaction data for the data transfer and may process the data transfer using the data transfer processor.

[0043] When the rewrap backend 150 decrypts the encrypted reader blob 186, it can perform a specific verification of the metadata in the encrypted reader blob 186. If the verification is verified, the rewrap backend 150 can use the PAN server private key to decrypt the encrypted transaction key of the encrypted transaction blob 184. The rewrap backend 150 can rewrap the transaction key using the rewrap KEK (corresponding to the DTSP KEK) and generate the rewrapped encrypted transaction data 190 from the encrypted transaction data and the rewrapped transaction key. In this way, the DTSP 140 that has access to their specific DTSP KEK (corresponding to the rewrap KEK) can decrypt the rewrapped transaction key of the rewrapped encrypted transaction data 190. The rewrapped transaction key can be used to decrypt the encrypted transaction data. The rewrapped encrypted transaction data 190 can also be referred to as the rewrapped transaction data or the rewrapped transaction blob. This step of re-encrypting the transaction data on the rewrap backend 150 such that the transaction data is encrypted for decryption by the DTSP 140 may be referred to as rewrapping. The rewrap backend 150 may include a Hardware Security Module (HSM). Some or all of the encryption and decryption performed on the rewrap backend 150 may occur within the HSM. Further description of the rewrap backend 150 and the processes performed by the rewrap process described herein.

[0044] In some implementations, if the confirmation is verified, the rewrap backend 150 can use the PAN server private key to decrypt the encrypted transaction key of the encrypted transaction blob 184. In some implementations, the encrypted transaction data can be decrypted using the transaction key to confirm / verify the transaction data. In some implementations, if the transaction data is confirmed and / or verified, the rewrap backend 150 can encrypt the transaction key using a rewrap KEK (corresponding to the DTSP KEK) and re-encrypt the transaction data using the transaction key to generate rewrapped encrypted transaction data 190.

[0045] The DTSP 140 can then decrypt the rewrapped encrypted transaction data 190 upon receipt. In some embodiments, the decryption of some or all of the rewrapped encrypted transaction data 190 occurs on the DTSP Control HSM (DTSP HSM). The DTSP 140 can then process the transaction data. For example, the DTSP 140 can determine whether the second data 182 is payment information and whether there are sufficient funds associated with the second data 182. The DTSP 140 can also send the transaction data to another party for processing, such as the data transfer processor 160. Once the DTSP 140 (or the data transfer processor 160) processes the transaction data, the DTSP 140 can send an authorization response 182 to the source app 112. The authorization response 192 can indicate whether authorization is granted or denied for the transaction.

[0046] Upon completion, a message can be sent back to the source application indicating whether the data transfer was approved or not. In addition, other information regarding the source's day-to-day business operations (e.g., user permissions and transaction history) can be sent directly between the DTSP and the source app.

[0047] 2 illustrates a sequence diagram 200 of an exemplary high-level sequence for implementing the virtual terminal techniques described herein. The exemplary sequence includes transmitting and processing data on a virtual terminal 202, a reader 204, a source app 206, a DTSP 208, and a rewrap backend 210. The virtual terminal 202, the reader 204, the source app 206, the DTSP 208, and the rewrap backend 210 correspond to the virtual terminal 126, the reader 120, the source app 112, the DTSP 140, and the rewrap backend 150, respectively, of FIG. 1. As previously discussed, the virtual terminal 202, the reader 204, and the secure element may be referred to as a virtual terminal system.

[0048] Prior to the start of the example sequence diagram 200, the DTSP 208 and the backend (e.g., the terminal backend 126 and / or the rewrap backend 210 of FIG. 1) may exchange keys used to encrypt and decrypt communications and transmissions between the DTSP 208 and the rewrap backend 210. In some implementations, these keys may be symmetric keys. In some implementations, these keys may be key exchange keys (KEKs). In some implementations, these keys may be symmetric KEKs. These keys are known only by the DTSP 208 and the rewrap backend 210. The KEK for the DTSP 208 is known as the DTSP KEK. The KEK for the rewrap backend 210 is known as the backend KEK.

[0049] At block 220, the source app 206 can initiate the transaction by sending first data to the reader 204. The first data can be generated in the source app 206. For example, a source can input the first data to the source app 206. The first data can include data transfer parameters. The source app 206 can transmit the first data to the reader 204.

[0050] In block 222, the reader 204 can prompt the user to the device. The prompt can be a request for the second data. For example, the reader 204 can present a UI that prompts the user to present a data transfer instrument (e.g., tap, swipe, or insert a credit card, debit card, or device that hosts a digital wallet), the data transfer instrument having the second data.

[0051] In block 224, the reader 204 may send a signal to the virtual terminal 202 that a transaction has begun. The reader 204 may also send the first data. When the user provides the second data, the virtual terminal 202 may obtain the second data. Once the second data is received, it may be used to generate transaction data.

[0052] In block 226, the virtual terminal 202 may then generate transaction data from the first data and the second data. The virtual terminal 202 may then encrypt the transaction data using a transaction key to generate encrypted transaction data. The transaction key is generated in the virtual terminal 202 and / or the secure element such that only the virtual terminal 202 and / or the secure element knows the transaction key. The transaction key is then encrypted using the PAN server public key. The PAN server public key corresponds to the PAN server private key held by the terminal backend and / or the rewrap backend 210. The PAN server public key is obtained during initialization of the virtual terminal 202 as described herein. Additional metadata may be added to the encrypted transaction data to generate an encrypted transaction blob. This encryption may occur within the secure element of the device and / or the virtual terminal 202 of the secure element.

[0053] Once the virtual terminal 202 generates the encrypted transaction blob, the virtual terminal 202 and / or the reader 204 can relinquish control of the device's UI. In some implementations, the relinquishment of the device's UI can occur at a later time. For example, the relinquishment of the device's UI can occur after the transaction has been authorized by the DTSP 208 and / or at block 244 of the example sequence 200.

[0054] In block 228, the virtual terminal 202 can send the encrypted transaction blob to the reader 204. The encrypted transaction data can include other confirmation, verification, and encryption data in addition to the transaction data for the underlying transaction. In block 230, the reader 204 can then generate additional metadata and encrypt the metadata using a transport server public key. The transport server public key corresponds to a transport server private key held by the rewrap backend 210 and / or the terminal backend. The encrypted metadata and the encrypted transaction blob are used to generate an encrypted reader blob. The additional metadata can include a session token. The second encryption is designed to protect the integrity and confidentiality of the transmission via the source app 206 to the DTSP 208. The reader 204 can then send the encrypted reader blob to the source app 206. In block 232, the source app 206 sends the encrypted reader blob and an authorization request to the DTSP 208 requesting authorization for the transaction.

[0055] In block 234, the DTSP 208 can send the encrypted leader blob to the rewrap backend 210. In some implementations, the DTSP 208 cannot decrypt the encrypted leader blob and must send it to the rewrap backend 210 for decryption. In some implementations, the DTSP 208 can decrypt a portion of the encrypted leader blob to verify and verify certain information. In some implementations, the DTSP 208 can re-encrypt (e.g., re-wrap) the encrypted transaction data after this verification.

[0056] In block 236, the rewrap backend 210 may decrypt some or all of the encrypted leader blob to verify certain information as described herein. The rewrap backend 210 may decrypt the metadata in the encrypted leader blob to verify and validate the transaction. The rewrap backend may decrypt the metadata using the transport server private key (which corresponds to the transport server public key). For example, the rewrap backend 210 may verify the session token. If the verification fails, the rewrap process does not proceed.

[0057] Once the rewrap backend 210 verifies the transaction after decrypting the metadata, the rewrap backend 210 can rewrap the encrypted transaction key. The rewrap backend 210 begins by decrypting the encrypted transaction key using the PAN server private key that corresponds to the PAN server public key used to encrypt the transaction key. The rewrap backend 210 can then rewrap the transaction key using a KEK (e.g., the rewrap backend 210's KEK from the symmetric KEK exchanged between the rewrap backend 210 and the DTSP 208). The rewrap backend 210 can then package the rewrapped transaction key (now encrypted by the KEK, not the PAN server public key) and the encrypted transaction data to generate a rewrapped transaction blob. At 228, the rewrap backend 210 can send the rewrapped transaction blob (also referred to as rewrapped transaction data or rewrapped encrypted transaction data) to the DTSP 208. In some implementations, some or all of the decryption performed by the rewrap backend 210 occurs in the HSM of the rewrap backend 210.

[0058] In some implementations, the rewrap backend 210 must decrypt the encrypted reader blob to find the encrypted transaction blob and verify certain information, as described herein. In some implementations, the rewrap backend can decrypt the encrypted transaction blob and verify certain information, as described herein.

[0059] At block 240, the DTSP 208 can process the transaction. In some implementations, the DTSP 208 can process the transaction and data transfer by sending the transaction or information associated with the transaction and / or data transfer to a third party. At 242, the DTSP 208 can return a transaction result to the source app 206. At 244, the source app 206 can display a data transfer response on the device hosting the source app 206.

[0060] FIG. 3 illustrates exemplary system components 300. The system components may include components on the device 310 and components in the backend 330. The device 310 includes a reader 312 and a secure element 320. The reader 312 is hosted on the typical hardware of the device (e.g., the processor used for most or all applications). There is also a secure element 320 that hosts a virtual terminal 322. The backend 330 represents a device external to the server device or general-purpose device. The device 310, reader 312, secure element 320, virtual terminal 322, rewrap backend 340, and terminal backend 350 correspond to the device 110, reader 120, secure element 124, virtual terminal 126, rewrap backend 150, and terminal backend 130 of FIG. 1, respectively.

[0061] In some implementations, the reader 312 is implemented in software using some or all of the hardware components of the general-purpose device. The reader 312 may run on the device's processor along with other applications and processes. The reader 312 may also include cryptographic services as described herein.

[0062] The reader 312 includes a prompt UI 314. The prompt UI 314 is used to indicate that the virtual terminal 322 is ready to receive second data from the user. For example, the prompt UI 314 can be used to indicate that the user should submit the second data. In some implementations, the prompt UI 314 can be used to indicate that the user should swipe, tap, or insert a card, or use some type of digital wallet on the mobile device. The prompt UI 314 can be used to indicate where on the multipurpose device the user should submit the second data. For example, the prompt UI 314 can indicate to the user where on the multipurpose device they should tap their card.

[0063] The reader 312 also includes a daemon 316 and an instrument reader 318. The daemon 316 may be used to execute processes and generate data associated with the device 310 that is not processed by the secure element 320. The daemon 316 may also be used to process second data obtained by the instrument reader 318. The instrument reader 318 is used to read the second data from the user and process the second data.

[0064] The device 310 may also include a secure element 320. The secure element 320 is an element designed for security on the general-purpose device. In some implementations, the secure element 320 is a separate chip or hardware module from the device's processor. For example, the secure element 320 may be running on a separate chip from the processor that runs the reader 312. In some implementations, the secure element 320 is a software module that includes additional software security features for running processes that the reader 312 does not use. In some implementations, the secure element 320 is used specifically only by the device 310 and runs only processes associated with the device 310. In some implementations, the secure element 320 runs some processes associated with the device 310 and also runs processes for other applications on the general-purpose device that require additional security features.

[0065] The secure element 320 houses a virtual terminal 322. The secure element 320 can house multiple virtual terminals 322 corresponding to different pairs of source apps and DTSPs. The virtual terminal 322 has a virtual terminal kernel (also called a terminal kernel) that is configurable by a kernel token. The virtual terminal 322 is designed to encrypt data. For example, the virtual terminal 322 encrypts transaction data generated from the second data and the first data. The virtual terminal 322 can use many types of keys, hashes, and other cryptography when encrypting data. Examples of encryption performed by the virtual terminal 322 are included herein.

[0066] Backend 330 represents system components that are not stored on device 310. In some implementations, backend 330 represents one or more devices that typically have server functionality. Backend 330 can include rewrap backend 340 and terminal backend 350. Terminal backend can include API gateway 368, kernel manager 360, authorizer 362, authentication subsystem 364, and monitoring subsystem 366.

[0067] The rewrap backend 340 receives encrypted transaction data from the DTSP (e.g., the encrypted reader blob 186 of FIG. 1), decrypts some or all of the encrypted transaction data (e.g., the metadata of the encrypted reader blob 186 of FIG. 1 and the encrypted transaction key), verifies some or all of the transaction data (e.g., the metadata of the encrypted reader blob 186 of FIG. 1), and then re-encrypts some or all of the transaction data (e.g., the transaction key after it has been decrypted using the PAN server private key) with a KEK associated with the DTSP. The rewrap backend 340 and the processes performed by the rewrap backend 340 are described further herein.

[0068] The API gateway 368 is used to mediate interactions between the device 310 and the terminal backend 350. For example, the API gateway 368 mediates communication, interactions, and transmissions between the device 310 and the kernel manager 360, the authorizer 362, the authentication subsystem 364, and the monitoring subsystem 366.

[0069] The kernel manager 360 can be used to create and generate kernel tokens. The kernel manager 360 can also be used to generate scripts for the configuration of the virtual terminal 322 in the secure element 320 of the device 310.

[0070] The authorizer 362 can be used to authorize DTSPs, sources, and devices to use the virtual terminal system. This ensures that only DTSPs, sources, and devices that are accepted to use the virtual terminal system can use the techniques described herein. Authorization can include the use of tokens, keys, accounts, credentials, etc.

[0071] The authentication subsystem 364 may be used to authorize and verify devices (e.g., mobile devices and servers) using the virtual terminal system. The authentication subsystem 364 is part of a security system designed to prevent hacking or fraudulent use of the virtual terminal system to create fake transactions or hijack existing transactions. Hijacking a transaction may include altering any transaction data associated with a transaction such that the transaction data does not exactly match or correspond to the transaction.

[0072] The monitoring subsystem 366 may be used to monitor transactions and devices (e.g., virtual terminals 322 and readers 312) using the virtual terminal system described herein. Monitoring transactions may be important for compliance with CPOC and other regulations involving wire transfers, transactions, etc., and related devices.

[0073] 4 shows an example method 400 for initializing readers and virtual terminals. However, before a device can create readers and virtual terminals, there are several initialization steps. If a source app wants to use virtual terminals and readers on the device (e.g., instead of a dongle), the source app needs to register with the DTSP. The DTSP assigns and / or uses terminal profiles to organize the configuration data of different types of sources.

[0074] A terminal profile can consist of a set of personal enrollment data that is used to configure a reader before the reader processes any transactions. All personal enrollment data can be provided by a single terminal profile. The personal enrollment data can also be used to configure the virtual terminal 322 of FIG. 3. Examples of configuration data for a profile include what types of instruments are accepted (e.g., payment instruments such as Visa, MasterCard, etc.) and / or what the maximum amount acceptable for a single transaction is. Once a profile is created, it can be immutable, such that a new reader needs to be created to have a new terminal profile. In some examples, the DTSP is responsible for providing all the required configuration values ​​to create the terminal profile.

[0075] In some implementations, the DTSP can create the terminal profile itself. In some implementations, a backend (e.g., backend 330 in FIG. 3) can generate the terminal profile and share possible terminal profiles with the DTSP. The DTSP can request a new terminal profile with various configuration data. In some implementations, each new terminal profile has an associated profile ID. This profile ID can be stored by the DTSP for future use.

[0076] The DTSP can have multiple terminal profiles that can be used for one or more sources. The DTSP can keep track of which sources have which profiles. The DTSP can request a profile and the backend can return a profile ID. In some cases, the backend can generate the profile and the associated profile ID. The backend can upload the profile ID onto a web portal for use by the DTSP. The DTSP must log into a portal provided by the backend. From there, the DTSP can find all profile IDs created for it. In some examples, there can be a shared profile that all sources use on the mobile device, or there can be one profile per source, as needed. In some cases, the profile is a file with the commands necessary to configure the kernel token with the correct configuration. The kernel token is used for configuration of the secure element's virtual terminal and the cryptographic keys used by the virtual terminal (e.g., the PAN server public key).

[0077] Once the DTSP has determined which device profile to assign to the source, the DTSP sends the corresponding device profile ID to the source app. The source app needs to reference the device profile ID to the DTSP to initialize the reader according to the appropriate device profile ID used by the DTSP. Thus, the reader can be specific to a particular DTSP. For example, a multi-purpose device can have a first reader associated with a first DTSP and a second reader associated with a second DTSP. In some implementations, the DTSP allows the source to have a reader. A source (e.g., a store owner) can set up an account with a source application (e.g., a mobile application that allows businesses to receive money from customers). The source can then register with the DTSP. In some implementations, the source can use the source's credentials along with the source application to register with the DTSP. After the source is registered, the source can request permission from the DTSP to generate a reader associated with that DTSP. Typically, the DTSP wants the source to use a particular type of reader that is communicated via the device profile.

[0078] When the device reader is initialized, a device reader ID is returned to the source app. This device reader ID is linked to the lifecycle of the source app on the device. In some implementations, a new device reader ID may be generated when the application is uninstalled and reinstalled. In some implementations, the device reader ID is unique for each source app installed on the same device. In some implementations, the device reader ID is persisted between device reader initializations. In some implementations, when a source app initializes a device reader on two different devices, each installation on each device can have a unique device reader ID. In some implementations, the device reader ID can be a concatenation of the device serial number and the application ID (plus, in some implementations, the installation ID).

[0079] Returning to FIG. 4, the source app 404 needs to request a reader token to generate a reader 406 associated with the DTSP 402. The reader token can also be referred to as a partner token or a DTSP token. The reader token can include configuration information for the reader. The configuration information can include a DTSP ID, an expiration field, a terminal profile ID, an allowed app bundle ID, and an allowed virtual terminal ID. The expiration field is used to determine the expiration time of the reader token, which will terminate the reader 406 on the device and also the virtual terminal on the device. The DTSP ID can be used to identify the particular DTSP that issued the reader token. The terminal profile ID is used to configure the terminal kernel of the reader 406. The allowed app bundle ID indicates which source app (e.g., source app 404) can use the reader token. The allowed virtual terminal ID indicates which virtual terminal ID is allowed to use this reader token. In some implementations, the allowed virtual terminal ID corresponds to the reader ID.

[0080] In block 410, the source app 404 can request a reader token from the DTSP 402. The source app 404 can include the assigned terminal profile ID in the request for the reader token. Because the source app 402 requested the source login credentials before the reader initialization, the DTSP 402 knows (using the source app 402) which source is requesting the reader token. Thus, the DTSP 402 can know the terminal profile ID that it would normally give to the source app 402, and can know that the source app 404 is initializing the reader 406 at this point. In block 412, the DTSP 402 can generate a reader token. The reader token can be generated with a particular terminal profile.

[0081] The reader token is used to securely pass information between the DTSP 402 (e.g., the DTSP's backend system) and the reader 406. The most important information that needs to be communicated between the DTSP 402 and the reader 406 is the terminal profile ID associated with the reader 406. Using the reader token mechanism, the DTSP can indicate the terminal profile that can be used to initialize the reader. In some implementations, the reader token can be used to determine the lifespan of the reader by setting a token expiration date. When the token expires, the reader can be automatically terminated. In some implementations, the reader token can be used to specify a particular source app that is the user of the token by referencing the source app ID associated with the source in the reader token.

[0082] All reader tokens can be signed with any type of cryptographic algorithm (e.g., ES256, etc.) using one or more keys (e.g., ECDSA keys). A private key must be used by the DTSP to sign the token, and the associated public key must be shared with the terminal backend and / or rewrap backend.

[0083] The reader token has multiple uses. The reader token protects the data that is to be sent because it is bound to the DTSP 402 and therefore authenticates that the reader and the corresponding transaction are bound to that particular DTSP 402. This is because the DTSP 402 must ultimately request that the data transfer data be decrypted, and therefore the rewrap backend wants to be sure that the DTSP 402 has authorized the initiation of the data transfer. In some implementations, every DTSP 402 can have a different signature for signing the reader token. Each DTSP 402 can sign different reader tokens and can use multiple different terminal profiles. Through a gateway associated with the terminal backend 408 and the rewrap backend, the DTSP can upload public keys for use by the terminal backend 408 and the rewrap backend for encryption. This same gateway also allows the DTSP 402 to browse, read, request, and modify the various terminal profiles that can be used by the DTSP 402. The source app 404 can then request a reader token from the DTSP 402, essentially requesting permission to have a reader initialized (for that source to use). Based on the source login, the DTSP knows which source is requesting a reader be prepared. The source app then fetches a source login token for the user, based at least in part on those login credentials. The DTSP 402 can determine which terminal profile the source should use and put the appropriate profile into the reader token and sign it. The token can also contain information about how long the device reader is available, whether to bind it to a device reader ID (also referred to herein as a terminal ID), and other details that the DTSP 402 controls.The DTSP 402 then returns the token to the source app 404, which can then make a "prepare" (or "initialize") call to initialize the reader by using an SDK (e.g., SDK 114 in FIG. 1). Here, the source application can use the SDK to pass in the reader token and initialize the reader 406.

[0084] The reader token can include data that identifies it as a reader token from a particular DTSP 402 (as opposed to another DTSP 402). In some implementations, the DTSP 402 can also sign the reader token. To protect the integrity of the device profile and avoid misuse (or device profile swapping), the DTSP backend asks the DTSP 402 to sign the reader token and / or the corresponding device profile ID (in some examples, the partner signs the device profile ID to indicate that the DTSP 402 intends to use the device profile referenced by the device profile ID). It is not desirable for the source to swap its profile. Since the profile passes through the source app, a hacker could try to modify the profile. One way for the partner to protect the integrity of the reader token and device profile ID is to create and sign a JWT token that includes the device profile ID. This token is called the reader token. This token can be used as an API key. When the reader receives the reader token, it can verify the signature of the token. By verifying the signature of the token, the backend can authenticate the DTSP 402 (to see which DTSP 402 is initializing the terminal). This works because only the DTSP 402 has the private key to sign the token, and the backend has a table of public keys that associates them with the DTSP. By authenticating, the mobile device can decide whether to allow the DTSP 402 to make a transaction.

[0085] In block 414 , the DTSP 402 may return a valid reader token to the source app 404 so that the source app 404 can begin creating readers associated with the particular DTSP 402 .

[0086] In block 416, the source app 404 can initialize the reader 406 using the reader token. The reader 406 initialization is done by calling an SDK (e.g., SDK 114 in FIG. 1) to initialize the reader 406 using the reader token. When requesting reader initialization, the reader token of the source app 404 can include a terminal profile ID. This terminal profile can be used to initialize the context of the reader and inform how the reader should be configured. When the reader is initialized, it is bound to the terminal profile, source ID, device reader ID, and the specific DTSP used during initialization. Any transactions performed on the reader can use the personal registration data associated with the terminal profile. To change the terminal profile, the reader needs to be reinitialized with a different profile ID. The terminal profile can be specified by the reader token received from the DTSP 402 by the source app 404 before the device reader initialization. Once the reader 406 initialization is successful, only the source application that initialized the device reader can use it. If another app tries to use it, the reader 406 will automatically exit.

[0087] In block 418, the reader 406 opens a session with the terminal backend 408. The reader 406 can send the reader token along with other configuration and authentication information to the terminal backend.

[0088] At block 420, the terminal backend 408 can verify the reader token. This verification of the reader token can include multiple steps. The terminal backend can also be referred to herein as a device data processor backend or a device reader backend. The terminal backend 408 looks at the reader token and verifies that it is valid. The device reader backend can determine if the reader token is valid by checking if any information in the reader token has changed. In some implementations, the verification process can include verifying a DTSP signature associated with the reader token. In some implementations, the verification can check an expiration date or expiration time of the reader token to determine if the reader token has expired. The verification can also include verifying the payload of the reader token. In some implementations, the verification can include verifying the app bundle ID, the virtual terminal ID, and the terminal profile ID. Once the terminal backend 408 performs validation on the virtual terminal token that the device and reader tokens are valid, the terminal backend 408 can enable the device reader (and / or device reader application) to initialize the virtual terminal using the kernel token.

[0089] Validating the reader token may also include part of an authentication process. An example sequence diagram 500 for authentication is shown in FIG. 5. The authentication process occurs during initialization of the reader 502. In some implementations, the authentication process is part of validating the reader token, as seen in block 420 of FIG. 4. The authentication process is designed to help any backend service (e.g., provided by the terminal backend 504 or the rewrap backend) know which device is making a call or requesting information from the backend service. In some implementations, the authentication process is designed to authenticate a specific device and / or a specific reader on a specific device. Authentication of a specific device may also refer to authentication of the secure element of the device or the terminal kernel within the secure element of the device. Authentication is also important for regulatory, security, and privacy reasons as part of implementing the standards for CPOC.

[0090] In block 512, the reader 502 requests a device identification certificate from the terminal backend 504. In some implementations, the certificate is a Secure Element Authentication Service (SEAS) certificate. The device identification certificate creates a unique identifier of a specific secure element of a specific reader on a specific device. The device may already have such a unique identifier, so the reader 502 may send the unique identifier (e.g., Secure Element ID (SEID)) to the terminal backend 504 to receive a certificate containing the unique identifier. In some implementations, the issuance of the certificate may originate from a well-known certificate authority and use such rules. In some implementations, the issuance of the certificate depends on passing a device check on the reader 502. Overall, the device identification certificate is meant to verify that the specific secure element / reader / device is an authorized device. In block 514, the reader 502 receives the certificate from the terminal backend 504.

[0091] At block 516, the reader 502 generates a baseline package for the reader 502. The baseline package may include baseline data about the device on which the reader is operating. The baseline data may also include information about the secure elements of the device. The baseline package is used to verify that the device is consistent. The baseline package may also include a device identification certificate. The baseline package may also include a signature from the reader 502. At block 518, the reader 502 sends the baseline package to the terminal backend 504 for verification. In some implementations, the portion of the terminal backend 504 that is processing this verification is different from the portion of the terminal backend 504 that processed the device identification certificate.

[0092] In block 520, the terminal backend 504 validates the baseline package. The terminal backend 504 verifies that the signature from the reader 502 is valid. The terminal backend 504 verifies that the device identification certificate is valid, for example, by verifying the ID of the device identification certificate. The terminal backend 504 validates the baseline data. For example, the terminal backend 504 can determine whether the baseline data is consistent with a baseline data format. The terminal backend 504 can also determine whether the baseline data is consistent with a particular secure element, reader, and / or device.

[0093] In block 522, the terminal backend 504 sends the verification result to the reader 502. If the verification fails, the authentication fails. In some implementations, this causes the reader 502 to fail initialization. If the verification is successful, the terminal backend 504 sends the authentication public key to the reader 502. The terminal backend 504 has an authentication private key that can be used to decrypt the authentication information from the reader 502.

[0094] In some implementations, blocks 512, 514, 516, 518, 520, 522, 524, 526, 528, and 530 of the authentication process 500 are performed by the device in parallel with blocks 410, 412, 414, and 416 of Figure 4. In such implementations, blocks 512, 514, 516, 518, 520, 522, 524, 526, 528, and 530 are implemented by a processor of the device to ultimately pass all authentication related data to the reader 506. In some implementations, the reader 406 can include the authentication token when the reader opens a session with the terminal backend 408 in block 418 of Figure 4.

[0095] At block 532, the reader 502 performs an authentication check to generate an authentication result. The authentication check can include verifying device-related information. In some implementations, the authentication check includes verifying that the device identification certificate is still valid. In some implementations, the authentication check verifies that the metadata of the transaction blob being attested has information (e.g., SEID, device ID, etc.) that matches the reader 502.

[0096] At block 534, the reader 502 generates a cipher by encrypting the authentication result of the authentication check and the authentication public key. At block 536, the cipher is added to the reader's 502 authentication entry list.

[0097] In block 530, the reader 502 signs the authentication entry list with the private key associated with the device identification certificate in preparation for requesting an authentication token. In block 532, the reader 502 sends an authentication token request to the terminal backend 504. The authentication token request includes the signature of the authentication entry list, the result of the authentication check, and the device identification certificate.

[0098] In block 534, the terminal backend 504 validates the authentication entry list. The validation begins by validating the signature of the authentication entry list. Because the signature was based on the device identification certificate, the terminal backend 504 can validate the device identification certificate and verify that the signature matches. Then, for each entry in the authentication entry list, the terminal backend 504 can decrypt the entry using the authentication private key. Then, the terminal backend 504 validates the entries in the authentication entry list by comparing the entry to the baseline package.

[0099] In block 536, the terminal backend 504 can send the verification result to the reader app 502. If all authentication entries are verified, the verification result can include an authentication token. The authentication token is used to indicate that the device is a verified device. If any of the authentication entries cannot be verified, the authentication fails. The verification result can indicate this failure and can provide an explanation for the authentication failure. In some implementations, the authentication token has an expiration date. In some implementations, the authentication token can expire after 15 minutes.

[0100] Returning to FIG. 4, in block 422, both a session token and a kernel token may be generated by the terminal backend 408 after the reader token and the authentication token are verified. In some implementations, the reader token and the authentication token are used to generate a session token. In some implementations, the session token is used to verify a particular instance of the reader 406. In some implementations, the session token is used to process a particular transaction between the source app 404 and the DTSP 402. The session token may include a virtual terminal ID. The virtual terminal ID may be based on one or more of a secure element ID (SEID), an app bundle ID, and an app installation ID. The SEID may be used to identify a secure element that will encrypt transaction data related to the reader 406. The secure element ID may be obtained from the authentication token (e.g., with reference to FIG. 5). The app bundle ID may be used to identify an app that is using the reader 406. The app installation ID may be used to identify which instance of the app is using the reader 406. For example, if an app is uninstalled and reinstalled on a device, a new app installation ID will be present. The session token may also include a DTSP token. In some implementations, the DTSP token is a reader token. The session token can be concatenated with an encrypted transaction blob generated by the virtual terminal on the secure element, which can be checked by the rewrap service at the time of rewrapping. If the session token is invalid, the rewrap fails and the transaction is rejected or fails.

[0101] The kernel token is used to configure the kernel of the virtual terminal initialized by the reader 406. The kernel token may include a terminal profile ID. The terminal profile ID may be used by the kernel manager (e.g., kernel manager 360 of FIG. 3) to find the appropriate script to return to the reader 406 to properly configure the virtual terminal. The kernel token may also include a DTSP ID. The DTSP ID may be used by the kernel manager to double-check that the DTSP has allowed the particular terminal profile ID requested. The kernel token may include a secure element ID, which may be obtained from an authentication token (e.g., see FIG. 5).

[0102] In block 424, the session token and kernel token are sent to the reader 406 for initialization. The kernel token can be used to configure the terminal kernel on the secure element. The session token can be used as part of the validation of the transaction payload. In some implementations, the terminal backend 408 can then send the transport server public key to the reader 406. In some implementations, the transport server public key is associated with the source app 404 and received by the source app 404 during initial setup with the virtual terminal system and backend. The transport server public key can then be shared with the reader 406 when the reader 406 is initialized.

[0103] 6 illustrates an example sequence diagram 600 for initializing and configuring a virtual terminal 608. The virtual terminal 608 can be seen as a secure counterpart to the reader 604, as the virtual terminal is initialized and configured for a specific combination of source app 602 and DTSP to process a specific transaction. The virtual terminal 608 also has a limited lifespan based on the lifespan of the reader 604. The virtual terminal 608 is housed within a secure element and used for enhanced security and validation through cryptography. In some implementations, the configuration of the virtual terminal 608 follows the initialization of the reader 604 (an example initialization of the reader is described with reference to FIG. 4). The virtual terminal 608 is configured with a kernel token.

[0104] In block 610, the reader 604 sends the kernel token to the terminal backend 606 to fetch kernel configuration for the device reader's configuration. In particular, a kernel manager (e.g., kernel manager 360 of FIG. 3) receives the kernel token.

[0105] In block 612, the terminal backend 606 verifies the kernel token. Verification of the kernel token may include verification of the SEID, the DTSP ID, and the terminal profile ID. Verification ensures that all of these IDs match so that it is confirmed that the secure element is authorized to have a virtual terminal that corresponds to the DTSP.

[0106] In block 614, the terminal backend 606 sends the kernel configuration script to the reader 604. The kernel configuration script can include many types of kernel configuration information, including a PAN session public key, a PIN server public key, and a KEK ID. The PAN session public key is for use by the virtual terminal 608, and the backends (both the terminal backend 606 and the rewrap backend) have a PAN session private key. The PAN session public key can be used by the virtual terminal 608 in the secure element to encrypt transaction information so that the backend can later decrypt it. The KEK ID ties a particular virtual terminal 608 to a DTSP, ensuring that transactions are tagged as corresponding to the correct DTSP. In some implementations, the kernel configuration script can also include other kernel configuration information as described herein. In some implementations, the PIN server public key is the transport server public key used by the reader 604.

[0107] In block 616, the virtual terminal 604 sends the kernel configuration script to the terminal kernel 608. In block 618, the terminal kernel 608 may use the kernel configuration script to configure the kernel associated with the device reader.

[0108] At block 620, the terminal kernel 608 may send a confirmation of the kernel configuration to the virtual terminal 604. At block 622, the virtual terminal 604 may send a virtual terminal identifier to the source app 602. In some implementations, the virtual terminal identifier may be used to identify the particular virtual terminal 608 that was initialized and configured according to the kernel token. In some implementations, the virtual terminal identifier may be a combination of the SEID, app bundle ID, and installation ID. This may ensure that the virtual terminal identifier does not change between configurations and / or sessions that use different terminal profile IDs. In some implementations, the virtual terminal identifier may be used to identify on which device and in association with which app the virtual terminal 608 is running.

[0109] In Fig. 7, an example sequence diagram 700 for generating and encrypting transaction data into an encrypted transaction blob is shown. The encrypted transaction blob is encrypted using a secure element virtual terminal 702. Therefore, the encryption here is highly secure such that normal processes, applications, and processors on the device cannot access the transaction data. The encrypted transaction blob is designed to be decrypted only in the DTSP, i.e., in the DTSP's HSM for security. The initialization of the virtual terminal 702 and the reader app 704 has already been done in preparation for processing the transaction as described herein.

[0110] At block 710, the source app 706 can send first data to the reader 704. In some examples, this initiates a transaction and the source application calls a "transaction begin" API. In some implementations, the first data includes sales information so that the source app 706 can pass the amount of the transaction and the reader 704 can determine whether it is a purchase or refund or confirmation.

[0111] At block 712, the virtual terminal prompts the user to present the second data. In some implementations, the virtual terminal displays a UI that prompts the user to present an instrument for data transfer (e.g., the data transfer can be payment information). The UI can indicate where the user should present an instrument (e.g., tap a card or present another form of payment and / or the second data).

[0112] At block 714, the reader 704 signals the virtual terminal 702 that a transaction is beginning so that the virtual terminal 702 can expect the second data. At block 716, the virtual terminal 702 reads the second data (e.g., reads instrument or card data), which is received at the virtual terminal 702 (rather than the processor running other applications and / or the device's operating system). The combination of the second data and the first data may be known as transaction data. In some implementations, the first data may be sales information related to the sale. In some implementations, the second data may be payment information related to how a payment is made in connection with the sale.

[0113] The virtual terminal 702 is part of the secure element configured during terminal configuration. The secure element may be a dedicated location with a dedicated processor that is especially secure so that access is limited. The only applications that may be installed or run on the secure element are those added by or approved by the device manufacturer. The virtual terminal 702 is such an application on the secure element. Thus, the secure element (and virtual terminal 702) is a secure realm, and transaction data cannot be accessed, even by the processor running the operating system of a general purpose device (e.g., device 110 of FIG. 1).

[0114] At block 718, a transaction key (TK) is generated by the virtual terminal 702 in the secure element. The transaction key is a random key known only on the device within the secure element. At block 720, the virtual terminal 702 then encrypts the transaction data with the TK. Now there is encrypted transaction data and TK, but the TK is only known by the virtual terminal 702, not the reader 704, the source app 706, the device, the DTSP, or the backend. Additionally, additional processing, such as hashing, can be performed on the encrypted data transfer data.

[0115] In block 722, TK is encrypted by the PAN session public key. As described herein, the PAN session public key corresponds to the PAN session private key that the backend has. In this way, the backend can decrypt TK. In some implementations, the encrypted transaction data may be encrypted a second time by the PAN session public key. In some implementations, the encryption can be done by ECIES. When the virtual terminal 702 is initialized and configured, the PAN session public key is received from the terminal backend and the corresponding public key known by the rewrap backend and located in the secure element is used to encrypt TK. Now, there is 1) TK encrypted by the PAN session public key (known only by the virtual terminal 702 in the secure element), and 2) the encrypted transaction data encrypted by TK (and potentially also by the PAN session public key).

[0116] In block 724, the terminal kernel generates an encrypted transaction blob. The combination of the encrypted transaction data and the encrypted transaction key is referred to as the encrypted transaction blob. The encrypted transaction blob may also be referred to as the encrypted blob and the transaction blob. The encrypted transaction blob is then packaged with additional metadata (e.g., transaction profile, version, etc.). In some implementations, the metadata may also be encrypted. In some implementations, the metadata is encrypted in the same manner as the transaction data and / or the TK. In some implementations, some or all of the metadata may be used as a security check (e.g., the version data may be used to ensure that a hacker is not trying to use an old version). In some implementations, the metadata is not encrypted but is signed by the virtual terminal 702. In this way, the metadata may be verified without the need to decrypt the metadata and / or other information (e.g., the transaction data). Additionally, in some examples, at the time of encryption, it is determined which DTSP key encryption key (KEK) is used for rewrapping. It is important to note that the KEK hash (e.g., SHA256) is used as a diversifier (KDF) in the ECIES algorithm. For example, since the KEK hash corresponds to the DTSP KEK (a key that the DTSP has), it should already be known which DTSP is associated with this transaction. In other words, a DTSP must be selected at this stage and the data transfer cannot be rerouted to another DTSP. In some instances, this is cryptographically bound, so only the DTSP key identified at this stage can be used for rewrapping later at the data transfer server.

[0117] At block 726, an authentication blob may be generated. In some implementations, the authentication blob is used to communicate that authentication has been performed and that the virtual terminal, secure element, and / or device is properly authorized when decrypting and verifying in the rewrap backend as described herein. In some implementations, the authentication blob is additional metadata (e.g., transaction profile, version, etc.) that can be used to verify the encrypted transaction blob without decrypting the transaction data.

[0118] At block 728, the encrypted transaction blob, authentication blob, and general device data may be returned to the reader 704. The general device data includes general information that does not need to be encrypted on-device for regulatory, security, and / or privacy reasons.

[0119] 8 is an example sequence diagram 800 for encrypting a transaction blob for transmission to a DTSP 808, where the additional encryption occurs after adding additional metadata that is used by a rewrap backend 810 to verify that proper authorization has been completed for the virtual terminal 802 and reader 804, and that the transaction has been authorized by both the source app 806 and the DTSP 808.

[0120] In block 812, the reader 804 is configured to prepare a transaction payload consisting of a transaction blob, an authentication blob, and a session token. The session token is now used to ensure that this particular transaction is authorized by both the DTSP 808 and the terminal backend (through authentication and generation of the session token). The authentication blob contains metadata that can be used by the rewrap backend 810 to verify that the transaction is authorized.

[0121] In block 814, the transaction payload is hashed and sent back to the virtual terminal 802 where it can be signed by a key in the secure element and / or virtual terminal 802 using the device identification certificate. First, the reader 804 can hash the transaction payload and then send it to the virtual terminal 802. The virtual terminal 802 can then sign the hashed transaction payload with the private key associated with the virtual terminal's 802 device identification certificate. This clearly indicates that this transaction payload was generated on the particular device that performed all of the previous steps. In block 816, the virtual terminal 802 sends the signed payload (or payload signature) to the reader 804.

[0122] In block 818, the reader 804 generates a reader blob from the encrypted and signed transaction payload. The reader blob includes the transaction payload, the payload signature, the device identification public certificate, and the session ID of the session token.

[0123] At block 820, the reader blob may be encrypted again for sending to the source app 806. In some implementations, the entire reader blob is encrypted. In some implementations, only the transaction payload and / or additional metadata added to the transaction blob to form the reader blob is encrypted. The encryption is done with a transport server public key that corresponds to the transport server private key held by the rewrap backend 810. The reason for this additional encryption is to protect the personal / device information and metadata added to the transaction blob so that the personal / device information and metadata added to the transaction blob can be used to verify and validate the transaction data without decrypting it. In some implementations, this encryption is done using ECIES. Notably, all encryption described herein can be done with ECIES and other encryption algorithms based on the keys described herein.

[0124] At block 822, the virtual terminal sends the reader blob and the general device data to the source app 806. The reader blob may be referred to as the encrypted reader blob 186 of FIG. 1. The general device data may refer to any data. Exemplary general device data may include data about a transaction (e.g., data about a payment method or sale) that does not need to be encrypted for security, privacy, or regulatory reasons.

[0125] In block 824, the source app 806 generates a permission request. In some implementations, the permission request includes the leader blob and general device data. In some implementations, the permission request is sent in parallel with the leader blob and general device data. In block 826, the source app 806 can send the permission request, the leader blob, and the general device data to the DTSP 808.

[0126] In the DTSP 808, the leader blob is encrypted and the DTSP cannot obtain the transaction information, so the DTSP 808 needs to send the leader blob to the rewrap backend 810. In block 828, the DTSP 808 can send a rewrap request with the leader blob to the rewrap backend 810 for decryption.

[0127] 9 illustrates an example flow diagram 900 for decrypting a leader blob on a rewrap backend. At block 902, the rewrap backend (e.g., rewrap backend 150 of FIG. 1) can decrypt the leader blob using a transport server private key that corresponds to the transport server public key used to encrypt some or all of the leader blob. In some implementations, only a portion of the leader blob is decrypted. In some implementations, this decryption is done via ECIES. Decrypting the leader blob can give the rewrap backend access to the payload signature, the device identification public certificate, the transaction payload, and the session ID. As described above, the transaction payload includes the transaction blob, the authentication blob, and the session token.

[0128] At block 904, the rewrap backend can validate the session token. Validating the session token can include validating the signature of the session token, the format of the session token, and that the session token has not expired. Validating the session token can also include validating the session ID included in the reader blob against the session ID in the session token.

[0129] In block 906, the rewrap backend can verify the device identification certificate of the reader blob. For example, the rewrap backend can verify the signature of the transaction payload and the device identification certificate. Device identification signature verification means verifying the secure element and / or device as being the proper device from which the reader blob originated. In some implementations, the device identification certificate is verified using a key.

[0130] At block 908, the device ID is verified by the rewrap backend. The device ID may be associated with a secure element and may be referred to as the secure element ID (SEID). This verification can be done by comparing the device ID stored in the authentication blob, the device ID stored in the session token, and the device ID stored in the device identity public certificate. If the device IDs across different locations do not match, indicating that different devices have either opened a session, performed authentication, or are allowed to have a virtual terminal, the entire reader blob is rejected and discarded.

[0131] The rewrap backend may verify the transaction blob signature in block 910. In some implementations, verifying the transaction blob signature involves using an authentication private key.

[0132] 10 shows an example sequence diagram 1000 for rewrapping a transaction blob and how the DTSP 1002 receives the transaction data. At this point, the rewrap backend 1006 has an encrypted transaction key (encrypted by the PAN session public key) and the encrypted transaction data (encrypted by the TK).

[0133] In block 1012, only the encrypted TK is sent to the rewrap hardware security module (HSM) 1008. Key decryption requires strong security, hence the reason that key decryption is performed in the HSM.

[0134] At block 1014, the rewrap HSM 1008 uses the PAN session private key to decrypt the TK (encrypted by the PAN session public key provided to the virtual terminal). The TK is now cleared in the rewrap HSM 1008. As described herein, the rewrap HSM 1008 has improved security features. In some implementations, the rewrap HSM 1008 has a hardware component that is separate from the rest of the rewrap backend 1006. In some implementations, the rewrap HSM 1008 includes additional physical safeguards to prevent tampering. For example, the rewrap HSM 1008 can include a sensor that detects if the rewrap HSM 1008 is moved causing the rewrap HSM 1008 to destroy all associated data contained therein.

[0135] In block 1016, the TK is encrypted with the re-wrap KEK such that only the DTSP 1002 (or more appropriately the DTSP HSM 1004) can decrypt the TK using the corresponding DTSP KEK (as described herein, the re-wrap KEK corresponds to or is the same as the DTSP KEK provided to the DTSP as part of the key ceremony). In some implementations, the TK is encrypted into a TR31 key block. As described herein, the DTSP 1002 received a symmetric key (the DTSP KEK) corresponding to the re-wrap KEK in the re-wrap HSM 1008 during the key ceremony. The re-wrap KEK may also be referred to as the back-end KEK. The DTSP 1002 symmetric key is referred to as the DTSP KEK and is stored in the DTSP HSM 1004. The back-end KEK is loaded into the HSM and used to encrypt and send transaction keys back to the DTSP 1002. As described above, the back-end KEK is used to encrypt transaction keys. After the transaction key is decrypted using the PAN session private key and re-encrypted using the backend KEK, it can be called a re-wrapped transaction key.

[0136] At block 1018, the rewrapped transaction key is signed by the rewrap HSM 1008. This means verifying to the DTSP 1002 that the rewrap HSM 1004 properly decrypted and rewrapped the transaction key for use by the DTSP 1002 and the DTSP HSM 1008. In some implementations, the ciphertext and some predefined element (e.g., IV or salt) are signed by the rewrap HSM 1008. This means verifying to the DTSP 1002 that the data encrypted in the device's secure element (e.g., secure element 124 of FIG. 1) was not altered in transit.

[0137] At block 1020, the rewrap HSM 1008 sends the rewrapped transaction key to the rewrap backend 1006. In some implementations, the rewrap backend 1006 can then certify the rewrap using the rewrap backend certificate. At block 1022, the rewrap backend 1006 can send the rewrapped transaction key, the encrypted transaction blob, and the rewrap backend certificate to the DTSP 1002. In some implementations, the rewrap backend 1006 also sends a signature along with the associated rewrap backend certificate for validation by the DTSP 1002.

[0138] At block 1024, the DTSP 1002 may verify the rewrap backend certificate. In some implementations, the verification of the rewrap backend certificate may be verified using a signature associated with the rewrap backend certificate, based on a key shared between the rewrap backend 1006 and the DTSP 1002 and / or a certificate sent from the rewrap backend 1006 at block 1022. At block 1026, the DTSP 1002 may verify the rewrap HSM signature based on a key shared with the DTSP 1002 and / or based on a certificate provided by the rewrap backend 1006 at block 1022. The DTSP 1002 now has the encrypted data and the rewrapped transaction key (encrypted using the DTSP KEK).

[0139] At block 1028, the encrypted transaction blob and the re-wrapped transaction key are sent to the DTSP HSM 1004. The DTSP HSM 1004 server can then be configured to decrypt the re-wrapped transaction key using the DTSP KEK. The partner server can then decrypt the transaction data (e.g., the transaction blob) using the transaction key to obtain transaction data that can be used to request that the transaction be processed by the data forwarding processor. At block 1032, the DTSP HSM 1004 sends the transaction data to the DTSP 1002.

[0140] Once the DTSP 1002 receives the transaction data, it can process the transaction or send it to a data transfer processor. Once the data transfer is processed, the DTSP 1002 can receive information from the data transfer processor indicating whether it was approved or rejected, and can share that information with the source application. The source application can then present such information on the device's UI.

[0141] 11 shows an example diagram 1100 for decrypting a rewrapped transaction blob 1102 (which may include an encrypted transaction blob and a rewrapped transaction key). The DTSP 1140 and the DTSP HSM 1150 are involved in this decryption. The DTSP 1140 receives the rewrapped transaction blob 1102 from a rewrap backend. The rewrapped transaction blob 1102 includes a ciphertext 1103, an IV 1104, and a transaction key block 1106, all of which are recognizable as separate parts of the rewrapped transaction blob. The ciphertext 1103 and the IV 1104 represent encrypted transaction data including transaction data, which may include some or all of the first data and the second data. As discussed above, the data transfer data may include device and user data.

[0142] Decryption in the DTSP 1140 is handled by the DTSP HSM 1150. The DTSP HSM is a special hardware module or system designed for cryptography and that is particularly secure as described above. In some implementations, the DTSP HSM 1150 is a subsystem of the DTSP 1140.

[0143] In block 1110, the HSM 1150 decrypts the transaction key block 1106 using the DTSP KEK 1212. The DTSP KEK 1112 was exchanged between the system backends (e.g., the rewrap backend 150 of FIG. 1 and / or the terminal backend 130 of FIG. 1) when onboarding the DTSP 1140 to use the virtual terminal system as described herein. The decryption results in a transaction key 1124 (e.g., a transaction key as described with reference to FIG. 7).

[0144] In block 1122, the HSM 1150 can then use the transaction key 1124 to decrypt the encrypted transaction data from the ciphertext 1103 and the IV 1104. This is the same transaction data and encrypted transaction data referenced in Figure 7. Once the transaction data is decrypted from the ciphertext 1103 and the IV 1104, the HSM 1150 can send the transaction data 1130 to the DTSP 1140. The DTSP 1140 can extract the second data and the first data from the transaction data for data transfer and / or processing of the transaction.

[0145] FIG. 12 illustrates a flow chart depicting an example process 1200 for the techniques described herein, according to at least one example. The process 1200 is illustrated as a logical flow diagram, with each operation of the flow diagram representing a sequence of operations that may be implemented in hardware, computer instructions, or a combination thereof. In the context of computer instructions, the operations represent computer-executable instructions stored on one or more computer-readable storage media that, when executed by one or more processors, perform the recited operations. Typically, computer-executable instructions include routines, programs, objects, components, data structures, etc. that perform a particular function or implement a particular data type. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described operations may be combined in any order and / or in parallel to implement the process.

[0146] At block 1202, process 1200 includes receiving, by a first application on the user device, a terminal profile including a profile identifier based at least in part on the account profile data.

[0147] At block 1204, process 1200 includes initializing, by the first application, a virtual terminal system on the user device based at least in part on the profile identifier, where the virtual terminal system is configured for one or more data transfers, and the virtual terminal includes a reader on the user device.

[0148] At block 1206, the process 1200 includes receiving, at a first user interface of a first application, a request for a data transfer of the one or more data transfers, the request including a transfer value corresponding to the data transfer.

[0149] At block 1208, the process 1200 includes presenting, by the reader on a second user interface, a representation of the request for the data transfer.

[0150] At block 1210, the process 1200 includes receiving, via the virtual terminal system, data corresponding to a data transfer, the data including a transfer value and account information.

[0151] At block 1212, the process 1200 includes transmitting, by the reader, the received data to the first application.

[0152] At block 1214, the process 1200 includes presenting, via a second user interface of the reader, a visual representation of a response to the request for data transfer, the response being received by the first application.

[0153] FIG. 13 illustrates a flow chart depicting an example process 1300 for the techniques described herein, according to at least one example. The process 1300 is illustrated as a logical flow diagram, with each operation of the flow diagram representing a sequence of operations that may be implemented in hardware, computer instructions, or a combination thereof. In the context of computer instructions, the operations represent computer-executable instructions stored on one or more computer-readable storage media that, when executed by one or more processors, perform the recited operations. Typically, computer-executable instructions include routines, programs, objects, components, data structures, etc. that perform a particular function or implement a particular data type. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described operations may be combined in any order and / or in parallel to implement the process.

[0154] At block 1302, process 1300 includes transmitting, by the first server device, to a secure element of the user device, virtual terminal kernel configuration data, the virtual terminal kernel configuration data being used to configure a virtual terminal with a first public encryption key, the virtual terminal being associated with the secure element, the first public encryption key being used to generate an encrypted second encryption key by encrypting the second encryption key, the second encryption key being used to generate the encrypted data payload by encrypting the data payload.

[0155] At block 1304, process 1300 includes receiving, by the first server device, a request for a data payload from the second server device, the request including the encrypted data payload and an encrypted second encryption key.

[0156] At block 1306, the process 1300 includes decrypting, by the first server device, the encrypted second encryption key using a third private encryption key that corresponds to the first public encryption key.

[0157] At block 1308, the process 1300 includes generating, by the first server device, a re-wrapped second encryption key by encrypting the second encryption key with a fourth encryption key that corresponds to a fifth encryption key associated with the second server device.

[0158] At block 1310, the process 1300 includes transmitting the rewrapped second encryption key and the encrypted data payload by the first server device to the second server device.

[0159] FIG. 14 illustrates a flow chart depicting an example process 1400 for the techniques described herein, according to at least one example. The process 1400 is illustrated as a logical flow diagram, with each operation of the flow diagram representing a sequence of operations that may be implemented in hardware, computer instructions, or a combination thereof. In the context of computer instructions, the operations represent computer-executable instructions stored on one or more computer-readable storage media that, when executed by one or more processors, perform the recited operations. Typically, computer-executable instructions include routines, programs, objects, components, data structures, etc. that perform a particular function or implement a particular data type. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described operations may be combined in any order and / or in parallel to implement the process.

[0160] At block 1402, process 1400 includes receiving, by the user device, from a first server device, virtual terminal kernel configuration data, the virtual terminal kernel configuration data being used to configure a virtual terminal of the user device with a first public cryptographic key, the virtual terminal being associated with a secure element of the user device.

[0161] At block 1404, process 1400 includes generating, by the user device, a data payload, the data payload associated with the request for data transfer.

[0162] At block 1406, the process 1400 includes generating, by the user device, a second encryption key.

[0163] At block 1408, the process 1400 includes generating, by the user device, an encrypted data payload by encrypting the data payload with a second encryption key.

[0164] At block 1410, the process 1400 generates, by the user device, an encrypted second encryption key by encrypting the second encryption key with the first public encryption key.

[0165] At block 1412, process 1400 includes requesting, by the user device, authorization for a request from the second server device for a value transfer including the encrypted data payload and the encrypted second encryption key.

[0166] At block 1414, process 1400 includes receiving, by the user device, an authorization for the request for value transfer from a second server device, the second server device evaluating the data payload after the first server device decrypts the encrypted data payload and the encrypted second encryption key.

[0167] Exemplary methods, systems, and computer-readable media for enabling a virtual terminal for receiving touchless data transfer on a mobile device are described above. Some or all of these systems and methods may be at least partially implemented by architectures such as those illustrated in at least FIGS. 1-14, but this is not required. Although many of the examples are described above with reference to personal and / or payment related information, it should be understood that the techniques may be used to manage any type of user or non-user information (e.g., any type of data). Furthermore, in the preceding description, various non-limiting examples are described. For purposes of explanation, specific configurations and details are set forth to enhance an understanding of the examples. However, it will be apparent to one skilled in the art that the examples may be practiced without the specific details. Furthermore, well-known features may be omitted or simplified so as not to obscure the described examples.

[0168] 15 is a block diagram of an exemplary electronic device 1500. The device 1500 generally comprises a computer-readable medium 1502, a processing system 1504, an input / output (I / O) subsystem 1506, a radio circuit 1508, and an audio circuit 1510 including a speaker 1512 and a microphone 1514. These components may be coupled by one or more communication buses or signal lines 1503. The device 1500 may be any portable electronic device, including a handheld computer, a tablet computer, a mobile phone, a laptop computer, a tablet device, a media player, a personal digital assistant (PDA), a key fob, a car key, an access card, a multifunction device, a mobile phone, a portable gaming device, a headset, etc. (including combinations of two or more of these items).

[0169] It will be apparent that the architecture shown in Figure 15 is only one example architecture for device 1500, and that device 1500 may have more or fewer components or components in a different arrangement than those shown. The various components shown in Figure 15 may be implemented as hardware, software, or a combination of both hardware and software, including one or more signal processing circuits and / or application specific integrated circuits.

[0170] The radio circuitry 1508 is used to transmit and receive information over a wireless link or network with conventional circuitry of one or more other devices, such as an antenna system, a radio frequency (RF) transceiver, one or more amplifiers, a tuner, one or more oscillators, a digital signal processor, a coder-decoder (CODEC) chipset, memory, etc. The radio circuitry 1508 may use a variety of protocols, such as those described herein, for example. In various embodiments, the radio circuitry 1508 may establish and maintain communications with other devices using one or more communications protocols including time division multiple access (TDMA), code division multiple access (CDMA), Global System for Mobile Communications (GSM), Enhanced Data GSM Environment (EDGE), Wideband Code Division Multiple Access (W-CDMA), Long Term Evolution (LTE), LTE Advanced, Wi-Fi (such as Institute of Electrical and Electronics Engineers (IEEE) 802.11a, IEEE 802.11b, IEEE 802.11g, and / or IEEE 802.11n), Bluetooth, Wi-MAX, Voice over Internet Protocol (VoIP), Near Field Communication protocol (NFC), protocols for email, instant messaging, and / or short message service (SMS), or any other suitable communications protocol, including communications protocols not yet developed as of the filing date of this document.

[0171] The radio circuitry 1508 is coupled to the processing system 1504 via a peripherals interface 1516. The peripherals interface 1516 may include conventional components for establishing and maintaining communications between peripherals and the processing system 1504. Voice and data information received by the radio circuitry 1508 (e.g., in a speech recognition application or a voice command application) is transmitted via the peripherals interface 1516 to the one or more processors 1518. The one or more processors 1518 may be configured to process a variety of data formats for one or more application programs 1534 stored on the medium 1502.

[0172] The peripheral interface 1516 couples input / output peripherals of the device 1500 to the one or more processors 1518 and the computer readable medium 1502. The one or more processors 1518 communicate with the computer readable medium 1502 via a controller 1520. The computer readable medium 1502 may be any device or medium capable of storing code and / or data for use by the one or more processors 1518. The computer readable medium 1502 may include a memory hierarchy including cache, main memory, and secondary memory. This memory hierarchy may be implemented using any combination of random access memory (RAM) (e.g., static random access memory (SRAM), dynamic random access memory (DRAM), double data random access memory (DDRAM)), read only memory (ROM), FLASH, magnetic storage devices such as disk drives, magnetic tape, CDs (compact discs), and DVDs (digital video discs), and / or optical storage devices. In some embodiments, the peripherals interface 1516, the one or more processors 1518, and the controller 1520 may be implemented on a single chip, such as the processing system 1504. In some other embodiments, they may be implemented on separate chips.

[0173] The processor(s) 1518 may include hardware and / or software elements that perform one or more processing functions, such as mathematical operations, logical operations, data manipulation operations, data transfer operations, controlling the receipt of user input, controlling the output of information to a user, etc. The processor(s) 1518 may be embodied as one or more hardware processors, microprocessors, microcontrollers, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), etc. As noted above, the secure element 154 of FIG. 1 is separate from the processor 1518 discussed herein.

[0174] The device 1500 also includes a power system 1542 that provides power to the various hardware components. The power system 1542 can include a power management system, one or more power sources (e.g., batteries, alternating current (AC)), a recharging system, power failure detection circuitry, power converters or inverters, power status indicators (e.g., light emitting diodes (LEDs)), and any other components typically associated with the generation, management, and distribution of power within a mobile device.

[0175] In some embodiments, device 1500 includes a camera 1544. In some embodiments, device 1500 includes sensors 1546. The sensors may include an accelerometer, a compass, a gyrometer, a pressure sensor, an audio sensor, a light sensor, a barometer, etc. The sensors 1546 may be used to sense aspects of a location, such as an audio or light signature of a place.

[0176] In some embodiments, the device 1500 may include a GPS receiver, sometimes referred to as a GPS unit 1548. A mobile device may use a satellite navigation system, such as the Global Positioning System (GPS), to obtain location, timing, altitude, or other navigation information. During operation, the GPS unit may receive signals from GPS satellites that orbit the Earth. The GPS unit analyzes the signals to provide travel time and distance estimates. The GPS unit may determine the current location of the mobile device. Based on these estimates, the mobile device may determine a location fix, altitude, and / or current speed. The location fix may be example geographic coordinates, such as latitude and longitude information.

[0177] The one or more processors 1518 execute various software components stored on the medium 1502 to perform various functions for the device 1500. In some embodiments, the software components include an operating system 1522, a communications module (or instruction set) 1524, a location module (or instruction set) 1526, and other application programs (or instruction sets) 1534.

[0178] Operating system 1522 may be any suitable operating system, including embedded operating systems such as iOS, Mac OS, Darwin, Real Time Operating System (RTXC), LINUX, UNIX, OS X, WINDOWS, or VxWorks, etc. The operating system may include procedures, instruction sets, software components, and / or drivers for controlling and managing general system tasks (e.g., memory management, storage device control, power management, etc.) and facilitating communication between various hardware and software components.

[0179] The communications module 1524 includes various software components for facilitating communication with other devices via one or more external ports 1536 or via the wireless circuitry 1508, and for handling data received from the wireless circuitry 1508 and / or the external port 1536. The external port 1536 (e.g., Universal Serial Bus (USB), FireWire, Lightning connector, 60-pin connector, etc.) is adapted to couple directly to other devices or indirectly via a network (e.g., the Internet, a wireless local area network (LAN), etc.).

[0180] The location / motion module 1526 can assist in determining the current position (e.g., coordinates or other geographic location identifier) ​​and movement of the device 1500. Modern positioning systems include satellite-based positioning systems such as the Global Positioning System (GPS), cellular network positioning based on a "cell ID," and Wi-Fi positioning technology based on a Wi-Fi network. GPS also determines a position estimate based on the visibility of multiple satellites. Satellites may not be visible (or have a weak signal) indoors or in "building canyons." In some embodiments, the location / motion module 1526 receives data from the GPS unit 1548 and analyzes the signal to determine the current position of the mobile device. In some embodiments, the location / motion module 1526 can determine the current location using Wi-Fi or cellular location technology. For example, the location of the mobile device can be estimated using knowledge of nearby cell sites and / or Wi-Fi access points and using knowledge of their locations. Information identifying the Wi-Fi or cellular transmitter is received by the radio circuitry 1508 and communicated to the location / motion module 1526. In some embodiments, the location determination module receives one or more transmitter IDs. In some embodiments, a set of transmitter IDs can be compared to a reference database (e.g., a cell ID database, a Wi-Fi reference database). The reference database maps or correlates the transmitter IDs to location coordinates of the corresponding transmitters and calculates estimated location coordinates for the device 1500 based on the location coordinates of the corresponding transmitters. Regardless of the particular location technology used, the location / motion module 1526 can receive information from which a location fix can be derived and interpret the information to return location information such as geographic coordinates, latitude / longitude, or other location fix data.

[0181] The one or more applications 1534 on the device 1500 may include any application installed on the device 1500, including, without limitation, a browser, an address book, a contact list, email, instant messaging, social networking, word processing, keyboard emulation, widgets, JAVA-enabled applications, encryption, digital rights management, voice recognition, voice duplication, a music player (playing music recorded in one or more files, such as MP3 or AAC files), etc. As mentioned above, different applications may be installed in the secure element 124 of Figure 1. These applications in the secure element 124 of Figure 1 are installed by the device manufacturer and cannot be added and / or removed by the end user.

[0182] There may be other modules or instruction sets (not shown), such as a graphics module, a time module, etc. For example, the graphics module may include various conventional software components for rendering, animating, and displaying graphical objects (including, without limitation, text, web pages, icons, digital images, animations, etc.) on a display surface. In another example, the timer module may be a software timer. The timer module may also be implemented in hardware. The time module may maintain various timers for any number of events.

[0183] The I / O subsystem 1506 may be coupled to a display system (not shown). The display system may be a touch-sensitive display. The display displays visual output to a user in a graphical user interface (GUI). This visual output may include text, graphics, video, and any combination thereof. Some or all of the visual output may correspond to user interface objects. The display may use LED (light emitting diode), LCD (liquid crystal display) technology, or LPD (light emitting polymer display) technology, although other display technologies may be used in other embodiments.

[0184] In some embodiments, the I / O subsystem 1506 may include a display and user input devices such as a keyboard, a mouse, and / or a trackpad. In some embodiments, the I / O subsystem 1506 may include a touch-sensitive display. The touch-sensitive display may also accept input from a user based at least in part on tactile and / or haptic contact. In some embodiments, the touch-sensitive display forms a touch-sensitive surface that accepts user input. The touch-sensitive display / surface (along with any associated modules and / or sets of instructions in the computer-readable medium 1502) detects contact (and any movement or release of contact) on the touch-sensitive display and translates the detected contact into an interaction with a user interface object (e.g., one or more soft keys) that is displayed on the touch screen when the contact occurs. In some embodiments, the point of contact between the touch-sensitive display and the user corresponds to one or more fingers of the user. The user may contact the touch-sensitive display using any suitable object or appendage, such as a stylus, pen, finger, etc. The touch-sensitive display surface may detect the contact as well as any movement or release thereof using any suitable touch sensitivity technology. Touch sensitivity technologies include capacitive, resistive, infrared, and surface acoustic wave technologies, as well as other proximity sensor arrays or other elements that determine one or more points of contact with a touch-sensitive display.

[0185] Further, I / O subsystem 1506 may be coupled to one or more other physical control devices (not shown), such as push buttons, keys, switches, rocker buttons, dials, slider switches, sticks, LEDs, etc., to control or perform various functions, such as power control, speaker volume control, ring volume, keyboard input, scrolling, hold, menu, screen lock, clearing and terminating communications, etc. In some embodiments, in addition to a touch screen, device 1500 may include a touch pad (not shown) for activating or deactivating certain functions. In some embodiments, a touch pad is a touch-sensitive area of ​​a device that, unlike a touch screen, does not display visual output. A touch pad may be a touch-sensitive surface separate from a touch-sensitive display or an extension of a touch-sensitive surface formed by a touch-sensitive display.

[0186] In some embodiments, some or all of the operations described herein may be performed using an application running on a user's device. Circuits, logic modules, processors, and / or other components may be configured to perform various operations described herein. Those skilled in the art will appreciate that such configuration may be achieved through the design, setup, interconnection, and / or programming of specific components depending on the implementation, and that configured components may or may not be reconfigurable for different operations depending on the implementation. For example, a programmable processor may be configured by providing suitable executable code, and dedicated logic circuits may be configured by suitable connections of logic gates and other circuit elements.

[0187] Any of the software components or functions described in this application may be implemented as software code executed by a processor using any suitable computer language, such as, for example, Java, C++ or Perl, using conventional or object-oriented techniques. The software code may be stored as a series of instructions or commands on a computer-readable medium for storage and / or transmission, suitable media including random access memory (RAM), read-only memory (ROM), magnetic media such as a hard drive or a floppy disk, or optical media such as a compact disk (CD) or digital versatile disk (DVD), flash memory, etc. The computer-readable medium may also be any combination of such storage or transmission devices.

[0188] Such programs may also be encoded and transmitted using carrier signals adapted for transmission over wired, optical, and / or wireless networks conforming to various protocols, including the Internet. Thus, computer-readable media according to embodiments of the present disclosure may be created using data signals encoded with such programs. Computer-readable media encoded with program code may be packaged with a compatible device or provided separately from other devices (e.g., via Internet download). Any such computer-readable media may be on or within a single computer program product (e.g., a hard drive or an entire computer system), or may be present on or within different computer program products within a system or network. The computer system may include a monitor, printer, or other suitable display that provides a user with any of the results described herein.

[0189] A computer program incorporating various features of the present disclosure may be encoded on a variety of computer-readable storage media, with suitable media including magnetic disks or tapes, optical storage media such as compact disks (CDs) or digital versatile disks (DVDs), flash memory, and the like. A computer-readable storage medium encoded with program code may be packaged with a compatible device or provided separately from other devices. In addition, the program code may be encoded and transmitted over wired and / or wireless networks conforming to various protocols, including the Internet, thus enabling distribution, for example, via Internet download. Any such computer-readable medium may be on or within a single computer product (e.g., a solid-state drive, hard drive, CD, or an entire computer system), or may be present on or within different computer products within a system or network. A computer system may include a monitor, printer, or other suitable display that provides a user with any of the results described herein.

[0190] Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense, although it will be apparent that various modifications and changes may be made thereto without departing from the broader spirit and scope of the disclosure as set forth in the appended claims.

[0191] Other variations are within the spirit and scope of the present disclosure. Thus, while the disclosed technology is susceptible to various modifications and alternative constructions, specific embodiments of the disclosed technology have been shown in the drawings and have been described above in detail. It is to be understood, however, that there is no intention to limit the disclosure to the particular form or forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents included within the spirit and scope of the present disclosure as defined in the appended claims.

[0192] In the context of describing the disclosed embodiments (particularly in the context of the claims that follow), use of the terms "a," "an," and "the" and similar designations should be construed to encompass both the singular and the plural, unless otherwise indicated herein or clearly contradicted by context. The terms "comprising," "having," "including," and "containing" should be construed as open-ended (e.g., meaning "including, but not limited to"), unless otherwise noted. The term "connected" should be construed as partially or completely contained within, attached to, or joined together, even if there is something intervening. The recitation of ranges of values ​​herein, unless otherwise indicated herein, is intended merely to serve as a shorthand method of referring individually to the individual values ​​falling within the range, and the individual values ​​are hereby incorporated as if they were individually recited herein. All methods described herein may be performed in any suitable order unless otherwise indicated herein or otherwise clearly contradicted by context. The use of any and all examples provided herein, or the use of exemplary language (e.g., "etc.") is intended merely to better illuminate the embodiments of the disclosure and does not impose limitations on the scope of the disclosure unless specifically claimed. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the disclosure.

[0193] Disjunctive language, such as the phrase "at least one of X, Y, or Z," is understood within the context in which it is generally used to indicate that an item, term, etc. may be either X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z), unless specifically stated otherwise. Thus, such disjunctive language is generally not intended to, and should not, imply that a particular embodiment requires that at least one of X, at least one of Y, or at least one of Z, respectively, be present.

[0194] Preferred embodiments of the present disclosure are described herein, including the best way known to the inventors for carrying out the disclosure. Variations of these preferred embodiments may become apparent to those skilled in the art upon reading the foregoing description. The inventors anticipate that such variations may be employed by those skilled in the art as appropriate, and the inventors intend for the present disclosure to be practiced otherwise than as specifically described herein. Accordingly, this disclosure includes all modifications and equivalents of the subject matter recited in the claims appended hereto as permitted by applicable law. Moreover, any combination of the foregoing elements in all possible variations of the present disclosure is encompassed by the present disclosure unless otherwise indicated herein or otherwise clearly contradicted by context.

[0195] All references cited in this specification, including publications, patent applications, and patents, are herein incorporated by reference to the same extent as if each reference was individually and specifically indicated to be incorporated by reference and to the same extent as if each reference was set forth herein as a whole.

[0196] As explained above, one aspect of the present technology is sharing personal and / or payment-related data between user devices, which may include storing some aspects of the data on a server. The present disclosure contemplates that in some cases, this collected data may include personal information data that uniquely identifies a particular person, or personally identifiable information (PII) data that can be used to contact or locate a particular person. Such personal information data may include demographic data, location-based data, phone numbers, email addresses, Twitter IDs, home addresses, data or records regarding a user's credit card information, date of birth, or any other identifying or personal or health information.

[0197] This disclosure recognizes that the use of such personal information data in the present technology may be for the benefit of the user. For example, the personal information data may be used to process data transfers or to pay for transactions with the source. Additionally, other uses of personal information data that benefit the user are also contemplated by this disclosure.

[0198] This disclosure contemplates that entities involved in the collection, analysis, disclosure, transmission, storage, or other use of such personal information data will adhere to robust privacy policies and / or privacy practices. Specifically, such entities should implement and consistently use privacy policies and practices that are generally recognized as meeting or exceeding industry or government requirements for keeping personal information data confidential and secure. Such policies should be easily accessible by users and should be updated as data collection and / or use changes. Personal information from users should be collected for the entity's lawful and legitimate use and should not be shared or sold except for those lawful uses. Furthermore, such collection / sharing should be carried out after informing and obtaining consent from the user. Moreover, such entities should consider taking all necessary measures to protect and secure access to such personal information data and ensure that others who have access to the personal information data adhere to their privacy policies and procedures. Furthermore, such entities may subject themselves to third-party assessments to attest to their adherence to widely accepted privacy policies and practices. Moreover, policies and practices should be adapted to the specific types of personal information data collected and / or accessed, and should conform to applicable laws and standards, including jurisdiction-specific considerations. For example, in the United States, collection of or access to certain health data may be governed by federal and / or state laws, such as the Health Insurance Portability and Accountability Act (HIPAA). Meanwhile, health data in other countries may be subject to other regulations and policies and should be addressed accordingly. Therefore, different privacy practices should be maintained with respect to different types of personal data in each country.

[0199] Notwithstanding the foregoing, the present disclosure also contemplates embodiments in which a user selectively blocks use of or access to personal information data. That is, the present disclosure contemplates that hardware and / or software elements may be provided to prevent or block access to such personal information data. For example, in the case of ad serving services or other services related to health record management, the present technology may be configured to allow a user to select "opt-in" or "opt-out" of participating in the collection of personal information data during registration for the service or at any time thereafter. In addition to providing "opt-in" and "opt-out" options, the present disclosure contemplates providing notice regarding access or use of personal information. For example, the user may be notified upon download of an app that will access the user's personal information data, and then again immediately before the personal information data is accessed by the app.

[0200] Moreover, it is the intent of this disclosure that personal information data should be managed and processed in a manner that minimizes the risk of unintended or unauthorized access or use. Risks can be minimized by limiting data collection and deleting data when it is no longer needed. Additionally, where applicable, including in certain health-related applications, anonymization of data can be used to protect user privacy. De-identification can be facilitated by removing certain identifiers (e.g., date of birth, etc.) where appropriate, controlling the amount or specificity of data stored (e.g., collecting location data at a city level rather than an address level), controlling how data is stored (e.g., aggregating data across users), and / or other methods.

[0201] Thus, while this disclosure broadly encompasses the use of personal information data to implement one or more of the various disclosed embodiments, this disclosure also contemplates that the various embodiments may be implemented without requiring access to such personal information data. That is, the various embodiments of the technology are not rendered inoperable by the absence of all or a portion of such personal information data. The embodiments may be implemented by using a computer program product that includes computer programs / instructions that, when executed by a processor, cause the processor to perform any of the techniques / methods described in this disclosure.

Claims

1. 1. A method comprising: receiving, by a first application on the user device, a terminal profile including a profile identifier based at least in part on the account profile data; initializing, by the first application, a virtual terminal system on the user device based at least in part on the profile identifier, the virtual terminal system being configured for one or more data transfers, the virtual terminal including a reader on the user device; receiving, at a first user interface of the first application, a request for a data transfer of the one or more data transfers, the request including a transfer value corresponding to the data transfer; presenting, by the reader, on a second user interface, a representation of the request for the data transfer; receiving, via the virtual terminal system, data corresponding to the data transfer, the data including the transfer value and account information; transmitting, by the reader, the received data to the first application; presenting, via the second user interface of the reader, a visual representation of a response to the request for the data transfer, the response being received by the first application; A method comprising:

2. The method of claim 1 , further comprising transmitting, by the first application, account profile data associated with the user device to a server device.

3. The method of claim 2 , wherein the server device generates the terminal profile corresponding to the account profile data.

4. requesting, by the first application, a token from the server device; receiving, by the first application, the token from the server device; initializing the reader based at least in part on the token; The method of claim 2 further comprising:

5. The method of claim 1 , further comprising encrypting, by the reader, the received data corresponding to the data transfer.

6. The method of claim 5 , wherein the virtual terminal system further comprises a near-field data receiving device and a secure element.

7. The method of claim 6 , wherein the data corresponding to the data transfer is received via the near field receiving device of the virtual terminal system.

8. The method of claim 6 , wherein the near-field data receiving device comprises a card reader.

9. The method of claim 8 , wherein the card reader comprises an internal Near Field Communication (NFC) card reader.

10. 7. The method of claim 6, wherein the received data corresponding to the data transfer is encrypted within the secure element of the virtual terminal system to generate encrypted data.

11. transmitting, by the first application, the encrypted data to a server device; receiving, by the first application, the response to the request for the data transfer from the server device; The method of claim 10 further comprising:

12. 1. A computing device comprising: one or more memories; one or more processors in communication with the one or more memories and configured to execute instructions stored in the one or more memories to cause the computing device to perform the method of any one of claims 1 to 11; A computing device comprising:

13. A non-transitory computer readable storage medium having stored thereon program instructions which, when executed by one or more processors of a computing device, cause the computing device to perform the method of any one of claims 1 to 11.

14. 1. A method comprising: transmitting, by the first server device, to a secure element of the user device, virtual terminal kernel configuration data used to configure a virtual terminal with a first public encryption key, the virtual terminal being associated with the secure element, the first public encryption key used to generate an encrypted second encryption key by encrypting a second encryption key, the second encryption key used to generate an encrypted data payload by encrypting a data payload; receiving, by the first server device, a request for the data payload from a second server device, the request including an encrypted data payload and the encrypted second encryption key; decrypting, by the first server device, the encrypted second encryption key using a third private encryption key corresponding to the first public encryption key; generating, by the first server device, a rewrapped second encryption key by encrypting the second encryption key with a fourth encryption key corresponding to a fifth encryption key associated with the second server device; transmitting the rewrapped second encryption key and the encrypted data payload by the first server device to the second server device; A method comprising:

15. The method of claim 14 , wherein the fourth encryption key and the fifth encryption key are related symmetric encryption keys.

16. 16. The method according to claim 14 or 15, wherein the decryption of the encrypted second cryptographic key using a third private cryptographic key is performed on a hardware secure module.

17. The method of claim 16 , wherein the hardware secure module is configured to be physically protected from electronic and physical tampering.

18. 18. The method of claim 14, wherein the second encryption key is generated by the virtual terminal on the user device.

19. 19. The method of claim 14, further comprising receiving a kernel token from the user device, the kernel token indicating that the second server device has authorized the user device to generate one or more data payloads.

20. receiving a reader token from the user device, the reader token including first data associated with the device and second data associated with the second server device; determining that the reader token is valid by checking the first data and the second data; generating the kernel token based at least in part on one or more of the first data and the second data; transmitting the kernel token to the user device; 20. The method of claim 19, further comprising:

21. sending to the user device a session token, the session token indicating that the second server device has authorized the user device to generate the data payload, the data payload being processed by the second server device; and verifying the session token, wherein the request for the data payload from the second server device further includes the session token.

21. The method according to any one of claims 14 to 20.

22. a first server device, one or more memories; one or more processors in communication with the one or more memories and configured to execute instructions stored in the one or more memories to cause the first server device to perform the method of any one of claims 14 to 21; A first server device comprising:

23. 22. A non-transitory computer-readable storage medium having stored thereon program instructions which, when executed by one or more processors of a first server device, cause the first server device to perform the method of any one of claims 14 to 21.

24. 1. A method comprising: receiving, by the user device, from a first server device, virtual terminal kernel configuration data, the virtual terminal kernel configuration data being used to configure a virtual terminal of the user device with a first public cryptographic key, the virtual terminal being associated with a secure element of the user device; generating, by the user device, a data payload, the data payload associated with a request for data transfer; generating, by the user device, a second encryption key; generating an encrypted data payload by encrypting, by the user device, the data payload with the second encryption key; generating, by the user device, an encrypted second encryption key by encrypting the second encryption key with the first public encryption key; requesting, by the user device, from a second server device, authorization for the request for a value transfer including the encrypted data payload and the encrypted second encryption key; receiving, by the user device, an authorization for the request for a value transfer from the second server device, the second server device evaluating the data payload after the first server device decrypts the encrypted data payload and the encrypted second encryption key; A method comprising:

25. 25. The method of claim 24, wherein the secure element is part of a user device, the secure element being a separate hardware module configured for security and cryptography, and the secure element being separate from an application processor on the user device.

26. 26. The method of claim 25, wherein generating the second cryptographic key and generating the encrypted data payload are performed by the secure element.

27. 27. The method of claim 24, further comprising sending a kernel token to the first server device, the kernel token indicating that the second server device has authorized the user device to generate one or more data payloads.

28. transmitting a reader token to the first server device, the reader token including first data associated with the user device and second data associated with the second server device; receiving the kernel token from the first server device, the kernel token indicating that the reader token is valid; sending a request to the first server device for the virtual terminal kernel configuration data, the request including the kernel token; 30. The method of claim 27, further comprising:

29. receiving a session token from the first server device, the session token indicating that the first server device has authorized the user device to generate the data payload, the data payload to be processed by the second server device; and validating the session token, wherein the request for the data payload from the server device further includes the session token.

29. The method of any one of claims 24 to 28.

30. 30. A method according to any one of claims 24 to 29, wherein the second cryptographic key is known only by the secure element.

31. 1. A computing device comprising: one or more memories; one or more processors in communication with the one or more memories and configured to execute instructions stored in the one or more memories to cause the computing device to perform the method of any one of claims 24 to 30; A computing device comprising:

32. 31. A non-transitory computer readable storage medium having stored thereon program instructions which, when executed by one or more processors of a computing device, cause the computing device to perform the method of any one of claims 24 to 30.

Images