Authorizer for virtual terminal operation

Abstract

To provide a method that performs authorization controls for operations of a secure element on a multipurpose device, such as a mobile device, a smart phone, tablet, and a user device and a storage medium.SOLUTION: A method includes: receiving, by an authorizer application, an authorization token associated with an operation of a cryptographic applet hosted by a secure element; authenticating the authorization token; setting authorization criteria for the operation of the cryptographic applet based on the authorization token; receiving an authorization status request corresponding to the operation, from the cryptographic applet; verifying the authorization status request complies with the authorization criteria; transmitting an authorization status to the cryptographic applet; and performing, by the cryptographic applet, the operation based at least in part on the authorization status.SELECTED DRAWING: Figure 7

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims benefit of and priority to U.S. patent application Ser. No. 18 / 374,482, entitled "AUTHORIZER FOR OPERATIONS OF A VIRTUAL TERMINAL," filed Sep. 28, 2023, which is related to U.S. patent application Ser. No. 18 / 374,414, entitled "SECURE PIN ENTRY USING A VIRTUAL TERMINAL," filed Sep. 28, 2023, which are hereby incorporated by reference in their entireties for all purposes. [Background technology]

[0002] Electronic devices, especially portable electronic user devices, are rapidly becoming more prevalent in any modern society. Such devices may be used as terminals for transmitting data to each other. The transmitted data may require encryption and decryption to protect sensitive data. Permission to perform operations by a secure element of the user device may be used to improve data security for encryption and decryption of sensitive data. [Brief explanation of the drawings]

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

[0004] [Figure 2] 1 shows a block diagram for illustrating the techniques described herein, according to one embodiment of the present disclosure.

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

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

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

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

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

[0010] [Figure 8] 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 INVENTION

[0011] 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 those 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.

[0012] Examples of the present disclosure relate to, among other things, methods, systems, devices, and computer-readable media that provide techniques for authorizing data transfer operations of a virtual terminal hosted by (e.g., executed internally by) a secure element. The secure element is embedded in a general-purpose user device. Unlike traditional data transfer methods, the techniques described herein enable authorization control for secure element operations on the general-purpose device (e.g., a mobile device, smartphone, tablet, etc.). An authorizer application executing within the secure element can receive tokens from a backend server that enable specific operations of the secure element. In this manner, the authorizer application enables checks on cryptographic and other operations of the secure element. The authorizer application enables data security features on the secure element that reduce potential data security and privacy concerns. A system including a virtual terminal can be configured to include a reader application (e.g., a data reader application that provides the general-purpose device operating system as a hub for data transfer-related applications and received information that can be used by the secure element), an internal near-field data transceiver device (e.g., an internal data reader such as a near-field communication ("NFC") chip), and a secure element. The short-range data transceiver device may not be a component of an external connection device (e.g., a dongle) but rather may be integrated into a general-purpose device. The general-purpose device may also include a secure element, e.g., a tightly integrated hardware module designed for data security. The secure element may host virtual terminal and data transfer information. The secure element may not be a component of an external connection device (e.g., a dongle).

[0013] The technology described herein provides a mobile contactless data transfer device solution that enables a user to perform secure data transfers using a virtual terminal on a multipurpose device (e.g., a mobile device, smartphone, tablet, etc.) that has been properly authorized by a backend server. Conventional data transfer systems require a dedicated device and / or hardware separate from the multipurpose device (e.g., a dongle or terminal device). The virtual terminal can be configured to support software-based terminals on the multipurpose device, eliminating the need for dedicated device and / or hardware data transfer. The virtual terminal can be hosted by a secure element. An authorizer application hosted by the secure element can be used to authorize secure element operations, such as data transfer-related operations of the virtual terminal. The authorizer application can be used to generate a verification block that is authenticated by a backend server. The backend server can verify the verification block and return an authorization token that sets authorization criteria in the authorizer application. When a cryptographic applet in the secure element is requested to perform an operation, the cryptographic applet can request authorization confirmation for the operation from the authorizer application. The authorizer application can communicate whether an operation is permitted or not, allowing the cryptographic applet to perform the requested operation. The authorizer application can be used to monitor the health of the secure element and associated systems / applications, reducing the opportunity for misuse of the secure element and its associated cryptographic capabilities. The authorizer application can also be used to enable a mutual authentication system that runs locally (without the need for a server service) between the secure element and the data transfer device. The authorizer application can be used to prevent unauthorized access and / or use of keys stored in the secure element.Mobile data transfer technology may be enabled through (1) a third-party mobile data transfer application (also referred to as a 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 ("API(s)") (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 ("DTSP(s)") that contract with Source App developers to facilitate processing of transactions. The Source Application is directed to the Source and may enable the Source to accept contactless data transfers from users using either digital or physical closed-loop transaction devices or open-loop data transfer devices.

[0014] In some examples, a source application on the multipurpose device may receive a command via a user interface of the multipurpose device to perform an operation that includes using the operation with a corresponding cryptographic applet in the secure element. To perform the operation of the cryptographic applet, authorization may be required via an authorizer application in the secure element. The authorizer application may be initialized in connection with the operations described herein. The source application may send an operation authorization request to the DTSP to perform the operation. The DTSP may authenticate the operation authorization request as originating from a valid source application and / or device. The DTSP may send a DTSP authorization token to the source application. The source application may send the DTSP authorization token to a reader application to request initialization of the authorizer application in the secure element. The reader application may generate a verification block including the DTSP authorization token and device metrics. The reader application may send the verification block along with an authorization token request to the server backend. The server backend may authenticate the authorization token request as originating from a valid reader application and / or device and authorized by the DTSP. The server backend may generate an authorization token including the authorization criteria. The server backend can send the authorization token so that it can be received by the authorizer application, and the authorizer application can set the authorization criteria associated with the operation. This process can be referred to as initializing the authorizer application with respect to the operation.

[0015] In some examples, after the authorizer application is initialized for an operation, the source application and / or the reader application can receive a command to perform the operation. The reader application can receive encrypted instrument data. The reader application can send the encrypted instrument data and a request to perform the operation to a crypto applet corresponding to the source application. The crypto applet can request an authorization status for the operation from the authorizer application. The authorizer application can check whether authorization criteria are met for the operation. The authorizer application can send the authorization status to the crypto applet. If the authorization status is "unauthorized," the crypto applet can not perform the operation and send an indication to the reader that the operation was not authorized. If the authorization status is "authorized," the crypto applet can perform the operation.

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

[0017] Referring now to the drawings, FIG. 1 shows an example block diagram 100 with example systems and components for implementing the virtual terminal technology described herein. A device 110 (also referred to as a general-purpose device) includes a source application 112 (e.g., an application also referred to as a “source app”) that interacts with an SDK 114 to transmit first data 180 to a reader 120 (also referred to as a reader application). The reader 120 may be part of the general-purpose device's operating system configured to receive information that can be used by data transfer-related third-party applications and secure elements. For example, the reader 120 may request information from the secure element on behalf of the third-party application (e.g., the source application 112). Additionally, the reader 120 may transmit information received from different communication methods on the device to the secure element and / or third-party applications. For example, information received through the device's UI interface or transmission standards (e.g., NFC, Bluetooth, WiFi, cellular connection, etc.) may be used to transmit information to the secure element and / or third-party applications. Prior to receiving the first data 180, the reader 120 can interact with the terminal backend 130 to initialize the virtual terminal 126. The virtual terminal 126 is hosted within the secure element 124. Any services or applications hosted within the secure element 124, including the virtual terminal 126, use the processor and memory associated with the secure element 124. Thus, the application processor and memory of the user device 110 may not be used by the applications or services hosted by the secure element. Data and information of any services or applications hosted by the secure element can have data secured as described in connection with the secure element. The secure element 124 is a system designed to enhance security as described herein.For example, the secure element 124 is a hardware module specially designed for cryptography and data security of secret and / or sensitive data. The secure element 124 can be a hardware chip that runs a specific set of programs / applications, stores secret and / or sensitive data, and provides controlled access to the secret and / or sensitive data. The secure element 124 can provide the following set of features at the hardware level: 1) detecting hacking and / or data tampering attempts, 2) creating a root of trust (RoT) platform for encryption and data security systems, 3) providing secure memory for storing secret encryption keys and secret and / or sensitive data, 4) cryptographically secure generation of random numbers, 5) generating keys such as private and public key pairs for asymmetric encryption, and 6) secure monitoring of system resources such as detecting hardware configuration changes. The secure element 124 is separate from the application processor of the device 110. The secure element 124 receives second data 182 that can detail how data transfers can be provided to a source associated with the source application 112.

