Secure pin input using virtual terminal

Abstract

Techniques are described herein for PIN input using a virtual terminal on a multi-purpose device to authorize data transfer. These techniques provide secure reception of each PIN number by a device and encryption of a PIN utility device, and while PIN input data is communicated, while still providing information to a server for further processing.

Description

[0001] Cross-reference to related applications

[0002] This application claims priority to U.S. Patent Application No. 18 / 374,414, filed September 28, 2023, entitled "SECURE PIN ENTRY USING AVIRTUAL TERMINAL", the entire contents of which are incorporated herein by reference.

[0003] This application relates to U.S. Patent Application No. 18 / 374,482, filed September 28, 2023, entitled “AUTHORIZER FOR OPERATIONS OF AVIRTUAL TERMINAL”, the contents of which are incorporated herein by reference. Background Technology

[0004] Electronic devices, especially portable electronic user devices, are rapidly becoming ubiquitous in modern society. These devices can be used as terminals for sending data to each other. The data sent may require encryption and decryption to protect sensitive information, including personal identification numbers (PINs). Attached Figure Description

[0005] Figure 1 A block diagram illustrating an embodiment of the present disclosure for performing the techniques described herein is shown.

[0006] Figure 2 A block diagram illustrating the technology described herein is shown according to an embodiment of the present disclosure.

[0007] Figure 3 A block diagram illustrating the technology described herein is shown according to an embodiment of the present disclosure.

[0008] Figure 4 A sequence diagram illustrating an embodiment of the present disclosure for performing the techniques described herein is shown.

[0009] Figure 5 A sequence diagram of embodiments of the present disclosure for performing the techniques described herein is shown.

[0010] Figure 6 A block diagram illustrating an embodiment of the present disclosure for performing the techniques described herein is shown.

[0011] Figure 7 A flowchart illustrating an embodiment of the present disclosure for performing the techniques described herein is shown.

[0012] Figure 8Example architectures or environments configured to implement the technologies described herein are illustrated according to embodiments of this disclosure. Detailed Implementation

[0013] In the following description, various examples will be described. For the purposes of explanation, many specific configurations and details are elaborated to provide a thorough understanding of the examples. However, it will also be apparent to those skilled in the art that some examples can be implemented without these specific details. Furthermore, well-known features may be omitted or simplified to avoid confusing the described examples.

[0014] Examples of this disclosure relate to methods, systems, apparatus, and computer-readable media, etc., for providing techniques for inputting a secure personal identification number (“PIN”) containing data transfer using a virtual terminal hosted (e.g., executed within) by a secure element of a user device. Unlike conventional PIN input, the techniques described herein enable the virtual terminal to securely encrypt both the data transfer information and the PIN for transmission on a multipurpose device (e.g., a mobile device, smartphone, tablet, etc.). A system including a virtual terminal may be configured to include a reader application (e.g., a data reader application that uses the operating system of the multipurpose device as a hub for the received information, usable by the data transfer-related application and the secure element), an internal short-range 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 may be integrated into the multipurpose device. The multipurpose device may also include a secure element, such as a tightly integrated hardware module designed for data security. The secure element can host the virtual terminal and encrypt the PIN (and related information) and the data transfer information. The security element may also not be a component of an external connection device (e.g., a dongle).

[0015] The technology described herein provides a mobile contactless data transfer device solution that allows users to accept data transfers and enter associated PINs using multipurpose devices (e.g., mobile devices, smartphones, tablets, etc.). Conventional PIN input systems require dedicated equipment and / or hardware separate from the multipurpose device (e.g., a dongle or terminal device). Virtual terminals are configured to support software-based terminals on multipurpose devices, eliminating the need for dedicated equipment and / or hardware for PIN input and data transfer. Additionally, some conventional PIN input systems convert the PIN's digits into a proprietary format for data security. However, data transfer service providers require information about the proprietary format to decrypt the PIN. The technology described herein enables data transfer service providers and data transfer processors to receive PINs in a common format that is easy to use. Source applications can collaborate with reader applications to facilitate data reception for data transfer transactions. Data transfer transactions may include a PIN as a data security protection. Mobile data transfer technology can be implemented via: (1) a third-party mobile data transfer application (source application) that integrates with a first-party (e.g., device-specific) data reader application on the application processor of a qualified mobile device of the source using one or more application programming interfaces (“APIs”) (collectively, “front-end integration”); and (2) a third-party data transfer system that integrates with a back-end platform (back-end platform) using the APIs (collectively, “back-end integration”). Two separate sets of APIs may be provided: one for third-party developers of the source application and one for data transfer service providers (“DTSPs”) contracted with the developers of the source application to facilitate transaction processing. The source application may be source-oriented and enable the source to accept contactless data transfers from users using digital or physical closed-loop trading financial instruments or open-loop data transfer financial instruments.

[0016] In some examples, PIN numbers can be received via a PIN user interface (“PIN UI”) and by a data reader application on the application processor of a multipurpose device. A first PIN number can be received by the PIN UI and transmitted to the data reader application. The data reader application can store the first PIN number in a first memory location and encrypt it using a public key. The public key may correspond to a private key stored in and used by a secure element. The data reader application can then transmit the encrypted first PIN number to the secure element. Similarly, a second PIN number can be received by the PIN UI and transmitted to the data reader application. The data reader application can store the second PIN number in the same first memory location and encrypt it using a public key. By using the same memory location, the data reader application prevents multiple PIN numbers from being stored simultaneously in insecure memory (e.g., device memory such as RAM or storage devices). Because the second PIN number is stored in the same memory location as the first PIN number, the value of the first PIN number is overwritten by the value of the second PIN number in the memory location. Likewise, each PIN number of a PIN can be stored in the same first memory location upon receipt. This increases the data security of the PIN because multiple PIN numbers and / or the entire PIN will never be stored in insecure memory.

[0017] The secure element can decrypt each PIN number using a private key corresponding to the public key. The secure element can also receive financial instrument information used for data transfer. The secure element can generate PIN blocks that include any combination of PIN, financial instrument information, and a symmetric transaction key. The symmetric transaction key can be encrypted using a repackaged backend public key to generate an encrypted transaction key. The repackaged backend public key can correspond to a repackaged backend private key known to the backend platform associated with the data transfer. The secure element can generate a PIN binary blob from the PIN block, the encrypted transaction key, and other metadata. The secure element can transmit the PIN binary blob to the data reader application. The data reader application can use the transport server key to encrypt the PIN binary blob to generate a reader PIN binary blob. The reader PIN binary blob can be transmitted from the data reader application to the source application. The source application can transmit the reader PIN binary blob to the DTSP.

[0018] DTSP may be unable to decrypt the reader PIN binary large object because DTSP may not possess the transport server key and the repackaged backend private key corresponding to the repackaged backend public key. DTSP can forward the reader PIN binary large object to a backend platform. The backend platform may have the transport server key and can decrypt the reader PIN binary large object. After decrypting the reader PIN binary large object, the backend platform has the PIN block, the encrypted transaction key, and other metadata. The backend platform can verify the other metadata to authenticate the PIN block. The backend platform may have the repackaged backend private key and can decrypt the encrypted transaction key. The decrypted transaction key can then be re-encrypted (also known as repackaged) using a key encryption key (“KEK”) shared between the hardware security module in DTSP's data delivery system (“DTSP HSM”) and the corresponding hardware security module on the backend platform. The re-encrypted transaction key can be referred to as the repackaged transaction key. The backend platform can generate a repackaged PIN binary large object from the PIN block and the repackaged transaction key. The backend platform can transmit the repackaged PIN binary large object to the DTSP, where the DTSP HSM can use the KEK of the DTSP HSM corresponding to the KEK of the backend platform to decrypt the repackaged transaction key.

[0019] The DTSP HSM can re-encrypt the decrypted transaction key using the Data Transfer Processor (DTP) KEK to generate a DTP-repackaged transaction key. The DTSP can then transmit the PIN block and the DTP-repackaged transaction key to the Data Transfer Processor. The DTP can have a shared DTPPKEK between the DTSP HSM and the corresponding DTP Hardware Security Module (DTP HSM). The DTP can use the DTP KEK to decrypt the DTP-repackaged transaction key. The DTP can then use the transaction key to decrypt the PIN block, verify the PIN's correctness, and authorize the associated data transfer.

[0020] Information related to the source's daily business operations (e.g., user authorization and transaction history) will be sent directly from DTSP's data delivery system to the source application, and may not go through the backend platform.

[0021] Now turn to the attached image. Figure 1An exemplary block diagram 100 is shown having exemplary systems and components for implementing the virtual terminal technology described herein. Device 110 (also referred to as a multipurpose device) includes a source application 112 (e.g., an application) that interacts with SDK 114 to transmit first data 180 to reader 120 (also referred to as a reader application). Reader 120 may be part of the operating system of the multipurpose device, configured to receive information that can be used by third-party applications and secure elements associated with the data transfer. For example, reader 120 may request information from a secure element on behalf of a third-party application (e.g., source application 112). Additionally, the reader may send information received on the device to the secure element and / or the third-party application, depending on different communication methods on the device. For example, information received via the device's UI interface or transmission standards (e.g., NFC, Bluetooth, WiFi, cellular connectivity, etc.) may be used to send information to the secure element and / or the third-party application. Before receiving the first data 180, reader 120 may interact with terminal backend 130 to initialize virtual terminal 126. Virtual terminal 126 is hosted within secure element 124. Any service or application (including virtual terminal 126) hosted within secure element 124 uses the processor and memory associated with secure element 124. Therefore, the application processor and memory of user equipment 110 may not be used by applications or services hosted by secure element. Data and information of any service or application hosted by secure element may have data protected as described herein. Secure element 124 is a system designed to enhance security, as described herein. For example, secure element 124 is a hardware module specifically designed for cryptography and data security of private and / or confidential data. A secure element may be a hardware chip that runs a specific set of programs / applications, stores private and / or confidential data, and provides controlled access to private and / or confidential data. The secure element can provide the following set of features at the hardware level: 1) detection of hacking attacks and / or data tampering attempts; 2) creation of a root of trust (RoT) platform for encryption and data security systems; 3) provision of secure storage for private encryption keys and private and / or confidential data; 4) cryptographically secure generation of random numbers; 5) key generation, such as private and public key pairs for asymmetric encryption; and 6) secure monitoring of system resources, such as detection of hardware configuration changes. The secure element 124 is decoupled from the application processor of device 110. The secure element 124 receives second data 182, which details how data can be delivered to the source associated with the source application 112.