[0018] The virtual terminal 126 can generate transaction data using the first data 180 and the second data 182. In some examples, a transaction can be referred to as a data transfer. As described herein, these terms may be interchangeable in some cases. 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. For example, the transaction key can be randomly generated at the time of the transaction by the virtual terminal 126. The transaction key is then encrypted with a rewrap backend public key (corresponding to a rewrap backend 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 with the rewrap backend public key and transaction data encrypted with the transaction key. The virtual terminal may generate an encrypted transaction blob 184 from the encrypted transaction key and the encrypted transaction data. The encrypted transaction blob 184 may include additional metadata. Use of the encrypted transaction blob 184 can prevent transaction data from being exposed outside of the secure element 124 before the DTSP 140 can process the transaction data.

[0019] The virtual terminal 126 can then send the encrypted transaction blob 184 to the reader 120. The reader 120 can include additional metadata about the data transfer encrypted using the transport server key described herein. The encrypted metadata (using the transport server 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 with the transport server key. The use of the encrypted transaction blob 184 can allow the rewrap backend 150 to verify the encrypted metadata to verify the transaction data without decrypting the transaction data encrypted with the transaction key. 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.

[0020] The reader 120 can send the encrypted reader blob 186 to the source application 112. The source application 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 may be 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 use a transport server key (corresponding to the transport server key) to decrypt the encrypted metadata of the encrypted reader blob 186 and verify various portions of the metadata to verify that the encrypted reader blob is authorized by the DTSP 140, the source application 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 the 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 application 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.

[0021] Once the rewrap backend 150 verifies the metadata of the encrypted reader blob 186, the rewrap backend 150 can re-encrypt the transaction key using 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 rewrap backend public key. The rewrap backend 150 can decrypt the transaction key using the rewrap backend private key (which corresponds to the rewrap backend public key). The rewrap backend 150 then re-encrypts the transaction key using 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.

[0022] 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) using the KEK (as described herein). In this manner, the rewrap backend decrypts 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.

[0023] 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 collaborate with the data transfer processor 160 by sending the transaction data to the data transfer processor 160 for processing. An exemplary data transfer processor can be a payment network operator. Another exemplary data transfer processor can be the issuer of the device used for the data transfer. In some examples, the DTSP 140 can send the transaction data to the payment network operator, which can send the transaction data to the issuer. For example, the device can be a credit card, and the issuer can be a bank. Once the data transfer is processed or authorized, the data transfer service provider 140 can send an authorization response 192 to the source application 112, which can indicate that the second data has been verified and authorized, the transaction has been authorized, and the transaction has been completed.

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

[0025] In some examples, the source may be ready to initiate a transaction (e.g., 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) can enter some value (e.g., $10) and press "Pay." In response, the system can 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 can then pass the first data to the reader 120.

[0026] Prior to a transaction, the reader 120 can be initialized and configured. The reader 120 can be specific to a particular pairing of the source application 112 and the DTSP 140. The reader 120 can then initiate the instrument reader. The instrument reader can be an application (e.g., if the source app is a first application, it corresponds to a second application) and can control the user interface (UI) of the device 110, which presents an instrument reader UI. In some examples, the instrument reader UI can be presented above the source app UI, and the instrument reader UI can display to the user information 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)) can be displayed.

[0027] 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.

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

[0029] 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) 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 key, while the encrypted transaction blob 184 may not be further encrypted. The transport server key can be generated during initialization of the reader 120 and corresponds to the transport server key maintained by the terminal backend 130 and / or the rewrap backend 150. The reader 120 can send the encrypted reader blob 186 to the source application 112, and the device reader application UI can close, leaving the source application running (and displayed on the UI), and the source application now 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 application 112.

[0030] Because the encrypted transaction blob 184 is encrypted with a transaction key known only by the virtual terminal 126, the source application 112 and the DTSP 140 may not be able to 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 provided herein.

[0031] 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 can also be referred to as a Mobile Payment on COD (MPOC) backend). The terminal backend 130 can also be referred to herein as the 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 necessary initialization processes. 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.

[0032] The second backend can be referred to as the rewrap backend 150, the device data processor backend, or the data transfer rewrap backend. The rewrap backend 150 handles the rewrap process, using the transport server key to decrypt the encrypted reader blob 186 and inspect the metadata therein, as described herein. Using the metadata, the rewrap backend can verify that the data transfer was authorized by the DTSP 140, the source application 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 rewrap backend public key) and encrypted transaction data (encrypted by the transaction key). Once the metadata is verified, the rewrap backend 150 can decrypt the encrypted transaction key (encrypted by the PAN session public key) using the corresponding rewrap backend 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 transport key encrypted transaction data may be referred to as re-wrapped encrypted transaction data 190, which may be decrypted by DTSP 140. Referring again to virtual terminal 126 and associated terminal backend 130, terminal backend 130 cooperates with virtual terminal 126 to securely encrypt the transaction data within secure element 124.

[0033] After receiving the encrypted reader blob 186 from the reader 120, the source application 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 application 112, or may be controlled by the same entity; however, it may also be an entirely different entity. For example, the source may create an account on the source application 112, such that the source may not own the source app but may use the source app to facilitate data transfers and other data transfer issues. The source application 112 may then be operated by the same or a different entity than the DTSP 140.

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

[0035] In some examples, a DTSP may be a payment service provider (“PSP”) such as a bank (or, alternatively, a bank affiliate), or a corporate entity such as an acquirer processor or payment facilitator or aggregator, either unlicensed or licensed as a non-bank financial institution (such as a money transmitter). Additionally, transaction information may be transmitted as follows: (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 app via front-end integration, (4) from the source app to the DTSP's payment system, (5) from the DTSP's payment system to the back-end platform via back-end integration, (6) from the back-end platform to the DTSP's payment system via 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 via 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.

[0036] The rewrap backend 150 accesses the appropriate keys (transport server key and rewrap backend private key) to decrypt the encrypted reader blob 186. In some implementations, the rewrap backend 150 can decrypt the encrypted reader blob 186 and the encrypted transaction blob 184 using the corresponding private key (relative to the public key used to encrypt the encrypted reader blob 186 and the encrypted transaction blob 184). The rewrap backend 150 can decrypt the encrypted transaction key used to encrypt the transaction data (encrypted by the rewrap backend public key) and re-encrypt the decrypted transaction key using the backend KEK known to the DTSP. The rewrap backend 150 can 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 a "transaction key" can be unwrapped by decrypting the transaction key via the rewrap backend private key (corresponding to the rewrap backend 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 (which corresponds to the back-end KEK). The DTSP can then decrypt the transaction data using the transaction key. Once this process is complete, the DTSP has the transaction data for the data transfer and can process the data transfer using the data transfer processor.

[0037] When the rewrap backend 150 decrypts the encrypted reader blob 186, it can perform specific verification of the metadata within the encrypted reader blob 186. If the verification is verified, the rewrap backend 150 can use the rewrap backend 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 rewrapped encrypted transaction data 190 from the encrypted transaction data and the rewrapped transaction key. In this way, the DTSP 140 with 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 rewrapped transaction data or a rewrapped transaction blob. This step of re-encrypting the transaction data on the rewrap backend 150 so that the transaction data is encrypted for decryption by the DTSP 140 can be referred to as rewrapping. The rewrap backend 150 can include a Hardware Security Module (HSM). Some or all of the encryption and decryption performed on the rewrap backend 150 can occur within the HSM. Further description of the rewrap backend 150 and the processes performed by the rewrap process described herein.

[0038] In some implementations, if the confirmation is verified, the rewrap backend 150 can use the rewrap backend 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 the rewrap KEK (corresponding to the DTSP KEK) and re-encrypt the transaction data using the transaction key to generate rewrapped encrypted transaction data 190.

[0039] The DTSP 140 can then decrypt the rewrapped encrypted transaction data 190 upon receipt. In some embodiments, decryption of some or all of the rewrapped encrypted transaction data 190 occurs on a DTSP controlled 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 application 112. The authorization response 192 can indicate whether authorization is granted or denied for the transaction.

[0040] Upon completion, a message can be sent back to the source application indicating whether the data transfer was approved. Additionally, 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.

[0041] FIG. 2 illustrates exemplary system components 200. The system components can include components on a device 210 and components in a backend 230. The device 210 includes a reader 212 and a secure element 220. The reader 212 is hosted on the device's typical hardware. For example, the reader 212 has access to a typical processor used for most or all applications, also known as an application processor. Similarly, the reader 212 uses memory (e.g., random access memory, short-term memory, or volatile memory) and storage (e.g., a solid-state drive or other long-term or non-volatile storage). There is also the secure element 220, which hosts a virtual terminal 222, a cryptographic applet 224 (also referred to as "crypto applet 224" in FIG. 2), and an authorizer 226 (also referred to as an authorizer application). The backend 230 represents a device external to the server device or general-purpose device. The device 210, reader 212, secure element 220, virtual terminal 222, rewrap backend 240, and terminal backend 250 correspond to the device 110, reader 120, secure element 124, virtual terminal 126, rewrap backend 150, and terminal backend 130 in FIG. 1, respectively.

[0042] In some implementations, the reader 212 is implemented in software using some or all of the hardware components of the general-purpose device. The reader 212 may execute on a processor of the device 210 along with other applications and processes. For example, the reader 212 may execute on an application processor of the device 210. The reader 212 may also include cryptographic services as described herein.

[0043] Reader 212 includes prompt UI 214. Prompt UI 214 is used to indicate that virtual terminal 222 is ready to receive second data from a user. For example, prompt UI 214 can be used to indicate that a user should present the second data. In some implementations, prompt UI 214 can be used to indicate that a user should swipe, tap, or insert a card, or to use some type of digital wallet on a mobile device. Prompt UI 214 can be used to indicate a location on the multipurpose device where the user should present the second data. For example, prompt UI 214 can indicate to a user where to tap their card on the multipurpose device.

[0044] The reader 212 also includes a daemon 216 and an instrument reader 218. The daemon 216 may be used to execute processes and generate data associated with the device 210 that is not processed by the secure element 220. The daemon 216 may also be used to process second data obtained by the instrument reader 218. The instrument reader 218 is used to read the second data from the user and process the second data.

[0045] Device 210 may also include secure element 220. Secure element 220 is an element designed for security on a general-purpose device. In some implementations, secure element 220 is a chip or hardware module separate from the device's processor. For example, secure element 220 may operate on a chip separate from the processor running reader 212. In some implementations, secure element 220 is a software module that includes additional software security features for executing processes, and reader 212 may not use those additional software security features. In some implementations, secure element 220 is used specifically only by device 210 and runs only processes associated with device 210. In some implementations, secure element 220 runs some processes associated with device 210 and also runs processes for other applications on the general-purpose device that require additional security features.

[0046] The secure element 220 houses a virtual terminal 222, a crypto applet 224, and an authorizer 226. The secure element 220 can house multiple virtual terminals 222 corresponding to different pairs of source apps and DTSPs. The virtual terminal 222 has a virtual terminal kernel (also called a terminal kernel) that is configurable by a kernel token. The virtual terminal 222 is designed to encrypt data. For example, the virtual terminal 222 encrypts transaction data generated from second data and first data. The virtual terminal 222 can use many types of keys, hashes, and other cryptographic techniques when encrypting data. Examples of encryption performed by the virtual terminal 222 are included herein. The crypto applet 224 performs cryptographic operations. In some examples, the secure element 220 can host multiple crypto applets that can perform different cryptographic operations. In some examples, the crypto applet 224 can correspond to a source application. In some examples, the crypto applet 224 can correspond to a grouping of similar cryptographic operations. In some examples, the cryptographic applet 224 may be used by the virtual terminal 222 to perform cryptographic operations. The virtual terminal 222 may represent a terminal instantiated for use by the source application and DTSP, and the cryptographic applet 224 may provide cryptographic operations for encryption, decryption, etc. The authorizer 226 may be an application within the secure element 220 that provides authorization status for types of cryptographic operations that the cryptographic applet 224 can perform. For example, the authorizer 226 may store digital flags that indicate whether certain types of operations may be performed by the cryptographic applet 224. The authorizer 226 may set these flags based on authorization criteria received via an authorization token, as described herein. The authorizer 226 may be configured to update the digital flags when the authorization criteria are no longer complied with. For example, the authorization criteria may indicate a period of time for which the cryptographic operation is authorized. In another example, the authorization criteria may indicate a number of times the cryptographic operation is authorized to be performed.

[0047] Backend 230 represents system components that may not be stored on device 210. In some implementations, backend 230 represents one or more devices that typically have server functionality. Backend 230 can include rewrap backend 240 and terminal backend 250. Terminal backend can include API gateway 268, kernel manager 260, authorizer manager 262, authentication subsystem 264, and monitoring subsystem 266.

[0048] The rewrap backend 240 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 being decrypted using the rewrap backend private key) with a KEK associated with the DTSP. The rewrap backend 240 and the processes performed by the rewrap backend 240 are described further herein.

[0049] The API gateway 268 is used to mediate interactions between the device 210 and the terminal backend 250. For example, the API gateway 268 mediates communication, interactions, and transmissions between the device 210 and the kernel manager 260, the authorization manager 262, the authentication subsystem 264, and the monitoring subsystem 266.

[0050] The kernel manager 260 can be used to create and generate kernel tokens. The kernel manager 260 can also be used to generate scripts for the configuration of the virtual terminal 222 in the secure element 220 of the device 210.

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

[0052] The authentication subsystem 264 may be used to authorize and verify devices (e.g., mobile devices and servers) using the virtual terminal system. The authentication subsystem 264 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 may not exactly match or correspond to the transaction.

[0053] The monitoring subsystem 266 may be used to monitor transactions and devices (e.g., virtual terminals 222 and readers 212) 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.

[0054] 3 shows an example block diagram 300 with example systems and components for implementing the virtual terminal technology described herein. A device 310 (e.g., device 110 of FIG. 1 ) includes a source application 312 (e.g., source application 112 of FIG. 1 ) that interacts with an SDK 314 (e.g., SDK 114 of FIG. 1 ) to send data to a reader 320 (e.g., reader 120 of FIG. 1 ). The source application 312 can also communicate with a DTSP (e.g., DTSP 140 of FIG. 1 ) for initialization of an authorizer 328 to authorize a secure element 324 to perform operations. A virtual terminal 326 (e.g., virtual terminal 126 of FIG. 1 ) is hosted within the secure element 324 (e.g., secure element 124 of FIG. 1 ). The secure element 324 also hosts a crypto applet 322 (e.g., crypto applet 224 of FIG. 2 ). The secure element 324 also hosts an authorizer 328 (eg, authorizer 225 of FIG. 2).

[0055] FIG. 4 shows a sequence diagram 400 of an exemplary high-level sequence for implementing the virtual terminal techniques described herein. The exemplary sequence includes initializing an authorizer 446 that can authorize the secure element 324 and / or the crypto applet 322 of FIG. 3 to perform operations. The sequence diagram 400 may describe operations between the systems and components of FIG. 3. The systems and components of FIG. 3 are described herein in conjunction with the operations of the sequence diagram 400. The DTSP 440, source application 442, reader 444, authorizer 446, and terminal backend 448 of FIG. 4 correspond to the DTSP 340, source application 312, reader 320, authorizer 328, and terminal backend 330 of FIG. 3, respectively. The exemplary sequence of sequence diagram 400 may be referred to as initializing the authorizer, setting the permission criteria for the operation, and / or setting the permission status for the operation. Exemplary operations may include sending data for data transfer, encrypting specific data, decrypting specific data, encrypting data with a specific key, decrypting data with a specific key, and generating a public and private key pair for use in asymmetric cryptography.

[0056] In block 402, the source application 442 may request DTSP permission 402 from the DTSP 440 to perform an operation. As shown in FIG. 3, the source application 312 may send a permission request 370 to the DTSP 340. The permission request 370 may include data regarding the operation for which the source application 312 seeks permission. For example, the operation may be a data transfer involving the use of Key A. Key A may be stored in the crypto applet 322 and / or the secure element 324. The data regarding the operation may include Key A and that the operation is a data transfer. The permission request 370 may include metadata regarding the source application 312 and the device 310. The permission request 370 may also include operation information. For example, if the operation is a data transfer as described in connection with FIG. 1, the permission request 370 may include data transfer information and transaction information.

[0057] In block 404, the DTSP 440 may authenticate the permission request 370. The DTSP 440 may examine the metadata of the permission request 370 and data regarding the operation for which the source application 442 is seeking permission. The DTSP 440 may authenticate that the identified source application 442 is seeking permission and that the source application 442 may be authorized to perform the particular operation. If the DTSP 440 authenticates the permission request 370 as valid, the DTSP 440 may generate a DTSP authorization token. The DTSP authorization token may include data regarding the operation for which the source application 442 is seeking permission. For example, the DTSP authorization token may indicate which operation is authorized. Continuing with the exemplary operation of data transfer involving the use of Key A, the DTSP authorization token may include the operation type (in this case, data transfer) and Key A. Additionally, the DTSP authorization token may include one or more permission criteria. The one or more permission criteria may indicate the boundaries of the permission. For example, the permission criteria may include the number of times the operation may be performed. In another example, the permission criteria may include a time period during which the operation is permitted to be performed. For example, the operation may be permitted to be performed for 10 seconds, 5 minutes, 1 hour, 1 day, 1 week, or any amount of time therebetween, or any other time increment. In some examples, the DTSP permission token may not include one or more permission criteria. In block 406, the source application 442 may receive the DTSP permission. As shown in FIG. 3, the DTSP 340 may send an authorization response 372 to the source application 312. The authorization response 372 may include the DTSP permission token.

[0058] In block 408, the source application 442 may send a request to the reader 444 to initialize the authorizer 446. In some examples, this request may be referred to as an authorizer initialization request or an authorizer application initialization request. As shown in FIG. 3, the source application 312 may communicate with the reader 320 by using the SDK 314.

[0059] In block 410, the reader 444 may request a nonce from the authorizer 446. As shown in FIG. 3, the reader 320 may send a nonce request 374 to the authorizer 328 hosted by the secure element 324. The authorizer 328 may generate a nonce 376. The nonce 376 may be a random number or a string. The nonce 376 may be used to identify that the authorization token is intended for the authorizer 328. In this manner, the nonce 376 functions as a random identifier known only by the authorizer 328 and / or the secure element 324. In some examples, the nonce 376 may be encrypted. The authorizer 328 may store the nonce 376 for later comparison with the authorization token. The authorizer 328 may also start a timer associated with the nonce 376 such that the authorization token associated with the nonce 376 is valid only if received before the expiration of the timer associated with the nonce 376. In block 412 , the reader 444 may receive the nonce 376 from the authorizer 446 .

[0060] At block 414, the reader 444 may generate a verification block 378. In some examples, the verification block 378 may include a nonce 376. In some examples, the verification block 378 may include a DTSP authorization token. In some examples, the verification block 378 may include one or more authorization criteria of the DTSP authorization token. In some examples, the verification block 378 may include device metadata. The device metadata may include a software version of the operating system of the device 310, a software version of the operating system of the secure element 324, a software version of the reader 320, and a software version of the source application 312. The device metadata may also include a unique device identifier associated with the device 310 and / or a unique secure element identifier associated with the secure element 324. The device metadata may include location information of the device 310, such as Global Positioning System (GPS) coordinates.

[0061] In block 416, the reader 444 may send a verification block and request an authorization token from the terminal backend 448. As shown in Figure 3, the reader 320 may send a verification block 378 to the terminal backend 330.

[0062] In block 418, the terminal backend 448 can authenticate the verification block. As shown in FIG. 3 , the terminal backend 330 can authenticate the verification block 378. The terminal backend 330 can authenticate and / or verify the device metadata of the verification block 378. For example, the terminal backend 330 can determine whether the verification block 378 from the device 310 has a valid combination of one or more of the software version of the operating system of the device 310, the software version of the operating system of the secure element 324, the software version of the reader 320, and the software version of the source application 312. In another example, the terminal backend 330 can determine whether the verification block 378 of the device 310 has a valid unique device identifier associated with the device 310 and / or the unique secure element identifier associated with the secure element 324. For example, a user associated with the device 310 and / or the secure element 324 can report the device 310 and / or the secure element 324 as lost, hacked, or unsecured. In some examples, the terminal backend 330 can verify that the device 310 is within a geographic boundary for valid use as a virtual terminal. The terminal backend 330 can also authenticate the DTSP authorization token. The terminal backend 330 can determine whether the DTSP authorization token is valid and / or authentic. The terminal backend 330 can also determine whether the DTSP authorization token corresponds to the device metadata. After authenticating the verification block 378 and the device metadata, the terminal backend 330 can generate an authorization token. The authorization token can indicate which operations are permitted. The authorization token can also include one or more authentication criteria. In some examples, the authorization token has the same one or more authentication criteria as the DTSP authorization token. In some examples, the authorization token has different authentication criteria than the DTSP authorization token.For example, the permitted actions may be a set or a subset of the actions permitted in the DTSP authorization token. In some examples, the terminal backend 330 may generate authentication criteria for the authorization token. In some examples, the terminal backend 330 may have predefined authentication criteria for certain types of actions. The terminal backend 330 may generate a signed verification block 380. The signed verification block 380 may include the authorization token and the nonce 376. The signed verification block 380 may be signed and / or encrypted by a terminal backend private key. The terminal backend private key may correspond to an authorizer public key. The authorizer 328 may have the authorizer public key to decrypt the signed verification block 380.

[0063] In block 420, the terminal backend 448 can send the signed verification block to the reader 444. As shown in FIG. 3, the terminal backend 330 can send the signed verification block 380 to the reader 320. In some examples, the terminal backend 330 can send the signed verification block 380 to the secure element 324 and directly to the authorizer. In block 422, the reader 444 can send the signed verification block to the authorizer 446. As shown in FIG. 3, the reader 320 can send the signed verification block 380 to the authorizer 328.

[0064] In block 424, the authorizer 446 may authenticate the signed verification block 424. The authorizer 446 may authenticate the signed verification block by verifying the signature of the terminal backend 448. The authorizer 446 may decrypt the signed verification block using an authorizer public key that corresponds to the terminal backend private key. The authorizer public key may be injected into the authorizer 446 and / or the secure element in a secure manner before this verification and before the sequence diagram of 400. The authorizer 446 may then verify the nonce (e.g., nonce 376). The authorizer 446 may determine whether the signed verification block includes a nonce and whether the nonce matches a nonce that the authorizer 446 previously generated. The authorizer 446 may also determine whether the nonce is still valid, for example, whether an associated timer has not yet expired.

[0065] In block 426, the authorizer 446 may set permission criteria for the operation. The authorizer may determine one or more permission criteria for the operation from the permission token in the signed verification block. The one or more permission criteria dictate when the operation may be performed by a crypto applet (e.g., crypto applet 322) and / or a secure element. The one or more permission criteria may indicate the boundaries of the permission. For example, the permission criteria may include the number of times the operation may be performed. In another example, the permission criteria may include the period of time the operation is allowed to be performed. For example, the operation may be allowed to be performed for 10 seconds, 5 minutes, 1 hour, 1 day, 1 week, or any amount of time therebetween, or any other time increment. The authorizer 446 may maintain the permission status of the operation based on the permission criteria. The permission status may be allowed or unauthorized. When the authorizer 446 sets the permission criteria for the operation, the authorizer 446 may set the permission status to allowed. The permission status remains set to allowed as long as the permission criteria are met. The authorization status becomes unauthorized as soon as the authorizer 446 detects non-compliance with the authorization criteria, for example, if the time period for authorization has expired or if the operation has occurred the authorized number of times.

[0066] Referring now to the drawings, FIG. 5 shows an example block diagram 500 with example systems and components for implementing the virtual terminal techniques described herein. A device 510 (e.g., device 310 of FIG. 3 ) includes a source application 512 (e.g., source application 312 of FIG. 3 ) that interacts with an SDK 514 (e.g., SDK 314 of FIG. 3 ) to send data to a reader 520 (e.g., reader 320 of FIG. 3 ). The source application 312 can also communicate with a secure element 524 via the reader 520 to perform operations. A virtual terminal 526 (e.g., virtual terminal 326 of FIG. 3 ) is hosted within the secure element 524 (e.g., secure element 324 of FIG. 3 ). The secure element 524 also hosts a crypto applet 522 (e.g., crypto applet 322 of FIG. 3 ). The secure element 524 also hosts an authorizer 528 (e.g., authorizer 328 of FIG. 3 ).

[0067] FIG. 6 illustrates a sequence diagram 600 of an exemplary high-level sequence for implementing the virtual terminal techniques described herein. The exemplary sequence includes a crypto applet 652 requesting the authorization status of an operation before performing the operation. Sequence diagram 600 may describe operations between the systems and components of FIG. 5. The systems and components of FIG. 5 are described herein in conjunction with the operations of sequence diagram 600. Authorizer 650, crypto applet 652, reader 654, and source application 656 of FIG. 6 correspond to authorizer 528, crypto applet 522, reader 520, and source application 512 of FIG. 5, respectively. The exemplary sequence of sequence diagram 600 may be referred to as checking the authorization status of an operation.

[0068] Prior to block 602, the reader 654 or source application 656 may indicate operations to be performed, including operations performed by the crypto applet 652. In block 602, the instrument 658 may send encrypted instrument data to the reader 654 for use in the operation. As shown in FIG. 5 , in some examples, the encrypted instrument data 582 may be sent to the virtual terminal 526, which may send the encrypted instrument data 582 to the reader 520. In some examples, the instrument 658 may send the encrypted instrument data directly to the reader 654. As described herein, the instrument 658 may be a card bearing data, such as a credit card, debit card, or other digital data-carrying card. In this example, the instrument data may be encrypted with a public key. The corresponding private key may reside in the crypto applet 652. In block 604, the reader 654 may send the encrypted instrument data to the crypto applet 652.

[0069] At block 606, crypto applet 652 may request the permission status of the operation from authorizer 650. As shown in FIG. 5, crypto applet 522 may request the permission status from authorizer 528. At block 608, authorizer 650 may check the permission status of the operation. For example, authorizer 650 may check whether the permission status of the operation is authorized or unauthorized. As described in connection with FIG. 4, the permission status of the operation may be pre-initialized using permission criteria. As soon as authorizer 650 detects non-compliance with the permission criteria for the operation, authorizer 650 sets the permission status for the operation to unauthorized. At block 610, authorizer 650 may send the permission status of the operation to crypto applet. In other words, crypto applet 652 may receive the permission status of the operation.

[0070] Blocks 620, 622, and 624 illustrate example operations by the crypto applet 652 to decrypt instrument data for the device 658. In block 620, the crypto applet 652 may decrypt the encrypted instrument data after determining that the permission status for decrypting the encrypted instrument data is permitted. As described herein, the permission status and operation may be associated with decrypting particular data, such as encrypted instrument data. Alternatively, the permission status and operation may be associated with using a particular key to decrypt the encrypted instrument data. For example, the encrypted instrument data may be encrypted with the public key of the device 658 that corresponds to the private key of the crypto applet 652. Decrypting the encrypted instrument data may generate decrypted instrument data. In block 622, the crypto applet 652 may send the decrypted instrument data to the reader 654. In block 624, the reader 654 may send the decrypted instrument data to the source application 656.

[0071] Blocks 630, 632, 634, 636, 638, and 640 illustrate example operations by the crypto applet 652 to generate an authenticated command for the device 658. In block 630, the crypto applet 652 may generate the authenticated command after determining that the permission status for generating the authenticated command is permitted. The authenticated command may include an action for the device to perform. For example, the authenticated command may indicate that the device 658 should transfer data to the source application 656. For example, the device 658 may have a store of value (e.g., digital currency or any currency) that can be transferred to the source application 656. The crypto applet 652 may encrypt the authenticated command with a private key that corresponds to a public key on the device 658. In some examples, the crypto applet 652 may encrypt the authenticated command with a public key that corresponds to a private key on the device 658. In this manner, both the crypto applet 652 and the device 658 authenticate the authenticated command. This may be referred to as mutual authentication.

[0072] At block 632, the crypto applet 652 may send the authenticated command to the reader 654. At block 634, the reader 654 may send the authenticated command to the device 658. At block 636, the device 652 may execute the authenticated command after verifying the authenticity of the authenticated command. For example, the device 658 may decrypt the authenticated command using the device's 658 public key corresponding to the crypto applet's 652 private key. In some examples, the device 658 may decrypt the authenticated command using the device's 658 private key corresponding to the crypto applet's 652 public key. The device 658 may also verify other metadata in the authenticated command to verify that the crypto applet 652 is valid. The device 652 may execute the authenticated command to generate an authenticated command result. For example, the device 652 may perform a data transfer of a value to the source application 656 based on the authenticated command. In block 638, the device 658 may send the authenticated command results to the reader 654. In block 640, the reader 654 may send the authenticated command results to the source application 656.

[0073] FIG. 7 shows a flowchart illustrating an example process 700 for the techniques described herein, according to at least one example. Process 700 is illustrated as a logical flow diagram, with each operation in the flow diagram representing a sequence of actions that may be implemented in hardware, computer instructions, or a combination thereof. In the context of computer instructions, the actions represent computer-executable instructions stored on one or more computer-readable storage media that, when executed by one or more processors, perform the recited actions. Typically, computer-executable instructions include routines, programs, objects, components, data structures, etc. that perform particular functions or implement particular data types. The order in which the actions are described is not intended to be construed as limiting, and any number of the described actions can be combined in any order and / or in parallel to implement a process.

[0074] At block 702, process 700 may include receiving, by an authorizer application (e.g., authorizer 328 of FIG. 3 ) hosted by a secure element (e.g., secure element 324 of FIG. 3 ) of a user device (e.g., device 310 of FIG. 3 ). The secure element may be a hardware module configured for security and cryptography associated with one or more processors and one or more memories. The secure element may be separate from a reader application (e.g., reader 320 of FIG. 1 ), a second one or more memories, and a second one or more processors of the user device. The authorization token may be associated with the operation of a crypto applet (e.g., crypto applet 322 of FIG. 3 ) hosted by the secure element. A first server (e.g., terminal backend 330 of FIG. 3 ) may be configured to generate the authorization token.

[0075] At block 704, process 700 may include authenticating, by the authorizer application, the authorization token. At block 706, process 700 may include setting, by the authorizer application, authorization criteria for operations of the cryptographic applet based at least in part on the authorization token. The authorization criteria may include an authorization period. The authorization criteria may include a number of times the operation is allowed to be performed.

[0076] At block 708, process 700 may include receiving, by the authorizer application, a permission status request from the crypto applet. The permission status request may correspond to an action. At block 710, process 700 may include verifying, by the authorizer application, that the permission status request complies with permission criteria.

[0077] At block 712, the process 700 may include sending, by the authorizer application, the authorization status to the crypto applet. At block 714, the process 700 may include performing, by the crypto applet, an action based at least in part on the authorization status.

[0078] Process 700 may further include generating a nonce by the authorizer application. Authenticating the authorization token may be based at least in part on the nonce. Process 700 may further include sending the nonce to a reader application on the user device by the authorizer application. Process 700 may further include sending the nonce to a first server by the reader application. The first server may be configured to generate the authorization token based at least in part on the nonce. Process 700 may further include sending device information by the reader application on the user device to the first server. The first server may be configured to generate the authorization token based at least in part on the device information. Process 700 may further include sending a data transfer service provider authorization request to a second server (e.g., DTSP 340 of FIG. 3 ) by the reader application on the user device. Process 700 may further include receiving the data transfer service provider authorization token from the second server by the reader application. The process 700 can further include transmitting, by the reader application, the data transfer service provider authorization token to the first server. The first server can be configured to generate an authorization token based at least in part on the data transfer service provider authorization token. In some examples, the data transfer service provider authorization token can include at least a portion of the authorization criteria.

[0079] Exemplary methods, systems, and computer-readable media for enabling a virtual terminal for receiving touchless data transfers on a mobile device are described above. Some or all of these systems and methods may be implemented, at least in part, by architectures such as those illustrated in at least FIGS. 1-7, but this is not required. While many of the embodiments are described above with reference to personal and / or payment-related information, it should be understood that any type of user or non-user information (e.g., any type of data) may be managed using these techniques. Furthermore, various non-limiting embodiments have been described in the foregoing description. For purposes of explanation, specific configurations and details have been set forth to provide a thorough understanding of the embodiments. However, it will be apparent to those 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 described embodiments.

[0080] 8 is a block diagram of an exemplary electronic device 800. Device 800 generally comprises a computer-readable medium 802, a processing system 804, an input / output (I / O) subsystem 806, radio circuitry 808, and audio circuitry 810 including a speaker 812 and a microphone 814. These components may be coupled by one or more communication buses or signal lines 803. Device 800 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).