[0022] Virtual terminal 126 can use first data 180 and second data 182 to generate transaction data. In some examples, a transaction may be referred to as a data transfer. As described herein, these terms may be used interchangeably in some instances. Security element 124 (and virtual terminal 126) can also communicate with terminal backend 130 for various security and encryption features described herein to encrypt the transaction data. In some specific implementations, security element 124 communicates with terminal backend 130 via reader 120, where the communication is encrypted. Virtual terminal 126 can encrypt the transaction data using a transaction key known only to virtual terminal 126 and / or security element 124. For example, the transaction key may be randomly generated by virtual terminal 126 at the time of the transaction. The transaction key is then encrypted with a repackaged backend public key (which corresponds to a repackaged backend private key held by terminal backend 130 and / or repackaged backend 150), as described herein. Thus, virtual terminal 126 has a transaction key encrypted with the repackaged backend public key and transaction data encrypted with that transaction key. The virtual terminal can generate an encrypted transaction binary large object 184 from the encrypted transaction key and the encrypted transaction data. The encrypted transaction binary large object 184 may include additional metadata. The use of the encrypted transaction binary large object 184 can prevent transaction data from being exposed to the outside of the secure element 124 before the DTSP 140 can process the transaction data.

[0023] Virtual terminal 126 can then transmit an encrypted transaction binary large object 184 to reader 120. Reader 120 may include additional metadata about the data transmission, which is encrypted using a transport server key as described herein. The encrypted metadata (using the transport server key) and the encrypted transaction binary large object 184 are used to generate an encrypted reader binary large object 186. In some implementations, the encrypted transaction binary large object 184 may also be encrypted using the transport server key. The use of the encrypted transaction binary large object 184 allows backend 150 to re-encapsulate the encrypted metadata to verify the transaction data without decrypting the transaction data encrypted with the transaction key. In some implementations, the combination of reader 120, secure element 124, and virtual terminal 126 may be referred to as a virtual terminal system.

[0024] Reader 120 may transmit an encrypted reader binary large object 186 to source application 112. Source application 112 may transmit the encrypted reader binary large object 186 and an authorization request 188 for the transaction to data delivery service provider (DTSP) 140. DTSP 140 may be unable to decrypt some or all of the encrypted reader binary large object 186 and transmits it to repackaging backend 150 for decryption. In some implementations, repackaging backend 150 may use a transport server key (which corresponds to the transport server key) to decrypt the encrypted metadata of the encrypted reader binary large object 186 and verify the various parts of the metadata to verify that the encrypted reader binary large object has been authorized by DTSP 140, source application 112, and / or end backend 130, as described herein. This allows the repackaging backend 150 to verify transactions and / or data transfers corresponding to the encrypted reader binary large object 186 (and the associated encrypted transaction binary large object 184) without seeing the underlying unencrypted transaction data. This ensures the privacy of the underlying transaction data because the source application 112 and the repackaging backend 150 never decrypt the transaction data encrypted with the transaction key. In some implementations, the repackaging backend 150 may also decrypt the internal encrypted transaction binary large object 184 to verify and validate the additional metadata and various parts of the transaction data.

[0025] Once the re-encapsulation backend 150 has verified the metadata of the encrypted reader binary large object 186, the re-encapsulation backend 150 can use the KEK, a symmetric key known to the DTSP, to re-encrypt the transaction key, allowing the DTSP to decrypt the transaction key (using the KEK) and subsequently the transaction data (using the transaction key). However, the transaction key is currently encrypted by the re-encapsulation backend public key. The re-encapsulation backend 150 can decrypt the transaction key using the re-encapsulation backend private key (which corresponds to the re-encapsulation backend public key). The re-encapsulation backend 150 then re-encrypts the transaction key using the KEK. In some implementations, the KEK of the re-encapsulation backend 150 may be referred to as the re-encapsulation KEK, and the KEK of the DTSP 140 may be referred to as the DTSP KEK. In some implementations, the re-encapsulation KEK and the DTSP KEK are functionally equivalent symmetric keys. The re-encrypted transaction key may be referred to as the re-encapsulated transaction key. Re-encryption may be referred to as re-encapsulation.

[0026] The repackaging backend 150 then generates repackaged encrypted transaction data 192, which includes a repackaged transaction key and encrypted transaction data. In some implementations, the repackaging backend 150 can generate repackaged encrypted transaction data 192 by encrypting both the transaction key and the encrypted transaction data (encrypted by the transaction key) using a KEK (as described herein). In this way, the repackaging backend decrypts various forms of encryption and then reencrypts the transaction data. The repackaging backend 150 can then transmit the repackaged encrypted transaction data 190 to DTSP 140.

[0027] DTSP 140 can use a KEK to decrypt the repackaged encrypted transaction data 190 and then process the data transfer. In some examples, the data transfer service provider can work with data transfer processor 160 for processing by sending transaction data to data transfer processor 160. An example data transfer processor could be a payment network operator. Another example data transfer processor could be the issuer of a financial instrument used for data transfer. In some examples, DTSP can send transaction data to a payment network operator, which can then send the transaction data to an issuer. For example, the financial instrument could be a credit card, and the issuer could be a bank. Once the data transfer has been processed or authorized, data transfer service provider 140 can send an authorization response 192 to source application 112. This can indicate that the second data has been verified and authorized, the transaction has been authorized, and the transaction has been completed.

[0028] In some cases, source application 112 is a source-oriented application responsible for initiating data transfer. An example source application is a merchant application responsible for initiating a sale or payment. The source application can be used to generate first data 180. In some implementations, the first data 180 may include data about the cost of the transaction, a description of the goods or services, a description of the time and place of the transaction, etc. Using SDK 114, source application 112 can communicate with reader 120 and initialize virtual terminal 126. For example, when a user initiates a transaction, source application 112 can contact reader 120 via SDK 114. During the initialization of virtual terminal 126, reader 120 initializes a specific virtual terminal 126 associated with source application 112 and DTSP 140. Therefore, different virtual terminals 126 will need to be initialized to communicate with different pairs of source applications 112 and DTSP 140.

[0029] In some examples, the source may be ready to begin a transaction (e.g., receiving data transfer), so the user can press "Start Transaction". Some transactions may be payment-related, allowing the user (e.g., a customer) to enter a value (e.g., $10) and press "Pay". In response, the system can contact the Software Development Kit (SDK) 114 and invoke a function (e.g., "Transaction"). In some examples, SDK 114 is a concrete implementation of the API described above regarding front-end integration. SDK 114 can then pass the first data to reader 120.