[0081] It will be apparent that the architecture shown in Figure 8 is only one example architecture for device 800, and that device 800 may have more, fewer, or differently configured components than those shown. The various components shown in Figure 8 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.

[0082] The radio circuitry 808 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 808 may use various protocols, for example, as described herein. In various embodiments, the radio circuitry 808 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), Long Term Evolution (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.

[0083] The radio circuitry 808 is coupled to the processing system 804 via a peripheral interface 816. The peripheral interface 816 may include conventional components for establishing and maintaining communications between peripherals and the processing system 804. Voice and data information received by the radio circuitry 808 (e.g., in a speech recognition application or a voice command application) is transmitted via the peripheral interface 816 to one or more processors 818. The one or more processors 818 may be configured to process various data formats for one or more application programs 834 stored on the medium 802.

[0084] The peripheral interface 816 couples input / output peripherals of the device 800 to one or more processors 818 and computer-readable medium 802. The one or more processors 818 communicate with the computer-readable medium 802 via a controller 820. The computer-readable medium 802 may be any device or medium capable of storing code and / or data for use by the one or more processors 818. The computer-readable medium 802 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 and / or optical storage devices such as disk drives, magnetic tape, compact discs (CDs), and digital video discs (DVDs). In some embodiments, the peripheral interface 816, the one or more processors 818, and the controller 820 may be implemented on a single chip, such as the processing system 804. In some other embodiments, they may be implemented on separate chips.

[0085] The processor(s) 818 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) 818 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 324 of FIG. 3 is separate from the processor 818 discussed herein.