[0030] Prior to the transaction, reader 120 can be initialized and configured. Reader 120 can be dedicated to a specific pairing of source application 112 and DTSP 140. Reader 120 can then initiate a financial instrument reader. The financial instrument reader can be an application (e.g., corresponding to a second application where the source application is the first application), and can then control the user interface (UI) of device 110 to present the financial instrument reader UI. In some examples, the financial instrument reader UI can be presented on top of the source application UI, and the financial instrument reader UI can display information to the user identifying the requested data value (e.g., $10), the name of the source, and how / where to place their financial instrument (e.g., where to tap the user's financial instrument). In some implementations, the financial instrument reader is a card reader. In some cases, a source logo or default logo can be displayed (e.g., based on the Merchant Category Code (MCC)).

[0031] In some implementations, the financial instrument may be a payment instrument or a card (e.g., a credit card, a digital wallet application containing digital payment information, etc.). In some implementations, the financial instrument may be read by a financial instrument reader, and the second data 182 is transmitted 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 unencrypted form.

[0032] Secure element 124 can receive both first data 180 and second data 182. Secure element 124 can be designed for data security and ensure the security and integrity of transaction data, as described herein. Secure element 124 can host virtual terminal 126. Virtual terminal 126 can generate transaction data from first data 180 and second data 182. Virtual terminal 126 can apply several security and encryption layers, as described herein. Virtual terminal 126 can encrypt the transaction data using a key known only to secure element 124 (referred to as the transaction key). The transaction key can be randomly generated by virtual terminal 126 at the time of the transaction. Secure element 124 can then encrypt the transaction key using a repackaged backend public key. Virtual terminal 126 receives / generates the repackaged backend public key during virtual terminal 126 initialization. The repackaged backend public key corresponds to the repackaged backend private key held by terminal backend 130 and / or repackaged backend 150. In some specific implementations, the repackaged backend public key is used to encrypt additional metadata. Encrypted transaction data (encrypted by the transaction key), an encrypted transaction key (encrypted by re-encapsulating the backend public key), and additional metadata are used to generate an encrypted transaction binary large object (184). In addition to the transaction data, the metadata can also include various security and encryption information, and can also be encrypted. Metadata can also include other data, such as descriptions of the time and place of the transaction, descriptions of encryption, and time.

[0033] After the secure element 124 has generated the encrypted transaction binary large object 184, the encrypted transaction binary large object 184 (sometimes referred to as the encrypted binary large object) can be transmitted to the reader 120. The reader 120 can then add additional metadata and further encrypt it to generate an encrypted reader binary large object 186. The metadata can be used to verify the transaction. In some implementations, the metadata is encrypted by a transport server key, and the encrypted transaction binary large object 184 may not be further encrypted. The transport server key can be generated during the initialization of the reader 120 and corresponds to the transport server key held by the terminal backend 130 and / or the repackaged backend 150. The reader 120 can transmit the encrypted reader binary large object 186 to the source application 112, and the financial instrument reader application UI can be closed, allowing the source application to run (and be displayed on the UI), and the source application now has the encrypted reader binary large object 186. In some examples, the financial instrument reader application UI is closed once the source application 112 receives authorization for the transaction.

[0034] Because the encrypted transaction binary large object 184 is encrypted using a transaction key known only to virtual terminal 126, source application 112 and DTSP 140 may be unable to decrypt the transaction data. This document describes further details of the encryption of the transaction data by virtual terminal 126 of secure element 124.

[0035] Two system backends work with the virtual terminal to encrypt and decrypt transaction data. The system backends can provide security for the data according to security standards such as the PCI CPoC standard (collectively referred to as CPoC verification). The first backend may be referred to as Terminal Backend 130 or Contactless Payment on Customer Off-the-Shelf (COTS) (which may also be referred to as Mobile Payment on COD (MPOC) backend). Terminal Backend 130 may also be referred to herein as the Financial Instrument Reader Backend. In some specific implementations, Terminal Backend 130 is configured to initialize the virtual terminal 126 prior to data transmission (e.g., for financial instruments or other data transfer financial instruments). As part of the initialization, Terminal Backend 126 may verify and / or perform a number of necessary initialization processes. These initialization processes may include verifying the virtual terminal token, generating a session token, transmitting the virtual terminal configuration to the secure element, performing proof checks, etc., as described herein.

[0036] The second backend can be referred to as the repackaging backend 150, the financial instrument data processor backend, or the data delivery repackaging backend. As described herein, the repackaging backend 150 handles the repackaging process, which uses the transport server key to decrypt the encrypted reader binary large object 186 to examine its metadata. Using the metadata, the repackaging backend 150 can verify that the data delivery has been authorized by DTSP 140, the source application 112, and / or the terminal backend 130. In addition to the metadata, the encrypted reader binary large object 186 also includes an encrypted transaction binary large object 184 with an encrypted transaction key (encrypted by the repackaging backend public key) and encrypted transaction data (encrypted by the transaction key). Once the metadata has been verified, the repackaging backend 150 can use the corresponding repackaging backend private key to decrypt the encrypted transaction key (encrypted by the repackaging backend public key). The repackaging backend 150 then uses KEK to reencrypt the transaction key to generate a re-encrypted transaction key. The re-encrypted transaction key and the transaction data encrypted with the transmission key can be referred to as repackaged encrypted transaction data 190, which can be decrypted by DTSP 140. Returning to the reference virtual terminal 126 and associated terminal backend 130, the terminal backend 130 works with the virtual terminal 126 to securely encrypt the transaction data in the secure element 124.

[0037] After receiving the encrypted Reader Binary Large Object 186 from Reader 120, Source Application 112 may transmit the encrypted Reader Binary Large Object 186 along with an authorization request 188 to DTSP 140 to determine whether the transaction is authorized. In some examples, DTSP 140 may be the same entity or controlled by the same entity that created Source Application 112; however, it may be a completely different entity. For example, the source may register an account on Source Application 112, allowing the source to use the source application to facilitate data transfer and other data transfer-related matters without owning it. Source Application 112 may then be operated by the same or different entity as DTSP 140.

[0038] In some implementations, DTSP 140 cannot decrypt the encrypted reader binary large object 186 upon receiving it from source application 112 because the decryption keys (transfer server key and repackaging backend private key) for the encrypted reader binary large object 186 may not be known to DTSP 140. This is part of the security of the encryption used for transaction data. Similarly, source application 112 may not have the key used to decrypt the encrypted reader binary large object 186. These features help ensure the security of the encrypted reader binary large object 186. However, DTSP 140 can transmit the encrypted reader binary large object 186 to the repackaging backend 150 for decryption.

[0039] In some examples, a DTSP can be a payment service provider (“PSP”) (such as a bank (or alternatively, a bank affiliate)) or a corporate entity (such as an acquiring processor or payment facilitator or aggregator that is not licensed or is licensed as a non-bank financial institution (such as a remittance company)). Additionally, transaction information may be sent as follows: (1) from the user via his or her payment device to a secure element in the mobile device of the source (e.g., the merchant); (2) from the secure element to the reader application; (3) from the reader application to the source application via front-end integration; (4) from the source application 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) if the DTSP is not an acquiring institution processor (e.g., a payment facilitator or payment aggregator), from the DTSP to the acquiring institution processor and then to the payment network, or (b) if the DTSP is an acquiring institution processor, from the DTSP directly to the payment network; (8) from the payment network to the issuing bank or issuing institution processor for authorization; and / or (9) the authorization result is directly transmitted back to the source application via the DTSP's system. In some specific implementations, neither the application / device provider nor the back-end platform sees any of the consumer's sensitive payment information.

[0040] The repackaging backend 150 has access to the appropriate keys (transfer server key and repackaging backend private key) to decrypt the encrypted reader binary large object 186. In some implementations, the repackaging backend 150 may use the corresponding private key (the public key used to encrypt the encrypted reader binary large object 186 and the encrypted transaction binary large object 184) to decrypt the encrypted reader binary large object 186 and the encrypted transaction binary large object 184. The repackaging backend 150 may decrypt the encrypted transaction key (encrypted by the repackaging backend public key) and reencrypt the decrypted transaction key using the backend KEK known to the DTSP. The repackaging backend 150 may provide the repackaged encrypted transaction data 190 back to the DTSP. In some implementations, repackaging may mean that the "transaction key" can be depackaged by decrypting the transaction key via the repackaging backend private key (corresponding to the repackaging backend public key used to encrypt the transaction key) and repackaged using the backend KEK. DTSP can decapsulate the transaction key using the DTSP KEK (which corresponds to the backend KEK). DTSP can then use the transaction key to decrypt the transaction data. Once this process is complete, DTSP has the transaction data for data transfer and can utilize a data transfer processor to process the data transfer.

[0041] Once the repackaging backend 150 has decrypted the encrypted reader binary large object 186, some form of verification of the metadata within the encrypted reader binary large object 186 can be performed. If the verification is successful, the repackaging backend 150 can then use the repackaging backend private key to decrypt the encrypted transaction key of the encrypted transaction binary large object 184. The repackaging backend 150 can use the backend KEK (which corresponds to the DTSP KEK) to repackage the transaction key, thereby generating repackaged encrypted transaction data 190 from the encrypted transaction data and the repackaged transaction key. In this way, the DTSP 140, which accesses its specific DTSP KEK (which corresponds to the repackaging KEK), can decrypt the repackaged transaction key of the repackaged encrypted transaction data 190. The repackaged transaction key can then be used to decrypt the encrypted transaction data. The repackaged encrypted transaction data 190 can also be referred to as repackaged transaction data or a repackaged transaction binary large object. The step of re-encrypting transaction data on the re-encapsulation backend 150 so that the transaction data is encrypted for decryption by the DTSP 140 can be referred to as re-encapsulation. The re-encapsulation backend 150 may include a hardware security module (HSM). Some or all of the encryption and decryption performed on the re-encapsulation backend 150 may be performed in the HSM. Further description of the re-encapsulation backend 150 and the procedures performed by the re-encapsulation process is as described herein.

[0042] In some implementations, if verification is successful, the repackaging backend 150 can subsequently use the repackaging backend private key to decrypt the encrypted transaction key of the encrypted transaction binary large object 184. In some implementations, the transaction key can be used to decrypt the encrypted transaction data to verify / authenticate the transaction data. In some implementations, if the transaction data has been verified and / or validated, the repackaging backend 150 can use the backend KEK (which corresponds to the DTSP KEK) to encrypt the transaction key and use the transaction key to re-encrypt the transaction data, thereby generating repackaged encrypted transaction data 190.

[0043] Then, DTSP 140 is able to decrypt the repackaged encrypted transaction data 190 upon receipt. In some implementations, some or all of the decryption of the repackaged encrypted transaction data 190 occurs on a DTSP-controlled HSM (DTSP HSM). DTSP 140 can then process the transaction data. For example, DTSP 140 can determine whether the second data 182 is payment information and whether sufficient funds are associated with the second data 182. DTSP 140 can also transmit the transaction data to another party for processing, such as a data transfer processor 160. Once DTSP 140 (or data transfer processor 160) has processed the transaction data, DTSP 140 is able to transmit an authorization response 182 to the source application 112. The authorization response 192 can indicate whether authorization is granted or denied for the transaction.

[0044] Once completed, a message indicating whether the data transfer was approved can be sent back to the source application. Additionally, other information related to the source's daily business operations (e.g., user authorization and transaction history) can be directly transferred between the DTSP and the source application.

[0045] Figure 2 Example system component 200 is illustrated. System components may include components on device 210 and components on backend 230. Device 210 includes a reader 212 and a secure element 220. The reader 212 is hosted on typical hardware of the device. For example, the reader 212 accesses a typical processor used for most or all applications, also known as an application processor. Similarly, the reader 212 uses the device 210's memory (e.g., random access memory, short-term memory, or volatile memory) and storage devices (e.g., solid-state drives or other long-term storage devices or non-volatile storage devices). Secure element 220 also hosts virtual terminal 222 and PIN applet 224. Backend 230 represents an external device of a server device or multipurpose device. Device 210, reader 212, secure element 220, virtual terminal 222, repackaged backend 240, and terminal backend 250 are respectively equivalent to Figure 1 The device 110, reader 120, secure element 124, virtual terminal 126, repackaged backend 150, and terminal backend 130.

[0046] In some implementations, the reader 212 is implemented in software using some or all of the hardware components of the multipurpose device. The reader 212 can run on the processor of the device 210 along with other applications and processes. For example, the reader 212 can run on the application processor of the device 210. The reader 212 may also include encryption services, as described herein.

[0047] The reader 212 includes a PIN UI 213 and a prompt UI 214. The prompt UI 214 is used to instruct the virtual terminal 222 to prepare to receive second data from the user. For example, the prompt UI 214 can be used to instruct the user to present the second data. In some implementations, the prompt UI 214 can be used to instruct the user to swipe, tap, or insert a card, or use some kind of digital wallet on a mobile device. The prompt UI 214 can be used to instruct the user where to present their second data on the multipurpose device. For example, the prompt UI 214 can instruct the user where to tap their card on the multipurpose device. The PIN UI 213 is used to instruct the reader 212 to prepare to receive a PIN (e.g., numbers, characters, symbols, etc.). For example, the PIN UI 213 can be used to instruct the user to enter a PIN associated with the second data.

[0048] The reader 212 also includes a daemon 216 and a financial instrument reader 218. The daemon 216 can be used to run processes and generate data associated with device 210 that is not processed by the security element 220. The daemon 216 can also be used to process second data obtained by the financial instrument reader 218. Similarly, the daemon 216 can be used to process a PIN. The daemon can receive the PIN digits entered by the user after being prompted by the PIN UI 213. As described herein, the daemon 216 can encrypt each digit of the PIN using a PIN applet public key received from a PIN applet 224. The PIN applet 224 may have a corresponding PIN applet private key. The daemon 216 can store each digit of the PIN in the same memory location such that when the next digit of the PIN is received, that next digit overwrites the last digit of the PIN. For example, when the second digit of the PIN is received, the second digit of the PIN will overwrite the memory location of the first digit of the PIN, such that the first and second digits of the PIN are not simultaneously in memory. The financial instrument reader 218 is used to read and process the second data from the user.

[0049] Device 210 also includes a security element 220. Security element 220 is a component designed for security on a multi-purpose device. In some embodiments, security element 220 is a chip or hardware module separate from the device's processor. For example, security element 220 may operate on a chip separate from the processor running reader 212. In some embodiments, security element 220 is a software module that includes additional software security features for the running process, which reader 212 does not use. In some embodiments, security element 220 is specifically used only by device 210 and only runs processes associated with device 210. In some embodiments, security element 220 runs some processes associated with device 210 and also runs processes for other applications on a multi-purpose device that require additional security features.

[0050] Secure element 220 accommodates virtual terminals 222 and PIN applet 224. Secure element 220 can accommodate multiple virtual terminals 222 corresponding to different pairwise source applications and DTSP. Virtual terminals 222 have a virtual terminal kernel (also referred to as a terminal kernel) configurable by a kernel token. Virtual terminals 222 are designed to encrypt data. For example, virtual terminal 222 encrypts transaction data generated from second data and first data. When encrypting data, virtual terminal 222 can employ many types of keys, hashes, and other cryptographic techniques. Examples of encryption performed by virtual terminal 222 are included herein. PIN applet 224 is an application that receives a PIN number from reader 212. When the PIN request process begins, PIN applet 224 can receive a PIN initiation signal from reader 212. PIN applet 224 can generate a PIN applet public key and a corresponding PIN applet private key. In some examples, the PIN applet public key and corresponding PIN applet private key can be randomly generated for each PIN input. For example, the PIN applet public key and the corresponding PIN applet private key can change for each PIN input on device 210. PIN applet 224 can transmit the PIN applet public key to the daemon 216 of reader 212. Daemon 216 can use the PIN applet public key to encrypt the PIN numbers. PIN applet 224 can use the PIN applet private key to decrypt the PIN numbers. PIN applet 224 can also generate PIN blocks as described herein.

[0051] Backend 230 represents a system component 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 may include repackaged backend 240 and terminal backend 250. Terminal backend may include API gateway 268, kernel manager 260, authorizer 262, authentication subsystem 264, and monitoring subsystem 266.