[0086] Device 800 also includes a power system 842 that provides power to the various hardware components. Power system 842 can include a power management system, one or more power sources (e.g., battery, 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.

[0087] In some embodiments, device 800 includes a camera 844. In some embodiments, device 800 includes a sensor 846. The sensor may include an accelerometer, a compass, a gyrometer, a pressure sensor, an audio sensor, a light sensor, a barometer, etc. The sensor 846 may be used to sense an aspect of a location, such as an audio signature or a light signature of the location.

[0088] In some embodiments, device 800 may include a GPS receiver, sometimes referred to as a GPS unit 848. Mobile devices may use satellite navigation systems, such as the Global Positioning System (GPS), to obtain position information, timing information, altitude, or other navigation information. During operation, the GPS unit may receive signals from GPS satellites orbiting the Earth. The GPS unit analyzes the signals to generate travel time and distance estimates. The GPS unit may determine the current position (current location) of the mobile device. Based on these estimates, the mobile device may determine a location fix, altitude, and / or current velocity. The location fix may be geographic coordinates, such as latitude and longitude information.

[0089] The one or more processors 818 execute various software components stored on the medium 802 to perform various functions for the device 800. In some embodiments, the software components include an operating system 822, a communications module (or instruction set) 824, a location module (or instruction set) 826, and other application programs (or instruction sets) 834.

[0090] Operating system 822 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. An 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.

[0091] Communications module 824 facilitates communication with other devices via one or more external ports 836 or via wireless circuitry 808 and includes various software components for handling data received from wireless circuitry 808 and / or external port 836. External port 836 (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.).

[0092] The location / motion module 826 can assist in determining the current position (e.g., coordinates or other geographic location identifier) ​​and movement of the device 800. Modern positioning systems include satellite-based positioning systems such as the Global Positioning System (GPS), cellular network positioning based on “cell ID,” and Wi-Fi positioning technology based on Wi-Fi networks. GPS also determines position estimates based on the visibility of multiple satellites, which may not be visible (or have weak signals) indoors or in “city canyons.” In some embodiments, the location / motion module 826 receives data from the GPS unit 848 and analyzes the signals to determine the current position of the mobile device. In some embodiments, the location / motion module 826 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 their locations. Information identifying the Wi-Fi or cellular transmitter is received by the radio circuitry 808 and communicated to the location / motion module 826. In some embodiments, the location 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 position coordinates of the corresponding transmitters and calculates estimated position coordinates for the device 800 based on the position coordinates of the corresponding transmitters. Regardless of the particular location technology used, the location / motion module 826 receives information from which a location fix can be derived, interprets that information, and returns location information such as geographic coordinates, latitude / longitude, or other location fix data.

[0093] The one or more applications 834 on the device 800 may include any application installed on the device 800, 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, audio duplication, a music player (which plays music recorded in one or more files, such as MP3 or AAC files), the reader 320 of FIG. 3 , the PIN user interface 322 of FIG. 3 , the source application 312 of FIG. 3 , etc. As discussed above, different applications may be installed in the secure element 324 of FIG. 3 . For example, the authorizer 328 and the encryption applet 322 of FIG. 3 may be applications installed in the secure element 324 of FIG. 3 . These applications in the secure element 324 of FIG. 3 may be installed by the device manufacturer and may not be added and / or removed by the end user.

[0094] 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.

[0095] The I / O subsystem 806 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.

[0096] In some embodiments, I / O subsystem 806 can include a display and user input devices such as a keyboard, a mouse, and / or a trackpad. In some embodiments, I / O subsystem 806 can include a touch-sensitive display. The touch-sensitive display can 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 (together with any associated modules and / or instruction sets in computer-readable medium 802) 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 touchscreen when the contact occurs. In some embodiments, the point of contact between the touch-sensitive display and the user corresponds to one or more of the user's fingers. The user can contact the touch-sensitive display using any suitable object or accessory, such as a stylus, pen, finger, etc. The touch-sensitive display surface can detect the contact and 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.

[0097] Additionally, I / O subsystem 806 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 ending communications, etc. In some embodiments, in addition to a touchscreen, device 800 may include a touchpad (not shown) for activating or deactivating certain functions. In some embodiments, the touchpad may be a touch-sensitive area of ​​the device that, unlike the touchscreen, does not display visual output. The touchpad may be a touch-sensitive surface separate from the touch-sensitive display or an extension of the touch-sensitive surface formed by the touch-sensitive display.

[0098] 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 the 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.

[0099] Any of the software components or functions described in this application may be implemented as software code executed by a processor using any suitable computer language, such as, for example, Java, C++, or Perl, using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions or commands on a computer-readable medium for storage and / or transmission, suitable media including random access memory (RAM), read-only memory (ROM), magnetic media such as a hard drive or 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.

[0100] Such programs may also be encoded and transmitted using carrier wave 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 can 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 medium may reside on or within a single computer program product (e.g., a hard drive or an entire computer system), or may reside on or within different computer program 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.

[0101] 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 discs (CDs) or digital versatile discs (DVDs), and flash memory. A computer-readable storage medium encoded with program code may be packaged with a compatible device or provided separately from other devices. Additionally, the program code may be encoded and transmitted over wired and / or wireless networks conforming to various protocols, including the Internet, thereby enabling distribution, for example, via Internet download. Any such computer-readable medium may reside on or within a single computer product (e.g., a solid-state drive, hard drive, CD, or an entire computer system) or 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.

[0102] 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 present disclosure as set forth in the appended claims.

[0103] Other variations are within the spirit and scope of the present disclosure. Accordingly, 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 should be understood, however, that there is no intention to limit the disclosure to the particular form or forms disclosed; 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.

[0104] In the context of describing the disclosed embodiments (particularly in the context of the claims that follow), use of the terms "a," "an," "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 fully 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 individually referring to each individual value falling within the range, and each individual value is encompassed herein as if it were individually stated herein. All methods described herein can 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 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.

[0105] 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.

[0106] Preferred embodiments of the present disclosure are described herein, including the best mode known to the inventors for carrying out the disclosure. Variations of these preferred embodiments may become apparent to those of ordinary skill in the art upon reading the foregoing description. The inventors anticipate that such variations will be employed by those of ordinary skill 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. Furthermore, any combination of the above-described 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.

[0107] All references, including publications, patent applications, and patents, cited in this specification 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.

[0108] As explained above, one aspect of the present technology is the sharing of personal and / or payment-related data between user devices, which may include storing some aspects of the data on a server. This 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 related to a user's credit card information, date of birth, or any other identifying or personal or health information.

[0109] 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.

[0110] 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 maintaining the strict confidentiality of personal information data. Such policies should be easily accessible to 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 the user's informed consent is obtained. Furthermore, such entities should consider taking all necessary measures to protect and secure access to such personal information data and to ensure that others with access to the personal information data adhere to their privacy policies and procedures. Furthermore, such entities may be able to undergo third-party assessments to demonstrate their adherence to widely accepted privacy policies and practices. Furthermore, policies and practices should be tailored to the specific types of personal data collected and / or accessed and should comply with 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.

[0111] 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 advertising delivery services or other services related to health record management, the present disclosure 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 the access or use of personal information. For example, the user may be notified upon downloading an app that will access the user's personal information data, and then again immediately before the app accesses the user's personal information data.

[0112] Furthermore, it is the intent of this disclosure that personal information data should be managed and processed in a manner that minimizes the risk of unintentional or unauthorized access or use. Risk can be minimized by limiting data collection and deleting data when it is no longer needed. Furthermore, where applicable, including in certain health-related applications, data anonymization can be used to protect user privacy. De-identification can be facilitated where appropriate by removing certain identifiers (e.g., date of birth, etc.), 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.

[0113] Thus, while this disclosure broadly covers the use of personal information data to implement one or more various disclosed embodiments, this disclosure also contemplates that the various embodiments may be implemented without requiring access to such personal information data, i.e., various embodiments of the present technology are not rendered inoperable by the absence of all or part of such personal information data.

Claims

1. 1. A method comprising: receiving, by an authorizer application hosted by a secure element of a user device, an authorization token associated with operation of a cryptographic applet hosted by said secure element; authenticating, by the authorizer application, the authorization token; establishing, by the authorizer application, authorization criteria for the operation of the cryptographic applet based at least in part on the authorization token; receiving, by the authorizer application, an authorization status request from the cryptographic applet, the authorization status request corresponding to the action; verifying, by the authorizer application, that the authorization status request complies with the authorization criteria; sending, by the authorizer application, an authorization status to the cryptographic applet; performing, by the cryptographic applet, the action based at least in part on the authorization status; A method comprising:

2. The method of claim 1 , wherein the authorization criteria includes an authorization period.

3. The method of claim 1 , wherein the permission criteria includes a number of times the action is permitted to be performed.

4. The method of claim 1 , wherein a first server is configured to generate the authorization token.

5. generating, by the authorizer application, a nonce, wherein authenticating the authorization token is based at least in part on the nonce; transmitting, by the authorizer application, the nonce to a reader application on the user device; 5. The method of claim 4, further comprising: transmitting, by the reader application, the nonce to the first server, the first server configured to generate the authorization token based at least in part on the nonce.

6. 5. The method of claim 4, further comprising transmitting, by a reader application of the user device, device information to the first server, the first server configured to generate the authorization token based at least in part on the device information.

7. sending, by a reader application of the user device, a data transfer service provider authorization request to a second server; receiving, by the reader application, a data transfer service provider authorization token from the second server; 5. The method of claim 4, further comprising: transmitting, by the reader application, the data transfer service provider authorization token to the first server, the first server configured to generate the authorization token based at least in part on the data transfer service provider authorization token.

8. The method of claim 7 , wherein a data transfer service provider authorization token comprises at least a portion of the authorization criteria.

9. 1. A user device, comprising: a secure element having one or more memories and one or more processors in communication with the one or more memories, the one or more processors executing instructions stored in the one or more memories to cause the secure element to: receiving, by an authorizer application of the secure element, an authorization token associated with operation of a cryptographic applet hosted by the secure element; causing the authorization token to be authenticated by the authorizer application; causing the authorizer application to set authorization criteria for the operation of the cryptographic applet based at least in part on the authorization token; receiving, by the authorizer application, an authorization status request from the cryptographic applet, the authorization status request corresponding to the action; causing the authorizer application to verify that the authorization status request complies with the authorization criteria; causing the authorizer application to transmit an authorization status to the cryptographic applet; The user device is configured to cause the cryptographic applet to perform the action based at least in part on the authorization status.

10. The user device of claim 9 , wherein a first server is configured to generate the authorization token.

11. a second one or more memories; a second one or more processors in communication with the second one or more memories and configured to execute instructions stored in the second one or more memories; 11. The user device of claim 10, wherein the secure element is a hardware module configured for security and cryptography, the secure element being separate from a reader application, the second one or more memories, and the second one or more processors.

12. The one or more processors: generating, by the authorizer application, a nonce, wherein authenticating the authorization token is based at least in part on the nonce; further configured to transmit, by the authorizer application, the nonce to a reader application on the user device; 12. The user device of claim 11, wherein the second one or more processors are further configured to transmit, by the reader application, the nonce to the first server, the first server configured to generate the authorization token based at least in part on the nonce.

13. 12. The user device of claim 11, wherein the second one or more processors are further configured to send, by the reader application, device information to the first server, and the first server is configured to generate the authorization token based at least in part on the device information.

14. The second one or more processors: sending, by the reader application, a data transfer service provider authorization request to a second server; receiving, by the reader application, a data transfer service provider authorization token from the second server; 12. The user device of claim 11, further configured to: send, by the reader application, the data transfer service provider authorization token to the first server, the first server configured to generate the authorization token based at least in part on the data transfer service provider authorization token.

15. A non-transitory computer-readable storage medium having stored thereon program instructions that, when executed by one or more processors of a user device, cause the user device to: receiving, by an authorizer application hosted by a secure element of a user device, an authorization token associated with operation of a cryptographic applet hosted by said secure element; authenticating, by the authorizer application, the authorization token; establishing, by the authorizer application, authorization criteria for the operation of the cryptographic applet based at least in part on the authorization token; receiving, by the authorizer application, an authorization status request from the cryptographic applet, the authorization status request corresponding to the action; verifying, by the authorizer application, that the authorization status request complies with the authorization criteria; sending, by the authorizer application, an authorization status to the cryptographic applet; and performing, by the cryptographic applet, the action based at least in part on the authorization status.

16. The non-transitory computer-readable storage medium of claim 15 , wherein the permission criteria includes a number of times the operation is permitted to be performed.

17. The non-transitory computer-readable storage medium of claim 15 , wherein a first server is configured to generate the authorization token.

18. generating, by the authorizer application, a nonce, wherein authenticating the authorization token is based at least in part on the nonce; transmitting, by the authorizer application, the nonce to a reader application on the user device; 20. The non-transitory computer-readable storage medium of claim 17, further comprising: transmitting, by the reader application, the nonce to the first server, wherein the first server is configured to generate the authorization token based at least in part on the nonce.

19. 20. The non-transitory computer-readable storage medium of claim 17, further comprising transmitting, by a reader application of the user device, device information to the first server, the first server configured to generate the authorization token based at least in part on the device information.

20. sending, by a reader application of the user device, a data transfer service provider authorization request to a second server; receiving, by the reader application, a data transfer service provider authorization token from the second server; 20. The non-transitory computer-readable storage medium of claim 17, further comprising: transmitting, by the reader application, the data transfer service provider authorization token to the first server, the first server configured to generate the authorization token based at least in part on the data transfer service provider authorization token.

Images