[0052] Re-encapsulate the encrypted transaction data received from DTSP by backend 240 (e.g., Figure 1 The encrypted reader binary large object 186), for some or all of the encrypted transaction data (e.g., Figure 1 The encrypted reader decrypts the metadata of the binary large object (186) and the encrypted transaction key to verify the transaction data (e.g., Figure 1 The encrypted reader binary large object 186 contains some or all of its metadata, and then uses the KEK associated with the DTSP to re-encrypt some or all of the transaction data (e.g., the transaction key after decryption using the re-encapsulated backend private key). This paper further describes the re-encapsulation backend 240 and the process performed by the re-encapsulation backend 240.

[0053] API gateway 268 facilitates interaction between device 210 and terminal backend 250. For example, API gateway 268 facilitates communication, interaction, and transmission between device 210 and kernel manager 260, authorizer 262, authentication subsystem 264, and monitoring subsystem 266.

[0054] Kernel manager 260 can be used to create and generate kernel tokens. Kernel manager 260 can also be used to generate scripts for configuring virtual terminals 222 in the secure element 220 of device 210.

[0055] Authorizer 262 can be used to authorize DTSPs, sources, and devices to use the Virtual Terminal System. This ensures that only DTSPs, sources, and devices that have already been authorized to use the Virtual Terminal System can use the technologies described herein. Authorization may include the use of tokens, keys, accounts, credentials, etc.

[0056] The authentication subsystem 264 can be used with a virtual terminal system to authorize and verify devices (e.g., mobile devices and servers). The authentication subsystem 264 is part of a security system designed to prevent hacking or misuse of the virtual terminal system to create fraudulent transactions or hijack existing transactions. Hijacking a transaction can include altering any transaction data associated with the transaction so that the transaction data may not accurately match or correspond to the transaction.

[0057] Monitoring subsystem 266 can be used to monitor transactions and devices (e.g., virtual terminal 222 and reader 212) using the virtual terminal system described herein. Monitoring transactions can be critical for compliance with CPOC and other rules involving wired transmissions, transactions, etc., and related devices.

[0058] Figure 3 Example block diagram 300 illustrates an example system and components for implementing the virtual terminal technology described herein. Device 310 (e.g., Figure 1 Device 110) includes source application 312 (e.g., Figure 1 The source application 112), which is compatible with SDK 314 (e.g., Figure 1 The SDK 114) interacts with the reader 320 to transmit the first data 380 to the reader 320 (e.g., Figure 1 (Reader 120). In some examples, the first data 380 is... Figure 1 The first data 182 is the same. In some examples, the first data 380 is different. Figure 1 The first data 182. The first data 380 may include transaction information and / or data transmission information. Virtual terminal 326 (e.g., Figure 1 The virtual terminal 126 is hosted in the secure element 324 (e.g., Figure 1 Within the secure element 324. The secure element 324 receives second data 382, ​​which details how data can be delivered to a source associated with the source application 312. The second data 382 may include financial instrument information. In some examples, the second data 382 is... Figure 1 The second data 182 is the same. In some examples, the second data 382 is different. Figure 1 The second data point is 182.

[0059] Generating a PIN response 390 and a reader PIN binary large object 388 can be referred to as PIN capture. In some examples, device 310 may generate a PIN response 390 and a reader PIN binary large object 388 in response to a PIN request 370 forwarded by DTSP 340 to source application 312 from data transfer processor 360 (DTP). For example, DTSP 340 may, as Figure 1 The diagram illustrates data transfer processing, where the data transfer processor 360 (e.g., an issuer of a financial instrument such as a debit card) requests a PIN. (See reference.) Figure 1When DTSP 140 decrypts the repackaged, encrypted transaction data 190, DTSP 140 may determine that a PIN is required before transmitting the authorization response 192. Alternatively, DTP 160 may receive the transaction data and determine that a PIN is required before DTP 160 can transmit confirmation of the transaction to DTSP 140. Once DTSP 140 receives confirmation of the transaction from DTP 160, DTSP can transmit the authorization response 192. Figure 3 DTSP 340 can forward the PIN request 370 received from data transfer processor 360 to source application 312. Once DTP 360 has received and verified the PIN from DTSP 340, DTP 360 can send a confirmation of the transaction to DTSP 140, and DTSP 140 can send an authorization response 192, as per reference. Figure 1 As shown and described. In some examples, device 310 may generate a PIN response 390 after determining that a financial instrument (e.g., a card) providing second data 382 (e.g., a card number) is associated with a PIN. Thus, the device may generate a PIN response 390 and a reader PIN binary large object 388 without receiving a PIN request 370 from DTP 360 and / or DTSP 340. For example, the financial instrument may transmit information indicating that a PIN is required for data transfer to virtual terminal 326 or reader 320.

[0060] When a PIN capture is initiated as described above, reader 320 can cause device 310 to display PIN user interface 322 (e.g., Figure 2 (PIN UI 213). The user can enter a PIN number 384 at a time. The PIN number 384 can be transmitted to a reader 320. The reader 320 can store and encrypt the PIN number 384, as described herein. The reader 320 can transmit the encrypted PIN number to a PIN applet 328 (e.g., ...). Figure 2 (PIN mini-program 224). Reference Figure 5 The process for capturing individual PIN numbers is described.

[0061] Virtual terminal 326 can transmit second data 382 to PIN applet 328. Secure element 324 (and PIN applet 328) can also communicate with terminal backend 330 (e.g., Figure 1The terminal backend 324 communicates with the terminal backend 330 via the reader 320 for the various security and encryption features described herein, in order to encrypt the PIN block. In some specific implementations, the secure element 324 communicates with the terminal backend 330 via the reader 320, wherein the communication is encrypted. The techniques described herein for encrypting the PIN block allow the PIN stored in the secure element 324 to be stored in a common format (e.g., unencrypted format), so that no proprietary format is used to encrypt the PIN. Once all decryption has been completed, this allows the DTSP 340 and DTP 360 to receive PINs in a common format. The PIN applet 328 can encrypt the PIN using a transaction key known only to the PIN applet 328, the virtual terminal 326, and / or the secure element 324. The transaction key is then encrypted with a repackaged backend public key (which corresponds to a repackaged backend private key held by the terminal backend 330 and / or the repackaged backend 350), as described herein. In some examples, the repackaged backend public key used herein is the same as the referenced one. Figure 1 The same repackaged backend public key. In some examples, the repackaged backend public key used here differs from the reference one. Figure 1 The re-encapsulation of the backend public key. The use of re-encapsulated backend public and private keys enables the use of asymmetric cryptography in the secure element 324, the re-encapsulated backend 350, and the DTSP 340. Compared to symmetric cryptography systems, asymmetric cryptography reduces the risk of key leakage and its use by third parties to decrypt transaction data. Therefore, the PIN applet 328 has a transaction key encrypted with the re-encapsulated backend public key and a PIN block encrypted with at least the transaction key. The PIN applet 328 can generate a PIN binary large object 386 from the encrypted transaction key and PIN block. The PIN binary large object 386 may also include additional metadata as described herein. The use of the PIN binary large object 386 prevents the PIN and related metadata from being exposed outside the secure element 324 before the DTSP 340 and / or DTP 360 can process the PIN and related metadata. (Compared to...) Figure 6 The process was further explained.

[0062] Virtual terminal 326 then transmits a PIN binary large object 386 to reader 320. In some examples, reader 320 may transmit the PIN binary large object 386 to source application 312. In some examples, reader 320 may add additional metadata about the data transfer associated with the PIN binary large object 386. The additional metadata may be encrypted using a transport server key as described herein. The combination of the additional data encrypted with the transport server key and the PIN binary large object 386 may be referred to as reader PIN binary large object 388. In some implementations, the PIN binary large object 386 may also be encrypted using the transport server key. The use of additional metadata in reader PIN binary large object 388 may allow backend 350 to re-encapsulate the encrypted metadata to verify the PIN block without decrypting the PIN block itself. In some implementations, the combination of reader 320, secure element 324, and virtual terminal 326 may be referred to as a virtual terminal system.

[0063] In some examples, when generating the encrypted reader binary large object 186, the PIN binary large object 386 and / or the reader PIN binary large object 388 may be included. Figure 1 The encrypted transaction binary large object 184 (and associated metadata) is included. When device 310 generates a PIN response 390 without a PIN request 370 from DTSP 340 and / or DTP 360, as described above, the PIN binary large object 386 may be included in the encrypted reader binary large object 186.

[0064] Source application 312 may send a reader PIN binary large object 388 and a PIN response 390 to data delivery service provider (DTSP) 340. In some examples, the PIN response 390 is in response to a PIN request 370. In some examples, the PIN response 390 is generated based on a financial instrument that provides second data 382 indicating that a PIN is required for a transaction. Therefore, a PIN response 390 may be generated even if DTSP 340 does not send a PIN request 370. DTSP 340 may be unable to decrypt some or all of the reader PIN binary large object 388 and will send the reader PIN binary large object 388 to repackaging backend 350 for decryption.

[0065] In some examples, the reader PIN binary large object 388 may include encrypted metadata from reader 320. In these examples, repackaging backend 350 can use the transport server key (which corresponds to the transport server key) to decrypt the encrypted metadata of reader PIN binary large object 388 and verify the various parts of the metadata to verify that the PIN block has been authorized by DTSP 340, source application 312, and / or terminal backend 330, as described herein. This allows repackaging backend 350 to verify transactions and / or data transfers corresponding to the PIN block without seeing the underlying unencrypted PIN and transaction data. This ensures the privacy of the underlying PIN and transaction data because source application 312 and repackaging backend 350 never decrypt the PIN encrypted with the transaction key. In some specific implementations, repackaging backend 350 may also decrypt reader PIN binary large object 388 to verify and validate additional metadata and transaction data of PIN binary large object 386.

[0066] The re-encapsulation backend 350 can re-encrypt the transaction key using a KEK (a symmetric key known to the DTSP), allowing the DTSP to decrypt the transaction key (using the KEK) and subsequently the PIN block (using the transaction key). However, the transaction key is currently encrypted using the re-encapsulation backend public key. The re-encapsulation backend 350 can decrypt the transaction key using the re-encapsulation backend private key (which corresponds to the re-encapsulation backend public key). The re-encapsulation backend 350 then re-encrypts the transaction key using a KEK. In some examples, the KEK of the re-encapsulation backend 350 can be referred to as the re-encapsulation KEK, and the KEK of the DTSP 340 can be referred to as the DTSP KEK. In some implementations, the re-encapsulation KEK and the DTSP KEK are functionally equivalent symmetric keys. The re-encrypted transaction key can be referred to as the re-encapsulated transaction key. In some examples, the KEK and the re-encapsulation KEK here can be relative to... Figure 1 The same KEK and repackaged KEK are referenced. In some examples, the KEK and repackaged KEK here may differ from those relative to... Figure 1 Referenced KEK and repackaged KEK.

[0067] The repackaging backend 350 then generates a repackaged PIN binary large object 392, which includes the repackaged transaction key and PIN block. In some implementations, the repackaging backend 350 can generate the repackaged PIN binary large object 392 by encrypting both the transaction key and the PIN block (encrypted by the transaction key) using a KEK (as described herein). In this way, the repackaging backend decrypts various forms of encryption and then re-encrypts the PIN block. The repackaging backend 350 can then transmit the repackaged PIN binary large object 392 to the DTSP 340. The DTSP 340 can use a KEK to decrypt the repackaged transaction key.

[0068] The DTSP 340 may need to send the PIN block and transaction key to the DTP 360 to receive confirmation of the transaction. (Reference) Figure 1 Once DTSP 340 receives confirmation of the transaction from DTP 360, DTSP 140 can transmit an authorization response 192 to authorize the data transfer associated with the PIN. DTSP 340 can also repackage the transaction key using a DTP KEK, a shared KEK between DTP 360 and DTSP 340. This repackaging of the transaction key with the DTP KEK can occur within the DTSP HSM. DTP 360 can also have a DTP HSM for secure cryptography and data transfer. DTSP 340 can transmit the transaction key (encrypted with DTPKEK) and the PIN block to DTP 360. DTP 360 can decrypt the transaction key using the DTP KEK and decrypt the PIN block using the transaction key. DTP 360 can verify the PIN and transmit confirmation of the transaction to DTSP 340. (Reference) Figure 1 The DTSP 140 can transmit an authorization response 192 to authorize the data transfer associated with the PIN.

[0069] Figure 4 Sequence diagram 400 illustrates an example high-level sequence for implementing the virtual terminal technology described herein. The example sequence includes generating a PIN binary large object (e.g., on a virtual terminal 426, a reader 420, and a PIN applet 428). Figure 3 The PIN binary large object 386). This example sequence can also be referred to as PIN capture. Virtual terminal 426, reader 420 and PIN applet 428 correspond to respectively Figure 3 The virtual terminal 426, reader 320, and PIN app 428. As described herein, the virtual terminal 426 and PIN app 428 are composed of a secure element (e.g., Figure 3 Security Element 324) managed.

[0070] Before the start of example sequence diagram 400, DTSP (e.g., Figure 3 The DTSP 340 can be directed to source applications (e.g., Figure 3 The source application 312) transmits data originating from DTP (e.g., Figure 3 PIN request for DTP 360 (e.g., Figure 3 PIN request 370). In some examples, such as regarding Figure 1 The described data transfer process has initiated data transfer, and as per the above... Figure 3 The description requires a PIN. A PIN requirement can result in the sequence of example sequence diagram 400. In some examples, a financial instrument used for data transfer (e.g., a credit or debit card) can indicate to virtual terminal 426 that a PIN is required to complete the data transfer. A financial instrument indicating that a PIN is required can result in the sequence of example sequence diagram 400. For example, virtual terminal 426 can transmit an indication to reader 420 that a PIN needs to be captured.

[0071] At box 402, virtual terminal 426 can transmit financial instrument data to PIN applet 428. Financial instrument data relates to the financial instrument used for data transfer / transaction. Financial instrument data can include various information, including the primary account number (“PAN”). In some examples, the PAN is a card number, such as a credit card number or debit card number. In some examples, virtual terminal 426 may also include a transaction identifier (“transactionID”). For example, in cases such as… Figure 1 During the described data transfer process, the data transfer can be associated with a transactionID. This same transactionID can be used to bind the data transfer to a PIN request.

[0072] At box 404, reader 420 may initiate PIN capture. Reader 420 may send a PIN capture initiation signal to PIN applet 428, instructing the PIN applet to initialize and perform internal checks before receiving the PIN number. In some examples, reader 420 may initiate PIN capture after a PIN request from the DTSP to the source application, and the source application forwards the PIN request to reader 420, as per [reference needed]. Figure 3 As described. In some examples, virtual terminal 426 may transmit to reader 420 an indication that the financial instrument used for data transfer has indicated that a PIN is required to complete the data transfer. The indication from virtual terminal 426 may cause reader 420 to initiate PIN capture. When a PIN capture initiation signal is transmitted to PIN applet 428, reader 420 may transmit the transactionID associated with the PIN capture.

[0073] At box 406, PIN applet 428 may perform internal checks. These internal checks may include preparing the processor, memory, and storage device associated with the secure element hosting PIN applet 428 to receive the PIN number. In some examples, the internal checks may include verifying that PIN applet 428 has received financial instrument data (e.g., PAN) associated with the transaction ID received from reader 420. In some examples, if PIN applet 428 has not received the financial instrument data associated with the transaction ID, PIN applet 428 may request the financial instrument data associated with the transaction ID from virtual terminal 428 to prepare for receiving the PIN number. In some examples, the internal checks may also include initialization steps, such as generating a PIN applet public key and a PIN applet private key. In some examples, PIN applet 428 may also transmit authentication information about PIN applet 428 to reader 420. In some examples, PIN applet 428 may request authentication information from reader 420 before transmitting the PIN public key to reader 420. Both the PIN app 428 and the reader 420 can use the proof between the PIN app 428 and the reader 420 to verify that the other party is valid and authenticated.

[0074] At box 408, reader 420 can request PIN applet public key 408 from PIN applet 428. In some examples, PIN applet 428 can generate a new PIN applet public key and PIN applet private key pair for each PIN capture. In some examples, PIN applet 428 can generate a new PIN applet public key and PIN applet private key pair in response to a request from reader 420. Using a new PIN applet public key and PIN applet private key pair for each PIN capture (also referred to as a random PIN applet public key and PIN applet private key pair) can enhance the security of PIN captures using the device's secure element. In some examples, PIN applet 428 can generate a new PIN applet public key and PIN applet private key pair during internal check 406. The PIN applet public key and PIN applet private key can be specifically used to receive the PIN number from reader 420. Any encryption scheme can be used. For example, Elliptic Curve Integration Encryption (ECIES) can be used.

[0075] At box 410, PIN applet 428 can transmit the PIN public key to reader 420. If PIN applet 428 has already performed its internal check at box 406 and has financial instrument data associated with the transactionID, then PIN applet 428 can transmit the PIN public key and / or an instruction regarding authorized PIN capture to reader 420. When reader 420 receives the PIN public key and / or the instruction regarding authorized PIN capture, reader 420 can display the PIN UI on the device for PIN capture. If PIN applet 428 has already performed its internal check at box 406 and has found that PIN applet 428 has not had financial instrument data for the transactionID for a period of time, then PIN applet 428 can transmit a PIN rejection message. Reader 420 can receive the PIN rejection message and may not display the PIN UI on the device. This mechanism can be used to ensure that users do not enter their PIN into the device without a properly associated transactionID and appropriate financial instrument information to verify that an actual transaction is taking place. This protects users from unnecessarily revealing their PIN.

[0076] At box 412, reader 420 can transmit the PIN number to PIN app 428. (See also: Regarding...) Figure 5 In further detail, each digit of the PIN can be encrypted and transmitted independently to the PIN app 428. Each PIN digit can be transmitted along with the transaction ID. (See also: [link to related information]) Figure 3 As described, when reader 420 receives a first PIN number (e.g., via PIN UI), reader 420 may store the first PIN number in a first memory location of the device. The first PIN number may be encrypted using a PIN public key. The first PIN number may then be transmitted to PIN applet 428. The encryption and transmission of the first PIN number both occur before the second PIN number is received. When reader 420 receives the second PIN number, reader 420 may store the second PIN number in the first memory location of the device, overwriting the first PIN number, such that the first and second PIN numbers do not coexist in insecure memory (e.g., the device's memory, but not the secure element's memory). The second PIN number may be encrypted using a PIN public key and transmitted to PIN applet 428. The above sequence is repeated for each PIN number. In some examples, a PIN may be four digits. In some examples, a PIN may be any length of any combination of numbers, letters, symbols, etc.

[0077] When PIN app 428 receives the encrypted PIN number from reader 420, PIN app 428 can decrypt the encrypted PIN number using the PIN app private key corresponding to the PIN app public key. Therefore, the PIN will be completely decrypted within PIN app 428 of the secure element. As described herein, the PIN is secure within the secure element due to the specific hardware and software implementation of the secure element.

[0078] At box 414, reader 420 can request a PIN binary large object from PIN applet 428. This request may include the transaction ID. The request for the PIN binary large object allows PIN applet 428 to generate the PIN binary large object (e.g., ...). Figure 3 The PIN binary large object (386). The PIN binary large object includes the PIN block, the encrypted transaction key, and additional metadata. The PIN applet (428) can generate data such as... Figure 6 The PIN block is described. The PIN block can be encrypted using a transaction key. The transaction key can be encrypted using a re-encapsulated backend public key to generate an encrypted transaction key. Additional metadata may include the transaction ID, version information about the PIN applet, and version and operating system information about the secure element. In some examples, reader 420 may send an indication to PIN applet 428 that all PIN numbers have been received prior to a request for the PIN block. In some examples, when PIN applet 428 receives an indication from reader 420, PIN applet 428 may begin generating a PIN binary large object. At box 416, PIN applet 428 may transmit the PIN binary large object to reader 420.

[0079] Figure 5 Sequence diagram 500 illustrates an example high-level sequence for implementing the virtual terminal technology described herein. The example sequence includes entering a PIN number at a PIN user interface 522 and transmitting the PIN number to a PIN applet 528. The virtual terminal 426, reader 420, and PIN applet 428 correspond to... Figure 3 The virtual terminal 326, reader 320, and PIN app 328. The PIN user interface 522, reader 520, and PIN app 528 respectively correspond to... Figure 3 The PIN user interface 322, reader 320, and PIN app 328. As described herein, the PIN app 528 may be controlled by a secure element (e.g., Figure 3 The security element 324 is managed. Example sequences may be included. Figure 4In box 412. The example sequence can be repeated for each digit of the PIN. The example sequence can be referred to as a PIN digit capture or a single PIN digit capture.

[0080] At box 502, the user can enter a PIN number on the PIN user interface 522. The PIN user interface 522 transmits the PIN number to the reader 520. In some examples, the PIN user interface can be a physical button or a software interface on a touchscreen. The reader 520 stores the PIN number in a first memory location on the device. The memory location for the PIN number is considered insecure because the device's memory may not have the security features of a secure element. When each PIN number is received by the reader 520, the reader 520 overwrites the previous PIN number by placing the latest PIN number in the same first memory location. In this way, multiple PIN numbers are prevented from being stored in insecure memory simultaneously.

[0081] At box 504, reader 520 can encrypt the PIN number. Reader 520 can encrypt the PIN number at least based on the PIN applet public key received from PIN applet 528, as per [reference needed]. Figure 4 As described. At box 506, reader 520 can transmit the encrypted PIN number to PIN applet 528. The encryption of the PIN number and the transmission of the PIN number to PIN applet 528 can be performed faster than the user can enter the next PIN number.

[0082] At box 508, the PIN mini-program 528 can decrypt the PIN number. The PIN mini-program 528 can decrypt the PIN number at least based on using the PIN mini-program private key corresponding to the PIN mini-program public key, as per [reference to...]. Figure 4 As described. At box 510, PIN applet 528 can store ordinary, unencrypted PIN numbers in the memory of the secure element. Due to the specific hardware and software components of the secure element, the memory of the secure element can be considered secure. Therefore, multiple PIN numbers and / or the entire PIN can be stored in the PIN applet 528 in an ordinary, unencrypted state. The entire PIN can be referred to as a PIN block.

[0083] exist Figure 6 The diagram shows the method for generating PIN block 664 (e.g., Figure 3 Example Figure 600 shows a PIN binary large object (386 PIN block). Security elements (e.g., Figure 3 The PIN app for the Security Element 324 (e.g., Figure 3 The PIN app (328) can generate PIN block 664. Generating PIN block 664 can be done in response to a request for a large PIN binary object (e.g., ...). Figure 4 (Box 414) or in response to an indication that the PIN applet has received the final PIN number.

[0084] The PIN applet begins with an unencrypted PIN 602. PIN 602 includes each PIN number and is stored in memory associated with the secure element. The PIN applet can verify that each PIN number is associated with the same transactionID. Additionally, PIN 602 can be a plain value for the PIN and may not require a proprietary format.

[0085] In some examples, the PIN applet can generate an intermediate PIN block A 604. The intermediate PIN block A 604 can be generated at least based on encrypting PIN 602 using a symmetric key 606. As described herein, the symmetric key 606 can be randomly generated and can be known only to the PIN applet, the virtual terminal, and / or the secure element. In some examples, the symmetric key 606 can be as described in the reference... Figure 3 The described transaction key. As described herein, symmetric key 606 can be encrypted with an asymmetric public key (e.g., re-encapsulating the backend public key), such that symmetric key 606 can be used by an entity (such as...) having an asymmetric private key (e.g., re-encapsulating the backend private key). Figure 3 The repackaged backend (350) is then decrypted.

[0086] The PIN applet can generate intermediate PIN block B 608. Intermediate PIN block B 608 can be generated at least by performing an operation on intermediate PIN block A 604 using PAN 610. For example, the PIN applet can perform an XOR Boolean operation (commonly referred to as an XOR operation) on the bits of intermediate PIN block A 604 and PAN 610 to generate intermediate PIN block B 608. In some examples, intermediate PIN block B 608 can be generated by performing an operation on PIN block 602 using PAN 610. For example, the PIN applet can perform an XOR Boolean operation (commonly referred to as an XOR operation) on the bits of PIN block 602 and PAN 610 to generate intermediate PIN block B 608. Services attempting to decrypt the PIN from PIN block 602 or intermediate PIN block A 604 will require PAN 610 by performing an XOR operation on PIN block 602 or intermediate PIN block A 604. Reference Figure 3Any combination of DTSP 340, DTP 360, and repackaged backend 350 has PAN 610, and PAN 610 can be used to decrypt PIN block 664 or intermediate PIN block A 604 to determine PIN 602. For example, if intermediate PIN block B 608 is generated by performing an XOR Boolean operation on the bits of PIN block 602 and PAN 610, then performing another XOR Boolean operation using PAN 610 should decrypt intermediate PIN block B 608 to obtain intermediate PIN block A 604.

[0087] The PIN app can generate PIN block 664. PIN block 664 can be generated by encrypting the intermediate PIN block B 608 with the symmetric key 606. In some examples, the symmetric key 606 can be as shown in the reference. Figure 3 The described transaction key. In some examples, the symmetric key 606 is encrypted with an asymmetric public key (e.g., a repackaged backend public key).

[0088] Figure 7 A flowchart illustrating an example process 700 for use with the techniques described herein is shown according to at least one example. Process 700 is illustrated as a logic flowchart, where each operation represents a series of operations that can be implemented in hardware, computer instructions, or combinations thereof. In the context of computer instructions, an operation represents computer-executable instructions stored on one or more computer-readable storage media that, when executed by one or more processors, perform the described operation. Generally, computer-executable instructions include routines, programs, objects, components, data structures, etc., that perform a particular function or implement a particular data type. The order in which the operations are described is not intended to be construed as limiting, and any number of the described operations may be combined in any order and / or in parallel to implement the described process.

[0089] At box 702, process 700 may include a user device (e.g., Figure 3 The reader application of device 310) (e.g., Figure 3 The reader 320 receives a personal identification number (PIN) request associated with the encrypted data transmission. The encrypted data transmission may be transmitted by a first server (e.g., Figure 3 DTSP 340 authorization. Second server (e.g., Figure 3 The repackaged backend (350) can decrypt the PIN block.

[0090] At box 704, process 700 may include receiving a first digit from a plurality of digits of a PIN by the reader application. At box 706, process 700 may include overwriting a memory location by the reader application by storing the first digit in a memory location of a previously stored digit from the plurality of digits. At box 708, process 700 may include generating a first encrypted digit by the reader application by encrypting the first digit with a public key.

[0091] At box 710, process 700 may include sending a first encrypted number to a secure element (e.g., a reader application) of the user device. Figure 3 (Secure Element 324). The secure element may be part of the user equipment. The secure element may be a separate hardware module configured for security and cryptography. The secure element may be decoupled from the reader application and associated application processor on the user equipment. The secure element may host a virtual terminal configured to generate encrypted data payloads including financial instrument information and data transfer information.

[0092] At box 712, process 700 may include decrypting multiple digits of the PIN using a private key by a secure element. The private key may be associated with a public key.

[0093] At box 714, process 700 may include generating a PIN binary large object by a secure element based at least in part on multiple digits of the PIN. Generating the PIN binary large object may include the secure element receiving financial instrument information related to an encrypted data transfer. Generating the PIN binary large object may include the secure element generating a random symmetric key. Generating the PIN binary large object may include the secure element generating a first intermediate PIN block based at least in part on multiple digits of the PIN, the financial instrument information, and the random symmetric key. Generating the PIN binary large object may include the secure element encrypting the random symmetric key using an asymmetric public key. Generating the PIN binary large object may include the secure element generating the PIN binary large object based at least in part on the first intermediate PIN block and the random symmetric key.

[0094] Process 700 may further include a reader application sending a public key request for a public key to a secure element. Process 700 may also include the secure element sending the public key to the reader application. Process 700 may further include the reader application receiving the public key from the secure element. Process 700 may further include the secure element determining, based on a transaction identifier associated with the encrypted data transmission, that the secure element has financial instrument information associated with a PIN. The secure element may send the public key to the reader application based on the determination that the secure element has financial instrument information associated with a PIN.

[0095] The foregoing describes exemplary methods, systems, and computer-readable media for enabling virtual terminals to receive touchless data transfers on mobile devices. Some or all of these systems and methods may, but do not necessarily, be at least partially constituted by, for example, at least Figures 1 to 8 The architectures shown are used to implement this. While numerous examples have been described above in relation to personal and / or payment-related information, it should be understood that these techniques can be used to manage any type of user information or non-user information (e.g., any type of data). Furthermore, various non-limiting examples have been described in the foregoing description. For illustrative purposes, many specific configurations and details have been elaborated to provide a thorough understanding of the examples. However, it will also be apparent to those skilled in the art that some examples can be implemented without these specific details. Additionally, well-known features have sometimes been omitted or simplified to prevent confusion with the examples described herein.

[0096] Figure 8 This is a block diagram of an example electronic device 800. Device 800 typically includes a computer-readable medium 802, a processing system 804, an input / output (I / O) subsystem 806, wireless circuitry 808, and audio circuitry 810 including a speaker 812 and a microphone 814. These components can be coupled via one or more communication buses or signal lines 803. Device 800 can be any portable electronic device, including handheld computers, tablet computers, mobile phones, laptop computers, tablet devices, media players, personal digital assistants (PDAs), keychains, car keys, access cards, multifunction devices, mobile phones, portable gaming devices, headsets, etc., including combinations of two or more of these items.

[0097] Obviously, Figure 8 The architecture shown is only an example of the architecture of device 800, and device 800 may have more or fewer components or different configurations of components than shown. Figure 8 The various components shown can be implemented by hardware, software, or a combination of both, including one or more signal processing circuits and / or application-specific integrated circuits.

[0098] Wireless circuit 808 is used to transmit and receive information over a wireless link or network to conventional circuitry of one or more other devices, such as antenna systems, radio frequency (RF) transceivers, one or more amplifiers, tuners, one or more oscillators, digital signal processors, codec chipsets, memory, etc. Wireless circuit 808 can use various protocols, such as those described herein. In various implementations, the wireless circuit 808 is capable of establishing and maintaining communication with other devices using one or more communication 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), LTE, Advanced Long Term Evolution (LTE), Wi-Fi (such as 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 (NFC), protocols for email, instant messaging and / or short message service (SMS), or any other suitable communication protocol, including communication protocols not yet developed as of the date of submission of this document.

[0099] Wireless circuit 808 is coupled to processing system 804 via peripheral device interface 816. Peripheral device interface 816 may include conventional components for establishing and maintaining communication between peripheral devices and processing system 804. Voice and data information received via wireless circuit 808 (e.g., in voice recognition or voice command applications) is transmitted via peripheral device interface 816 to one or more processors 818. One or more processors 818 can be configured to process various data formats of one or more applications 834 stored on medium 802.

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

[0101] Processor 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, receiving user input, and outputting control information to the user. Processor 818 may be manifested as one or more hardware processors, microprocessors, microcontrollers, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), etc. As noted above, Figure 3 The security element 324 is separated from the processor 818 envisioned here.

[0102] Device 800 also includes a power system 842 for supplying power to various hardware components. Power system 842 may include a power management system, one or more power sources (e.g., batteries, alternating current (AC)), a recharging system, power fault detection circuitry, a power converter or inverter, a power status indicator (e.g., light-emitting diodes (LEDs)), and any other components typically associated with the generation, management, and distribution of power in mobile devices.

[0103] In some embodiments, device 800 includes a camera 844. In some embodiments, device 800 includes a sensor 846. The sensor may include an accelerometer, compass, gyroscope, pressure sensor, audio sensor, light sensor, barometer, etc. Sensor 846 may be used to sense positional aspects, such as auditory or optical markers of location.

[0104] In some implementations, device 800 may include a GPS receiver, sometimes referred to as GPS unit 848. Mobile devices may use satellite navigation systems such as the Global Positioning System (GPS) to obtain positioning 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 estimate transmission time and distance. The GPS unit may determine the current location (current position) of the mobile device. Based on these estimates, the mobile device may determine its orientation, altitude, and / or current speed. The orientation may be geographic coordinates, such as latitude and longitude information.

[0105] One or more processors 818 run various software components stored in medium 802 to perform various functions of device 800. In some embodiments, these software components include operating system 822, communication module 824 (or instruction set), location module 826 (or instruction set), and other applications 834 (or instruction set).

[0106] The operating system 822 can be any suitable operating system, including iOS, Mac OS, Darwin, real-time operating system (RTXC), LINUX, UNIX, OS X, WINDOWS, or embedded operating systems (such as VxWorks). The operating system may include various programs, 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.

[0107] The communication module 824 facilitates communication with other devices via one or more external ports 836 or via wireless circuit 808, and includes various software components for processing data received from wireless circuit 808 and / or external ports 836. External port 836 (e.g., Universal Serial Bus (USB), FireWire, Lightning connector, 60-pin connector, etc.) is adapted to be coupled directly or indirectly to other devices via a network (e.g., Internet, Wireless Local Area Network (LAN), etc.).

[0108] Location / motion module 826 helps determine the current location (e.g., coordinates or other geographic location identifiers) and movement of device 800. Modern positioning systems include satellite-based positioning systems such as the Global Positioning System (GPS), cellular network positioning based on “cell IDs,” and Wi-Fi positioning technology based on Wi-Fi networks. GPS also relies on the visibility of multiple satellites to determine location estimates, which may be invisible (or have weak signals) indoors or in “urban canyons.” In some embodiments, location / motion module 826 receives data from GPS unit 848 and analyzes the signals to determine the current location of the mobile device. In some embodiments, location / motion module 826 may use Wi-Fi or cellular location technology to determine the current location. For example, the location of the mobile device may be estimated using knowledge of nearby cell sites and / or Wi-Fi access points and their locations. Information identifying a Wi-Fi or cellular transmitter is received at wireless circuit 808 and transmitted to location / motion module 826. In some embodiments, the location module receives one or more transmitter IDs. In some implementations, a sequence of transmitter IDs can be compared with a reference database (e.g., a cell ID database, a Wi-Fi reference database) that maps or associates transmitter IDs with the location coordinates of the corresponding transmitter, and the estimated location coordinates of device 800 can be calculated based on the location coordinates of the corresponding transmitter. Regardless of the specific positioning technology used, the location / motion module 826 receives information from which location orientation can be derived, interprets the information, and returns location information, such as geographic coordinates, latitude / longitude, or other location orientation data.

[0109] One or more applications 834 on device 800 may include any application installed on device 800, including but not limited to browsers, address books, contact lists, email, instant messaging, social networks, word processing, keyboard emulation, widgets, Java-enabled applications, encryption, digital rights management, speech recognition, speech copying, and music players (playing back recorded music stored in one or more files such as MP3 or AAC files). Figure 3 Reader 320 Figure 3 PIN user interface 322 Figure 3 The source application 312, etc. As mentioned above, it can be used... Figure 3 Different applications are installed in the safety element 324. For example, Figure 3 The PIN mini-program 328 can be installed on Figure 3 Application in Safety Element 324. Figure 3 These applications in Security Element 324 are installed by the device manufacturer and may not be able to be added and / or removed by the end user.

[0110] Other modules or instruction sets (not shown) may exist, such as graphics modules, time modules, etc. For example, a graphics module may include various conventional software components for rendering, animate, and displaying graphical objects (including but not limited to text, web pages, icons, digital images, animations, etc.) on the display surface. In another example, a timer module may be a software timer. Timer modules may also be implemented in hardware. A time module may maintain various timers for any number of events.

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

[0112] In some embodiments, the I / O subsystem 806 may include a display and user input devices such as a keyboard, mouse, and / or touchpad. In some embodiments, the I / O subsystem 806 may include a touch-sensitive display. The touch-sensitive display may also accept input from a user based at least in part on tactile and / or haptic contact. In some embodiments, the touch-sensitive display forms a touch-sensitive surface for accepting user input. The touch-sensitive display / surface (along with any associated modules and / or instruction set in the 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, such as one or more soft keys 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 may use any suitable object or accessory, such as a stylus, pen, or finger, to contact the touch-sensitive display. The touch-sensitive display surface may use any suitable touch-sensitive technology to detect contact and any movement or release of it, including capacitive technology, resistive technology, infrared technology, and surface acoustic wave technology, as well as other proximity sensor arrays or other elements for determining one or more points of contact with the touch-sensitive display.

[0113] In addition, the I / O subsystem 806 may be coupled to one or more other physical control devices (not shown), such as buttons, keys, switches, joysticks, dial pads, slide switches, joysticks, LEDs, etc., for controlling or performing various functions, such as power control, speaker volume control, ringtone loudness, keyboard input, scrolling, holding, menus, screen locking, clearing, and ending communication. In some embodiments, in addition to the touchscreen, the device 800 may also include a touchpad (not shown) for activating or deactivating specific functions. In some embodiments, the touchpad is a touch-sensitive area of ​​the device that, unlike the touchscreen, does not display visual output. The touchpad may be a separate touch-sensitive surface from the touch-sensitive display, or an extension of the touch-sensitive surface formed by the touch-sensitive display.

[0114] In some implementations, an application running on a user's device may be used to perform some or all of the operations described herein. Circuits, logic modules, processors, and / or other components may be configured to perform the various operations described herein. Those skilled in the art will understand that, depending on the specific implementation, such configuration can be accomplished through the design, setup, interconnection, and / or programming of particular components, and again, depending on the specific implementation, the configured components may be reconfigurable or not reconfigurable for different operations. For example, a programmable processor can be configured by providing appropriate executable code; a dedicated logic circuit can be configured by appropriately connecting logic gates and other circuit elements; and so on.

[0115] Any software component or function described in this patent application can be implemented as software code that needs to be executed by a processor using any suitable computer language such as Java, C++, or Perl, using, for example, conventional or object-oriented techniques. The software code can be stored as a series of instructions or commands on a computer-readable medium for storage and / or transmission. Suitable media include random access memory (RAM), read-only memory (ROM), magnetic media such as hard disk drives or floppy disks, or optical media such as optical discs (CDs) or DVDs (Digital Universal Optical Discs), flash memory, etc. The computer-readable medium can be any combination of such storage or transmission devices.

[0116] Such programs can also be encoded and transmitted using carrier signals adapted for transmission over wired, optical, and / or wireless networks (including the Internet) conforming to various protocols. Similarly, computer-readable media according to embodiments of this disclosure can be created using data signals encoded by such programs. Computer-readable media encoded with program code can be packaged with compatible devices or provided independently of other devices (e.g., downloaded via the Internet). Any such computer-readable media can be present or located within a single computer program product (e.g., a hard disk drive or an entire computer system) and can be present or located within different computer program products within a system or network. A computer system may include a monitor, printer, or other suitable display for providing any results mentioned herein to a user.

[0117] Computer programs incorporating various features of this disclosure can be encoded on a variety of computer-readable storage media; suitable media include magnetic disks or magnetic tapes, optical storage media such as optical discs (CDs) or DVDs (Digital Multipurpose Discs), flash memory, etc. Computer-readable storage media encoding program code can be packaged with compatible devices or provided separately from other devices. Furthermore, program code can be encoded and transmitted via wired, optical, and / or wireless networks (including the Internet) conforming to various protocols, thereby allowing distribution, for example, via download over the Internet. Any such computer-readable medium can reside or be located within a single computer product (e.g., a solid-state drive, hard disk drive, CD, or an entire computer system) and can exist or be located within different computer products within a system or network. A computer system may include a monitor, printer, or other suitable display for providing any results mentioned herein to a user.

[0118] Accordingly, the specification and drawings should be regarded as illustrative rather than restrictive. However, it will be apparent that various modifications and changes may be made thereto without departing from the broader spirit and scope of this disclosure as set forth in the claims.

[0119] Other variations are within the scope of this disclosure. Therefore, although the disclosed technology is susceptible to various modifications and alternative constructions, certain illustrative examples are shown in the accompanying drawings and have been described in detail above. However, it should be understood that this disclosure is not intended to be limited to the specific forms disclosed, but rather is intended to cover all modifications, alternative constructions, and equivalents falling within the scope and spirit of this disclosure as defined by the appended claims.

[0120] In the context of describing the disclosed examples (particularly in the context of the claims below), the terms “a,” “an,” and “the,” as well as similar indicator words, shall be construed as covering both singular and plural forms, unless otherwise stated or clearly contradicted by the context. Unless otherwise stated, the terms “comprising,” “having,” “including,” and “containing” shall be construed as open-ended terms (e.g., meaning “including but not limited to”). The term “connected” is construed as including, attaching, or joining together, even if there is interference. Unless otherwise stated herein, the description of numerical ranges herein is intended merely as a simple way of individually referring to each individual value falling within that range, and each individual value is incorporated into the specification as if individually referenced herein. All methods described herein can be performed in any suitable order unless otherwise stated or clearly contradicted by the context. Unless otherwise stated, the use of any and all examples or exemplary language (e.g., “such as”) provided herein is intended merely to better illustrate examples of this disclosure and does not limit the scope of this disclosure. No language in the specification should be construed as indicating that any unstated element is essential to the practice of this disclosure.

[0121] Unless otherwise specifically stated, parse languages ​​such as the phrase “at least one of X, Y, or Z” are understood in context to be generally used to represent items, terms, etc., which can be X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z). Therefore, such parse languages ​​are generally not intended and should not imply that some examples require that at least one of X, at least one of Y, or at least one of Z each exist.

[0122] This document describes preferred examples of the present disclosure, including the best modes known to the inventors for carrying out the present disclosure. Variations of those preferred examples will become apparent to those skilled in the art after reading the foregoing description. The inventors expect those skilled in the art to appropriately employ such variations, and the inventors intend to practice the present disclosure in ways different from those specifically described herein. Therefore, as permitted by applicable law, this disclosure includes all modifications and equivalents to the subject matter recited in the appended claims. Furthermore, unless otherwise indicated herein or clearly contradicted by the context, this disclosure encompasses any combination of all possible variations of the foregoing elements.

[0123] All references cited in this article, including publications, patent applications and patents, are incorporated herein by reference, as each reference is individually and specifically indicated to be incorporated by reference and elaborated in the entire text.

[0124] As described above, one aspect of the present invention is sharing personal and / or payment-related data between user devices, which may include storing some aspect of the data on a server. This disclosure contemplates that, in some cases, this collected data may include personally identifiable information (PII) data that uniquely identifies or can be used to contact or locate a specific person. Such personal information data may include demographic data, location-based data, telephone 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 information or personal or health information.

[0125] This disclosure recognizes that the use of such personal information data in the techniques of this invention can be beneficial to users. For example, personal information data can be used to process data transfers or payments in transactions with sources. Furthermore, this disclosure also anticipates other uses of personal information data that benefit users.

[0126] This disclosure anticipates that entities responsible for the collection, analysis, disclosure, transmission, storage, or other use of such personal information data will comply with sound privacy policies and / or privacy practices. Specifically, such entities should implement and adhere to privacy policies and practices recognized as meeting or exceeding industry or governmental requirements for maintaining the privacy and security of personal information data. These policies should be readily accessible to users and should be updated as data collection and / or use change. Personal information from users should be collected for legitimate and reasonable entity purposes and should not be shared or sold outside of these legitimate purposes. Furthermore, such collection / sharing should be conducted only after receiving informed consent from users. Additionally, such entities should consider taking any necessary steps to protect and safeguard the right to access such personal information data and ensure that other entities with access to personal information data comply with their privacy policies and procedures. Moreover, such entities may be subject to third-party assessments to demonstrate their compliance with widely accepted privacy policies and practices. Furthermore, policies and practices should be appropriate for the specific types of personal information data collected and / or accessed, and should be consistent with applicable laws and standards, including considerations of specific jurisdictions. For example, in the United States, the collection or acquisition of certain health data may be governed by federal and / or state laws, such as the Health Insurance Portability and Accountability Act (HIPAA); while in other countries, health data may be subject to other regulations and policies and should be handled accordingly. Therefore, different privacy practices should be maintained for different types of personal data in each country.

[0127] Regardless of the foregoing, this disclosure also anticipates implementation schemes for users to selectively block the use or access to personal information data. That is, this disclosure anticipates providing hardware and / or software components to prevent or block access to such personal information data. For example, in relation to advertising delivery services or other services related to health record management, the inventive technology can be configured to allow users to opt-in or opt-out at any time during or after service registration. In addition to providing opt-in and opt-out options, this disclosure also anticipates providing notifications related to access to or use of personal information. For example, users may be notified when downloading an application that their personal information data will be accessed, and then reminded again just before the application accesses the personal information data.

[0128] Furthermore, the intent of this disclosure is that personal information data should be managed and processed in a manner that minimizes the risk of unintentional or unauthorized access or use. Once data is no longer needed, this risk can be minimized by restricting data collection and deleting data. Additionally, and where applicable, including in certain health-related applications, data deidentification can be used to protect user privacy. Deidentification can be facilitated, where appropriate, by removing specific identifiers (e.g., date of birth), controlling the amount or specificity of stored data (e.g., collecting location data at the city level rather than the address level), controlling how data is stored (e.g., aggregating data among users), and / or other methods.

[0129] Therefore, while this disclosure broadly covers the use of personal information data to implement one or more of the various disclosed embodiments, it is also contemplated that various embodiments can be implemented without access to such personal information data. That is, various embodiments of the present invention will not become inoperable due to the absence of all or part of such personal information data.

Claims

1. A method, the method comprising: The user device's reader application receives a personal identification number (PIN) request associated with the encrypted data transmission; The reader application receives the first digit of a plurality of digits from the PIN; The reader application overwrites the memory location by storing the first number in the memory location of a previously stored number among the plurality of numbers; The reader application generates a first encrypted number by encrypting the first number with a public key; The reader application sends the first encrypted number to the secure element of the user equipment; The security element uses a private key to decrypt the plurality of digits of the PIN, wherein the private key is associated with the public key; as well as The security element generates a PIN binary large object based at least in part on the plurality of numbers of the PIN.

2. The method of claim 1, wherein the security element is a hardware module configured for security and cryptography, and wherein the security element is separate from the reader application and associated application processor on the user device.

3. The method according to claim 1 or 2, further comprising: The reader application sends a public key request for the public key to the security element; as well as The public key is sent to the reader application by the security element.

4. The method according to claim 3, further comprising: The security element determines that it has financial instrument information associated with the PIN based on a transaction identifier associated with the encrypted data transmission; and The secure element sends the public key to the reader application based on determining that the secure element has the financial instrument information associated with the PIN.

5. The method according to any one of claims 1 to 4, wherein generating the PIN binary large object comprises: The secure element receives financial instrument information related to the encrypted data transmission; A random symmetric key is generated by the security element; as well as The first intermediate PIN block is generated by the security element based at least in part on the plurality of numbers of the PIN, the financial instrument information, and the random symmetric key.

6. The method of claim 5, wherein generating the PIN binary large object further comprises: The random symmetric key is encrypted by the secure element using an asymmetric public key; as well as The PIN binary large object is generated by the security element based at least in part on the first intermediate PIN block and the random symmetric key.

7. The method of claim 5, wherein the secure element hosts a virtual terminal, the virtual terminal being configured to generate the encrypted data transfer including the financial instrument information and data transfer information.

8. The method according to any one of claims 1 to 7, wherein the encrypted data transmission is authorized by a first server, and wherein a second server decrypts the PIN binary large object.

9. The method according to any one of claims 1 to 8, wherein the security element is part of the user equipment, wherein the security element is a hardware module configured for security and cryptography, and wherein the security element is separate from the reader application and associated application processor on the user equipment.

10. The method according to any one of claims 1 to 9, further comprising: The reader application sends a public key request for the public key to the security element; as well as The reader application receives the public key from the secure element.

11. The method of claim 10, wherein the secure element is configured to determine that the secure element has financial instrument information associated with the PIN based on a transaction identifier associated with the encrypted data transmission; and The secure element is further configured to send the public key to the reader application based on determining that the secure element has financial instrument information associated with the PIN.

12. A user equipment, the user equipment comprising: One or more memory units; and One or more processors, the one or more processors communicating with the one or more memories and configured to execute instructions stored in the one or more memories to perform the method according to any one of claims 1 to 11.

13. A non-transitory computer-readable storage medium storing program instructions that, when executed by one or more processors of a user equipment, cause the user equipment to perform the method according to any one of claims 1 to 11.

Images