Improved computer-implemented systems and methods for secure electronic transmissions

Abstract

The present disclosure provides a solution to emulate a secure device, such as a payment terminal or a device / resource access controller on a user device. In a preferred embodiment, the user device is a commercial off-the-shelf device, such as a mobile phone, tablet or laptop, etc. Once a triggering event is detected, a software component provided on the user's device acquires configuration data that enables the emulation of the secure device within the secure part of the user device. The emulation is intended to acquire relevant data for the intended transaction between the user and the terminal owner (e.g. merchant), as well as data from the user, such as but not limited to authentication data (e.g. PIN code), payment card data, etc. The data acquired by the user device can be sent to the acquirer of the merchant to enable the transaction to proceed.

Description

Technical Field

[0001] This disclosure relates to improvements in the secure transmission or exchange of data across electronic networks. In particular, the embodiments disclosed herein provide solutions for processing sensitive data on electronic devices. Advantageously, these devices may include consumer off-the-shelf devices such as mobile phones, laptops, and tablets, which typically lack the full security mechanisms required to store and / or process highly sensitive data.

[0002] Additionally or alternatively, embodiments of this disclosure can be described as providing technical solutions for performing operations and / or communications across electronic networks between two or more parties. Such operations and communications may require the transmission, exchange, storage, and / or processing of sensitive data to perform the operations.

[0003] Additionally or alternatively, embodiments of this disclosure can be described as providing technical solutions for securing, granting, and / or denying access to at least one controlled resource. Such solutions may include systems and methods for authenticating the identity of at least one entity wishing to gain access to the controlled resource. Background Technology

[0004] In many situations, such as in the payments industry and other application areas, there is a need to exchange sensitive data between a sender and a receiver. In some instances, the sender and receiver may belong to the same organization, but in others they may not. As a result, a lack of trust may exist between the parties involved. Furthermore, given the prevalence of mobile or portable technologies in today's world, performing such transmissions often requires the use of commercial end-user devices. However, mobile / portable devices such as smartphones are considered insufficiently secure for transmitting highly sensitive data such as encryption keys and passwords. Sensitive data can be used, for example, to control access to controlled resources such as bank accounts, computing networks, buildings or vehicles, patient medical or personal records in databases or other storage facilities, military data, etc.

[0005] While this disclosure is not limited to this application area, in the context of financial transactions, such technical challenges are addressed using "fixed-purpose" devices (such as softpos, POS terminals, or other types of payment terminals) provided to merchants by vendors. The vendor sets up (i.e., configures) the device for a specific merchant, enabling that merchant to securely execute transactions. This includes providing encryption keys and other merchant-specific configuration data on the device. The configuration of the merchant device does not change thereafter. Furthermore, such payment devices are typically hardware-specific, as a device provided by one vendor will not be able to work with systems from other vendors. As a result, the merchant device only allows the user (consumer) to transact with the acquirer to which the merchant has signed an agreement. However, it is evident that challenges arise when the merchant and user are not in the same location, or when the user wishes to use the same COTS device to securely transact with multiple different merchants who are not all associated with the same acquirer.

[0006] Therefore, numerous technical challenges arise, such as: how to establish identities to ensure the secure communication, storage, and processing of sensitive data on insecure end-user devices; how to improve the versatility of such user devices in a wider range of transaction environments; and how to ensure that data exchange is performed across different electronic networks in a manner that allows only authorized parties to access the sensitive data and other controlled resources. The embodiments disclosed herein provide systems and methods for addressing at least the aforementioned challenges. Summary of the Invention

[0007] The preferred embodiments of this disclosure provide solutions that enable or facilitate the configuration of electronic devices to temporarily operate in order to use, simulate, replicate, or extend the state of another (remote) electronic device.

[0008] The electronic device can also be configured to securely communicate with one or more remote computing resources to facilitate the sharing or transfer of potentially sensitive data between them. Preferably, the configuration of the electronic device is performed dynamically. In a preferred example, this may mean that the configuration is performed on the electronic device as needed when the communication or data sharing is required to perform a specific, predefined (transfer) operation. The installation of the configuration on the electronic device can be triggered, requested, or initiated by an event performed by the operator / user of the electronic device. Therefore, in some embodiments, the configuration of the electronic device persists only for the period required to perform the predefined operation and is thereafter removed from the electronic device.

[0009] Preferably, one or more of the following may be applied: The electronic device includes hardware, firmware, and / or software that enables it to perform processing functions; in some examples, it may include commercially available off-the-shelf (COTS) devices; in some examples, it may include mobile, handheld, or portable devices, such as (mobile) phones, laptops, tablets, etc., although this disclosure is not limited in this respect. Hereinafter, for convenience only, the user's electronic device may be referred to as a mobile phone; the phone may be operated by a first entity, which we may refer to as a user, end user, first user, customer, first operator, consumer, cardholder, etc. In some examples, the electronic device includes a touchscreen, camera, speaker, microphone, biometric reader, smart card reader, facial recognition functionality, wireless communication capabilities (such as Bluetooth, NFC), and telecommunications and internet connectivity. In some embodiments, the installation / uninstallation of the configuration of the user's electronic device may be controlled, executed, or influenced by a software component or application installed on the electronic device. For ease of reference, this software component / application may be referred to hereinafter as a "Software Development Kit (SDK)"; in other embodiments, the installation / uninstallation of the configuration may be performed on demand. For example, it can be triggered by action, signal detection, or electronic communication / transmission events, such as the action of scanning a QR code, receiving electronically transmitted messages (such as emails, text messages, or communications via instant messaging applications), or receiving certain other signals / communications at or by a user's electronic device. Another resource may include processing and communication capabilities, enabling it to initiate, facilitate, and / or complete predefined operations. This other resource may be remote relative to the electronic device. The term "remote" should not be interpreted as implying geographical distance or relative physical proximity, but rather as meaning that it is distinct from and separate from the electronic device.

[0010] In some examples, the other device may include a terminal, a point-of-sale (PoS) or ePOS device / system, an online business resource, or other apparatus that operates to initiate and / or execute financial transactions; in such examples, for convenience, the other resource may be referred to herein as a “merchant device.” The other resource may be operated by a second entity, which we may refer to as an intermediary / second / other user or operator, merchant, etc.

[0011] In some examples, the other device may be a virtual device rather than a physical device, such as an e-commerce or payment gateway. In other cases, the other device may be a physical device, such as a payment terminal provided to a specific merchant by an acquiring bank or payment solutions provider and configured for that specific merchant to use when conducting secure transactions with customers.

[0012] In some implementations, the configuration of the other device can be static, meaning that once the other device is configured, the initial configuration will not change. In some examples, the configuration may include at least one configuration file and / or key associated with the other device.

[0013] This operation may include, for example, financial transactions, calculations, user authentication prior to granting access to one or more controlled resources, secure communications, etc. For convenience, this operation may be referred to hereinafter as a "transaction," but this is intended to be interpreted in a general sense, and this disclosure is not limited to financial transactions. The phrase "authentications session" may be used interchangeably with "transaction" or "operation." In a preferred embodiment, a transaction may include an access authorization process for a controlled resource. Such a process may include verifying the user's identity and / or authorization prior to granting access to the controlled resource. For example, controlled resources may include vehicles, equipment, buildings, electronic accounts, file storage resources, websites, etc. An operation may be performed in association with a transaction entity, such as a financial organization or institution (e.g., an acquiring bank), or a locking / unlocking device configured to grant or deny access to a building or vehicle, etc. The transaction entity (hereinafter referred to as the "acquiring party" for convenience) may own, control, operate, or otherwise associate with a remote resource.

[0014] In summary, the embodiments provided in this disclosure can dynamically and on-demand create temporary copies of a statically configured second entity's other device on the electronic device of a first entity to enable or facilitate transfers between the other device and the electronic device. In some examples, this embodiment includes: creating a copy by generating a new, unused instance of the other device on the electronic device, and then configuring the instance (on a per-transfer / on-demand basis) by providing one or more configuration files and / or keys to the instance, thereby cloning the state of the other device on the electronic device. In one or more embodiments, the steps may include: using a software component (SDK) provided / installed on a user's electronic device (e.g., a telephone) to temporarily extend, project, copy, clone, or simulate the state of another device (e.g., a merchant terminal) on the user's electronic device (e.g., a telephone). Thus, the SDK can be configured to: configure the telephone (or a portion thereof, such as a virtual machine, enclave, TEE, HSM, or other secure portion of the user device) to simulate the other device. In other embodiments, this dynamic, temporary, and on-demand configuration can be executed in response to a trigger, such as when the telephone's processor receives a signal or one or more instructions.

[0015] The status of another resource may include one or more encryption keys. Additionally or alternatively, it may include one or more portions of configuration data (which may be referred to as a configuration file for convenience). The encryption keys and / or configuration files may be provided to the other resource from a third entity or resource that owns or controls the controlled resource. This third entity may be, for example, an acquiring bank, a payment integrator, or a payment solutions provider. Additionally or alternatively, the encryption keys and / or configuration files may uniquely identify the other resource to the third entity.

[0016] A telephone can use at least a portion of the state of another device (such as an encryption key) to identify itself to a third entity and / or communicate with the third entity as if it were another resource. For example, a telephone can use a simulated state to present itself to an acquiring bank as if it were a specific merchant, thereby conducting a specific financial transaction. In another example, a telephone can simulate the security configuration of an electric vehicle to enable a driver to authorize software downloads or enable a user to authorize security updates on a laptop, etc.

[0017] After the operation is complete, the software component can unload the configuration from the user device, restoring it to its previous state. In other words, the user device's configuration can be restored to its state before another device was installed.

[0018] These and other aspects of the invention will become apparent and will be illustrated by reference to the illustrative embodiments disclosed herein. The illustrative embodiments of this disclosure will now be described by way of example only and with reference to the accompanying drawings. Attached Figure Description

[0019] Figure 1 A flowchart illustrating the use of an example implementation of this disclosure is provided.

[0020] Figure 2 An overview of the resources, equipment, and participants involved in the use of an example implementation of this disclosure is provided.

[0021] Figure 3 Descriptions of possible computing environments that can be used to implement one or more embodiments of this disclosure are provided.

[0022] Detailed description of illustrative embodiments

[0023] We now provide some example implementations, which are intended to illustrate rather than limit.

[0024] As described above, the embodiments of this disclosure provide an improved solution that enables users to conduct electronic exchanges with other parties securely, even when the user is using a Commercial Off-the-shelf (CoTS) device such as a mobile phone. In the example scenario where a user wishes to transact with a merchant, the traditional approach is for the merchant to provide the user with a secure POS terminal on which the user can tap or insert their payment card. However, it is obvious that this is not possible when the user is not in the merchant's store.

[0025] Advantageously, embodiments of this disclosure address such challenges by providing a "blank terminal" on the user device, which can be configured almost instantaneously as a clone of the merchant device, allowing the transaction to be executed on the user device as if the user were physically present at the merchant device's location. Preferably, this means that one embodiment of this disclosure is configured to: remotely copy the merchant device to the user device almost in real time during a single transaction, and then remove / destroy the copy of the merchant device on the user device. This not only ensures transaction security but also allows the user to transact with different merchants using the same device, simply by copying a different merchant device onto the device each time.

[0026] Therefore, in a preferred example, one implementation provides, simulates, extends, or projects the assets of a (specific) merchant system (another device) onto a user's (consumer's) electronic device.

[0027] Traditionally, the assets of a merchant payment system comprise one or more payment devices (also referred to as “terminals”) located in a store or other facility where a transaction is to take place; these payment terminals typically include hardware, firmware, and / or software. Each payment terminal includes the acquirer’s (encryption) key and configuration. A terminal management system (TMS) is typically used to configure new payment devices, update configurations, update keys, and remove payment terminals from a merchant’s payment system. However, in the case of MPOS, the mobile device plus the payment application constitutes the terminal. Recently, this has been achieved by using a hardware dongle inserted into the merchant’s device. Advantageously, the embodiments disclosed herein eliminate the need for a hardware dongle for the merchant, instead enabling the use of NFC readers and other features commonly available in current mobile devices.

[0028] The embodiments disclosed herein enable users to install a simulated or virtual copy of secure terminal software on their COTS devices. In some examples, this is achieved by using software installation (referred to as an SDK) provided on the user device. This verifies and ensures that the operating environment on the user device meets the same security requirements as a merchant's traditional payment device. Therefore, the embodiments create a copy of the merchant device on the user device. This copy can be identical to the merchant device, or so similar that another device configured to interact with the merchant device cannot distinguish between the two. In other words, the copy provides another device with the functionality and data that the merchant device is expected to have. This is achieved by temporarily providing encryption keys and other necessary configuration data to the user device, thereby extending the merchant's terminal assets and configuration to the user / cardholder's device. Therefore, to complete a transaction, the user device appears to the issuing bank as the merchant's original (traditional) payment terminal.

[0029] Essentially, the implementation of this disclosure provides the following capabilities: Providing end users with a software application or its components (which we may refer to as an SDK) that runs to replicate one or more configuration elements (such as security data or settings) of another device on a user's device; in other words, the implementation can provide a user's device with the security and other functions of another device through the software application or its components; in yet another way, the implementation can provide a virtual device on a user's device that (at least partially) emulates another device; This may include temporarily providing secure data, such as one or more keys and / or one or more parameters, to a virtual device generated on a user device, wherein the keys and / or parameters match keys and / or parameters provided or associated with another device; this ensures that the technical environment created on the user device meets the same security requirements required and provided by the other device.

[0030] Therefore, in existing technology, each merchant terminal includes its own public / private key pair, which can be used to identify and verify the transactions it executes. Since merchants always use the same acquirer, this key pair remains unchanged. Thus, traditional terminals never change and always contain the same keys and configuration provided by the TMS during setup.

[0031] However, according to this disclosure, the acquiring party on the user's device can be changed whenever a user chooses to transact with a different merchant. Therefore, the configuration of the virtual terminal on the user's device (including configuration files for keys, identifiers, and other parameters) changes for each new merchant. This can be achieved in two ways: 1) Through standalone applications: In this approach, the SDK does not contain any specific acquirer or merchant state (configuration files or keys); therefore, they need to be injected into a new virtual terminal created for each required transaction; this can be done through any suitable mechanism, such as by scanning a QR code or clicking a link (explained in more detail below), and by transferring the standalone application (including the SDK) to the user's device and creating a new virtual terminal on it; 2) Through the embedded SDK: In this approach, a specific merchant provides an application with an embedded SDK; since the merchant consistently uses the same acquirer for each transaction, the virtual terminal does not need to change its configuration data for each transaction. In such cases, the configuration data can be encrypted and stored on the phone, ready to be decrypted and used when a transaction is to be executed, or transmitted to the phone for each transaction.

[0032] Regardless of the method used, the implementation of this disclosure creates a virtual terminal on the user's phone at the start of each transaction, provides the merchant's configuration data (such as configuration files, encryption keys, etc.) to the virtual terminal, executes the transaction between the issuer and the acquirer, and deletes the virtual terminal from the user's device after the transmission is complete.

[0033] Users execute transactions on their devices as if those devices were physical payment terminals for merchants. This can include one or more user authentication sessions that the user must successfully complete in order to conduct the transaction. For example, user authentication may include providing a secret identifier (such as a PIN code, password, memorable phrase, answers to pre-set security questions, etc.), biometric authentication, and / or presenting a security token or device, or one or more of these. User authentication may include presenting a smart card, such as a payment card, to a virtual terminal on the user's device. This can be achieved by reading data, such as encryption keys, from the chip in the smart card or other device. Card data can be obtained from the card by the user device wirelessly (e.g., using Bluetooth, NFC communication, etc.) or by inserting or bringing the card close to a reader device located within or coupled to the user device.

[0034] 1. Example #1 – Financial Transactions

[0035] If individuals could securely purchase goods and services using their mobile devices, it would be advantageous, at least for the reasons mentioned in this article. However, mobile phones and other such consumer devices are known to be inherently insecure, and therefore, traditionally, such payments have required secure terminals provided by the merchant's acquiring institution (such as a bank) or payment solutions provider (PSP). Secure terminals include the necessary "state" to ensure compliance with industry standards, thereby ensuring the security of sensitive data associated with the terminal. This includes at least one private encryption key, which the terminal provider (acquiring institution or payment solutions provider) injects into a given merchant's secure terminal, and which the terminal provides to the acquiring party when a payment is made, allowing the merchant terminal to verify its identity and prove that the transaction originated from a legitimate source.

[0036] To simulate a merchant's device on a user's mobile device, configuration needs to be performed on the mobile device. This configuration process involves two phases: 1) Invitation Phase: In this phase, merchants first request the generation of an invitation to unlock their assets for expansion. This request is sent to the merchant's terminal provider, such as their acquiring bank or PSP; in response, the terminal provider provides the merchant with an invitation code or other triggering mechanism that can be used to accept the invitation. 2) Acceptance stage: At this stage, if the cardholder (end user / customer) decides to make a payment via their mobile device, they need to accept the merchant's invitation to project the merchant's payment terminal onto their mobile device. In other words, cloning of the merchant's terminal only occurs with the end user's permission.

[0037] Special Reference Figure 1 and Figure 2 An overview of a non-limiting illustrative embodiment can be described as follows.

[0038] exist Figure 1 In step 1, the user (Alice, 201) wishes to purchase at least one good or service from the sales resources 203 provided by the merchant (Bob, 202). Figure 2 In one example, the sales resource is an online store such as a website, but in other examples, the store could be a physical store or some other sales venue, such as a mobile app, an in-game purchase facility, or some other type of virtual sales resource from which users (Alice, 201) can obtain services or goods.

[0039] exist Figure 1 In step 2, in order to transact the selected purchase item, Alice uses her electronic devices (e.g., Figure 2The remote payment process is initiated (“triggered”) on a mobile phone or tablet computer (206, or computer 207). The triggering mechanism may include various technical arrangements, such as, but not limited to: a QR code for capture and analysis by a camera on device 206 / 207; or a clickable hyperlink; or a voice recognition component configured to detect, analyze, and act upon the user’s audio input. The trigger may include any appropriately configured technical means.

[0040] Alice's device includes a software application ("SDK") that is capable of building a newly generated virtual terminal on Alice's device for that specific transaction. At this point in the process, the newly generated terminal does not yet contain the necessary elements or features required to complete the transaction because it is not yet bound to or associated with the merchant (Bob, 202).

[0041] exist Figure 1 In step 3, this binding is achieved by sending configuration data from acquiring resource 205 to devices 206 and 207. The configuration data may include at least a setup file (also known as a configuration file) for the transaction session and an encryption key. Once the configuration data is received at Alice's device, it is used by the SDK to configure the newly generated virtual terminal. Therefore, the combination of the configuration data on Alice's device and the blank terminal provides a functional and secure terminal that simulates a secure physical payment terminal, just as if Alice were in Bob's store. At this point in the process, the virtual terminal is subject to card payment industry standards.

[0042] exist Figure 1 In step 4, relevant transaction data is displayed on Alice's phone, such as the merchant's name, identifier, transaction amount, and payment instructions. In the example implementation, the transaction data is obtained from information contained in the QR code, resources referenced by links, etc.

[0043] exist Figure 1 In step 5, Alice 201 makes the required payment by entering the details of her payment card 208 into the virtual terminal. This can be achieved using any suitable technology. For example, this could include: placing her payment card 208 against the device for detection by a contactless card reader; or retrieving a payment card token stored in the device's wallet (e.g., for Apple). TM(Pay); or by swiping the magnetic stripe via a reader associated with Alice's devices 206, 207. (It should be noted that in other use cases unrelated to payment and financial solutions, the authentication device may not be the payment card 208. Instead, the authentication device presented by the user may include a smart card or certain other devices, including one or more of the following: security tokens, digital certificates, encryption keys, SIM cards, signal transmitters, RFID devices, etc. For example, this could include a vehicle's remote key, a building's access card, etc. The authentication device may include hardware and executable instructions configured to be executed by that hardware, or the authentication device may include a virtual device, i.e., it may only include machine-executable instructions.)

[0044] exist Figure 1 In step 6, the virtual terminal on the Alice device reads the details of payment card 208 obtained in step 5.

[0045] exist Figure 1 In step 7, for additional security, another user authentication process is performed; in the example implementation of Figure 7, a PIN input pad is displayed on Alice's device, which is known in the fields of payment solutions and other security systems used for user authentication. The term "PIN input pad" is used interchangeably herein with "keypad" and "keyboard." A PIN input pad may include symbols or markings associated with individual keys. Symbols may include numbers, letters, grammar symbols and punctuation marks, currency symbols, function symbols, etc. It should be noted that user authentication may include any suitable authentication mechanism, such as using one or more of the following: password, PIN or other secret identifier checks, biometric checks, facial / voice recognition, memorable phrases, etc. For ease of illustration, Alice uses PIN input authentication in this example.

[0046] exist Figure 1 In step 8, Alice enters her authentication identifier (PIN) into the PIN input pad. The authentication identifier is a secret associated with Alice and can take any suitable form. In some examples, the identifier can be a sequence of numbers (such as a PIN) or a combination of symbols such as a password. This identifier can be provided via a touchscreen associated with Alice's device, or via some other selection and input device, such as a mouse or other clicking device, or a keyboard, joystick, etc. In other examples, the secret authentication identifier may include an audio signal captured by a microphone associated with Alice's device. In any case, Alice enters her secret identifier into the terminal through a properly configured hardware / software interface.

[0047] exist Figure 1In step 9, the virtual terminal determines whether Alice is authorized to use her presented payment card 208 (i.e., the authentication device) to conduct the transaction. This includes verifying with the card provider 204 whether the secret identifier received from Alice matches the stored version of the identifier. The virtual terminal may encrypt the received identifier and transmit it to the card provider 204 for comparison with Alice's stored secret. It should be noted that... Figure 2 In this context, the issuing bank 204 is shown as the card provider described above, but this may not be the case in each implementation, and the authentication device 208 may be provided by any authorized party required for any implementation.

[0048] exist Figure 1 In step 10, if Alice's input does not match the stored secret known to card provider 204 and associated with Alice's payment card, the transaction fails. Alice can be notified of the failure by receiving a "reject" or "access denied" message.

[0049] exist Figure 1 Step 11 describes another scenario where the input matches the stored secret associated with payment card 208, and the transaction is completed. This could include sending funds from issuing bank 204 to Bob's acquiring bank 205, or unlocking resources such as physical objects, buildings, or vehicles, or granting access to electronic resources such as accounts, etc.

[0050] The virtual terminal was then removed from Alice's device; this step was not performed during... Figure 2 As shown in the diagram. In other words, the virtual terminal is put into use on demand when a specific authentication session is initiated, and is deactivated when it ends with success (step 11) or failure (step 10).

[0051] Special Reference Figure 1 and Figure 2 We now provide more details about the use of the illustrative embodiments.

[0052] 1.1 Scenario 1 – Online Shopping

[0053] Consider a non-restrictive example where a consumer / user (Alice 201) owns an electronic device (mobile phone) and wants to use it to make a purchase transaction in a merchant's (Bob's) online store 203. In other words, when Alice wants to make a purchase, she will have to make a "card not present" transaction.

[0054] Alice 201 holds payment card 208 issued by a third entity, Carole 204. Bob 202 has an account with David. David is an acquiring institution 205, such as a bank or payment solutions provider, which Bob has chosen to make payments through its website. David created an SDK (which we may also refer to as a “terminal application,” “software component,” or “payment application”), which Bob made available to Alice through his website, allowing her to download the SDK to her phones 206 and 207, as described in more detail below. The SDK operates to facilitate or perform methods conforming to any of the implementations disclosed herein.

[0055] After Alice completes her shopping at Bob's online store 203, she selects the "Proceed to Checkout" option to pay for the items in her shopping cart. In a traditional in-store scenario, Alice would walk to the checkout counter where Bob's point-of-sale payment terminal (i.e., another electronic device) is located and present her payment card. She would either tap the card against the terminal for a contactless transaction or insert the card into the terminal and enter her PIN. However, in our online store scenario, Alice cannot physically use Bob's payment terminal. When Alice selects the "Pay Now" option on Bob's website, she chooses to download and install the SDK to execute the transaction directly via her phone. By installing and running the application, Alice consents to allow David 205 (via the SDK) to interact remotely and temporarily with Alice's mobile device, just as if the phone 206 were Bob's traditional payment terminal. According to this disclosure, the security and functionality of Bob's physical merchant device are cloned onto Alice's device according to the implementation of this disclosure.

[0056] The download and installation of the SDK on Alice's phone can be initiated in different ways, as described above. In one example, Alice might be shopping online through Bob's website using her laptop. As she proceeds to checkout and make payment, she executes a triggering event that causes David's SDK to download, install, configure, and execute on her phone. The triggering event could be, for example, entering her phone number in an input box on the store checkout screen; or scanning a QR code displayed on Bob's store checkout screen using her phone's camera; or receiving push notifications or other signals / communications from Bob's device, as described above. The QR code could include instructions to initiate the download and installation of the SDK on the phone. The SDK could be downloaded from a remote location controlled by David. In such cases, the device Alice uses to initiate the transaction is not the same as the device she uses for authentication and payment; that is, she is using her laptop to make selections in an online store, but the payment transaction is generated and executed on her mobile phone.

[0057] In another example scenario, Alice might be shopping at Bob's online store on her phone and might simply click on a link provided on the checkout page instead of scanning a QR code from a separate device. In such cases, the purchase selection process (shopping) and the transaction process are performed on the same device.

[0058] Regardless of the type of trigger event used to initiate the SDK installation (via QR code, link click, or menu option selection, etc.), the result is the download and installation of the software application onto Alice's phone. In other scenarios, Alice may have already downloaded and installed Bob's application, which includes the SDK; therefore, the SDK is already installed and ready to execute.

[0059] During execution, the SDK provides a blank merchant terminal on the phone. In addition to being referred to as a "blank terminal," alternative terms such as "initial terminal," "virtual terminal," or "stateless terminal" may be used, and these terms are used interchangeably in this document.

[0060] The blank terminal generated on Alice's phone is "blank" because while it may include at least some of the functionality of a traditional payment terminal, it lacks the configuration or functionality required for a specific instance of a payment terminal. In other words, it includes the shell of a payment terminal but has not yet been set up or initialized as a terminal belonging to any particular merchant. Therefore, at this point in the process, the blank terminal has been generated on Alice's phone but has not yet been associated with Bob.

[0061] The transaction-related data (via visual and / or audio means) is presented on Alice's phone for her to review. If the data (such as the price) does not match her expectations, or if she has simply changed her mind, she can abort the transaction. However, if she agrees to continue, she can authorize payment to complete the transaction, i.e., the transfer of funds. In some cases, if the transaction amount is small enough, she may choose to make a contactless payment by simply tapping her payment card against the phone. The phone's built-in NFC reader reads data from the chip in Alice's payment card, performs the usual transaction steps, and completes the transaction. These traditional transaction steps may include: contacting the card issuer using the card, user, and payment details (Carole, 204); requesting payment; waiting for authorization from the card issuer (Carole); and presenting a confirmation of payment success (or failure) to the user (Alice) on the phone screen.

[0062] It is necessary to ensure that Alice's PIN code and other sensitive data (such as payment card details) are not accessed without authorization by malicious actors. For example, such data needs to be protected if the phone is threatened (e.g., by a virus or malware on the phone). Therefore, in a preferred embodiment, the SDK is installed, stored, and / or executed within the phone's secure enclave or hardened portion. This can be or includes one or more of a Secure Element (SE), Trusted Execution Environment (TEE), Trusted Platform Module (TPM), Hardware Security Module (HSM), Software Protection Extension (SGX), and Trusted User Interface (TUI).

[0063] To prevent security vulnerabilities such as "man-in-the-middle" attacks (in which an unauthorized third party intercepts the installation of the virtual terminal SDK on Alice's phone), an authentication platform is also installed as part of the SDK. This ensures that the SDK is installed in a secure environment and provides continuous checks to ensure that the phone or installation process has not been compromised.

[0064] In other implementations, security can be further enhanced and the risk of fraud or theft reduced by utilizing the phone's built-in camera and biometric devices. In some implementations, two-factor (2F) authentication can be used by capturing a facial image of the person conducting the transaction and holding the phone. Facial recognition can be used to check if the face of the person holding the phone matches a stored photograph of a legitimate user. Additionally or alternatively, a photograph of the person holding the phone can be captured and stored for future reference, to be used as evidence in the event of inquiries or claims related to the legitimacy of the transaction.

[0065] 1.2 Scenario 2 – In-store Shopping

[0066] In our next example scenario, Alice enters Bob's physical store to make a purchase. Before leaving the store, she uses her phone's camera to capture a QR code displayed at the checkout or elsewhere in the store. In other examples, a link or code could be provided for Alice to enter into her phone instead of capturing a QR code. The process then continues. As in scenario 1, a triggering event causes an SDK to be installed on Alice's phone, generating a blank terminal, which is then configured to simulate the security and functionality of Bob's physical payment terminal. A user interface is provided as described earlier, which retrieves a PIN code and any instructions, and makes payment after successful user verification via PIN code and / or other authentication methods such as biometrics, facial recognition, etc.

[0067] Consider this scenario: Alice is shopping for groceries at a supermarket with self-checkout facilities. When Alice reaches the self-checkout machine, she scans the items in her shopping cart using the machine's scanner, selects "Complete & Pay" on the touchscreen, and then chooses the "Pay on My Phone" option. As shown in Scenario 1 above, she scans the QR code, and the terminal SDK is subsequently downloaded to Alice's phone. The QR code scanning action establishes or generates an association between Alice's phone and the checkout machine. The terminal configuration and payment process are performed as described above.

[0068] In an alternative scenario, Alice might choose to use a "scanning while shopping" approach instead of scanning everything at the self-checkout machine at the end. In this method, Alice picks up a handheld scanner upon entering the store, scans each item as she moves through the store, and downloads the data from the scanner to the self-checkout machine afterward. Similarly, if she selects the "pay on my phone" option, she will trigger an event that causes the SDK to install, and the process will proceed as described above.

[0069] 1.3 Scenario 3 – Shopping via merchant application (in-store or mobile)

[0070] In the scenario described above, we illustrated an example where Alice triggers an event to download and install David's SDK on her phone. However, Alice doesn't necessarily have to reinstall the SDK every time she selects the "Pay on my phone" payment option.

[0071] For example, if David is Alice's bank or the PSP she agrees to use, the SDK can be downloaded and installed on her phone and not removed or uninstalled after each payment. In a way, this is similar to Alice always having a newly manufactured blank terminal residing on her phone. The SDK is not limited to working with only one merchant. Instead, it provides a universal authentication tool that Alice can use to make bank card payments at virtual or physical points of sale for different merchants. When Alice selects to checkout, the terminal connects to David's platform and downloads all the data files and keys for that specific merchant. At the end of the transaction, the SDK erases the data files, restoring it to a blank and stateless state.

[0072] However, in other examples, a particular merchant might choose to embed David's SDK into their own mobile or online applications. For instance, suppose Alice frequently shops online at Bob's store and wants to enjoy the convenience of having Bob's desktop or mobile shopping app installed on her device. When Alice uses Bob's online store as described in Scenario 1 and triggers an event to install the SDK, she can establish a connection between her phone and that particular retailer (Bob), so that when she shops at his store again, the payment transaction is automatically and directly sent to her phone. In this way, the user can set the SDK as the "default" payment method for a given merchant. However, this is an optional feature.

[0073] Alternatively, if Alice is shopping through Bob's app on her mobile phone, and David's SDK is embedded in Bob's shopping app to enable payment on the shopper's phone, Alice does not need to download and install David's SDK separately, as it will be automatically downloaded and installed as part of Bob's app download and installation process.

[0074] In other examples, the SDK is not embedded in merchant applications, but rather in banking applications, payment applications, or authentication applications used to control access to vehicles, buildings, or other controlled physical / digital resources.

[0075] Therefore, there are multiple possibilities for its use: 1) Remove SDK after a single transaction After the user triggers the event, the SDK can be downloaded and installed, and then uninstalled (automatically or upon the user's request / instruction) after payment is completed. Payment can be terminated either after successful payment or due to reasons such as insufficient funds in the user's account or too many failed authentication attempts.

[0076] 2) Persistent SDK residency

[0077] As mentioned above, this SDK can be downloaded and installed on a user's phone as a universal payment method for use with different merchants; or it can be a built-in payment component of a third-party application. In such cases, the SDK can remain on Alice's phone until she removes David's standalone SDK from the device, or deletes Bob's application that includes the SDK.

[0078] Preferably, the implementation scheme of the system disclosed herein has passed the certification of relevant payment industry standards, such as PCICPoC, SPoC, MPoC, etc. In a preferred embodiment, the system may include one, some, or all of the following components: Mobile point-of-sale applications (mobile apps); Authentication and monitoring system; Backend transaction processing system; The authentication and kernel configurations have been specifically optimized to manage the risks associated with cardholder transactions.

[0079] It is conceivable that the implementation plan for this system will be provided by various parties, such as acquirers, payment service providers, and payment integrators.

[0080] 2. Using Example #2 – Access Control

[0081] In the first use case example, we described how embodiments of this disclosure can be used to provide an on-demand authentication platform for payment-related transactions and transfers. However, the embodiments can also be advantageously applied to other scenarios and uses, and are not limited to applications related to payment transactions. In fact, any party issuing smart cards or other processing devices with NFC and PIN capabilities can deploy these embodiments. For example, consider a scenario where a data owner stores sensitive data on their computing resources. In this case, the data owner may be the “issuer” of the access card. When an operator or other user wishes to access the data, they must verify their identity by using the card that has been issued to them. Using embodiments of this disclosure, a user can do this by tapping their card against a reader and / or entering the PIN code associated with it. In some cases, the reader may be the user’s mobile phone or tablet, which then uses the data entered from the card to perform the verification process. If the verification is successful, the user will be granted permission to access certain files or resources; for example, they may be able to access files through their laptop / tablet.

[0082] In other examples, drivers can download an app from the car manufacturer to their phone, which includes the SDK described above. When they wish to unlock the car, the driver can use the app to generate a new virtual terminal, as described above. This virtual terminal is configured with the necessary security data (such as keys) to enable the driver to securely control the car via their phone, such as unlocking the doors.

[0083] List of clauses in the illustrative implementation plan

[0084] For illustrative and not limiting purposes, we now provide enumerated terms and alternative expressions to illustrate some of the implementations disclosed herein. The following set of terms is not intended to limit the ways in which the features disclosed herein can be combined. Any feature described with respect to a particular clause or set of terms is not intended to be limited to use in that respect, but may be combined with any other feature from one or more other clauses or sets of terms.

[0085] According to one or more embodiments disclosed herein, this disclosure can provide a computer-implemented method. This disclosure provides a corresponding (computer-implemented) system configured to perform the steps of any method disclosed herein. The method / system can be described as one or more of the following: A security method / system; A verification method; A method / system for simulating, generating, reconstructing, replicating, or emulating at least a portion of the state of another device on a user device, wherein a remote computing resource specifies, requests, influences, or otherwise provides the at least a portion of the state of the other device; A method for controlling access to controlled resources; A method for performing, controlling, authenticating, completing and / or processing electronic transactions or transmissions, including but not limited to electronic payments or transfers of digital assets.

[0086] The embodiments disclosed herein provide an improved solution for performing secure data transmission and can be advantageously applied to any of the following situations: It requires the secure sharing of sensitive data between at least two participants on an electronic network; and / or Before granting access to controlled resources (which may include the sensitive data), it is necessary to verify the identity and authorization of potential visitors.

[0087] In this document, we may describe example implementations of this disclosure within the context of conducting financial transactions. However, this example was chosen purely for illustrative purposes, and because such use cases are well-known and easily understood. This disclosure is not limited in this respect, and the implementations are equally applicable to other contexts and other purposes.

[0088] While the invention is not limited to such use cases, when the implementation is carried out in a payment system, the terms "on-us transaction," "internal payment / transaction," or "on-us cheque" refer to payments issued and received by the same financial institution. In other words, the transfer includes asset transfers between users belonging to or associated with the same entity. For example, a cheque or electronic transfer initiated from an account held by Bank A and submitted to another account also held by Bank A would be an "on-us" transaction. In such cases, the issuer can send the payment directly to the acquirer without the involvement of a settlement network (such as the Visa or MasterCard network). The payment is only rerouted internally to the receiving account.

[0089] Intra-bank transactions offer the technological advantage of shorter processing times because they do not require traversing interbank systems. Furthermore, intra-bank transactions significantly reduce energy and processing resource consumption by avoiding the need to access external networks for authorization or fund exchange. Moreover, intra-bank transactions are more secure because the risks of security breaches, attacks, or unauthorized interception are greatly reduced. Therefore, intra-bank transactions provide a more efficient and secure method for exchanging and transmitting funds across electronic networks.

[0090] In contrast, when the acquirer and the issuer are different entities, the transaction may be referred to as a "not-on-us item" or a "transit check." Such transactions require the involvement of an external network to facilitate the transmission and settlement of payments as they are sent to the acquirer.

[0091] Therefore, in the payments industry and other application areas, there are many situations requiring secure access to controlled resources and the exchange of sensitive data between senders and receivers who do not belong to the same organization. As a result, a lack of trust may exist between the parties involved. Numerous technical challenges arise, such as how to establish identities, ensure the secure communication, storage, and processing of sensitive data on unreliable end-user devices, and how to ensure that cross-network data exchange is performed in a manner that ensures only authorized parties can access sensitive data and other controlled resources. Technical challenges may also include how to leverage common, readily available electronic devices to perform secure electronic transfers (i.e., transactions) between different parties, each possessing or associated with secure configuration data, and / or associated with different transfer facilitation entities (e.g., acquirers).

[0092] Clause Set 1: Any feature or clause in Clause Set 1 may be combined with or incorporated into any other implementation or clause set provided herein. Example implementations of this disclosure may provide: Clause 1.1a: A method comprising the steps of: simulating or providing on / to a user's electronic device the (at least partial) state and / or functionality of at least one other electronic device (e.g., a payment terminal of a specific merchant). The "state" or "asset" may include configuration data, such as configuration files, encrypted data and / or encryption keys, and / or machine-executable logic code. The at least one other device may be a physical device or a virtual device.

[0093] Clause 1.1b: A method for performing electronic transfers between a user's electronic device and a second user associated with configuration data. The method may include the step of providing the user's electronic device with the second user's configuration data to enable the emulation of another electronic device on the user's electronic device. The other electronic device may be a computing device used to perform secure electronic transactions on behalf of the second user with other parties. The configuration data may include configured data, such as configuration files, encrypted data and / or encryption keys, and / or machine-executable logic code / instructions, thereby enabling the user's electronic device to simulate / emulate / copy / clone the (at least partially) state of the other electronic device (e.g., a merchant's payment terminal) on the user's electronic device.

[0094] Clause 1.1c: A method includes the following steps: The function of generating or facilitating the generation of at least one other device is created or implemented on the (first) user's electronic device. The other device may be a physical device or a virtual device. Additionally or alternatively, the at least one other device may be associated with a second user. The second user may include an individual, computing resource, or organization. The at least one other device may include a security device for performing the transfer of at least one electronic asset between the first user and at least one other party (which may include the second user). The step of creating or implementing the function of generating or facilitating the generation of the at least one other device on the (first) user's electronic device may include providing, installing, using, or executing configuration data on the user's electronic device, wherein the configuration is associated with the second user. The configuration data may be assigned to or associated with the second user by a third user / party / entity. The at least one other device may be or include a security device or terminal, such as a payment terminal and / or authentication device.

[0095] Preferably, one, some, or all of the following options may be applied to any option in Clause 1.1: i) The user's electronic devices include mobile, portable, handheld, and / or commercial off-the-shelf (COTS) devices; ii) The other electronic device includes hardware and / or software for performing data transmission with one or more other (computing) devices; the other device may include a payment terminal; iii) The other device is used to communicate with at least one remote resource; iv) The other device may be provided to the second user (e.g., a merchant) by or on behalf of the controlling (third) entity. iii) The state includes at least one encryption key; iv) A remote / third resource determines, identifies, influences, or otherwise provides the state of the other electronic device; the third resource may be a computation-based resource / system / device provided, operated, or used by a controlling entity; the controlling entity may be a bank, financial institution, or payment-related organization; for example, an acquiring bank, credit card provider, payment service provider, etc.; additionally or alternatively, the controlling entity may be the controller of a physical or electronic resource.

[0096] In one example of the terminology, "simulation of a state" can include, but is not limited to: Provide or implement the same or substantially the same functions or behaviors as the other electronic device; the functions may include: machine-executable instructions that can be stored in a computer memory and executed by one or more processors; and / or configuration data required or anticipated by the other device, such as encryption keys, merchant / user identifiers, etc.

[0097] Clause Set 2: Any feature or clause in Clause Set 2 may be combined with or incorporated into any other implementation or clause set provided herein. Additionally or alternatively, example implementations of this disclosure may provide: Clause 2.1: A computer-implemented method comprising the following steps: Simulate or provide the state of the security device on the user's electronic device (206, 207), wherein: i) the user's electronic device; and / or ii) The safety device is configured to: Controlling access to controlled resources; and / or Transmissions between a first party and a second party (e.g., financial transactions or other electronic transmissions, such as the transmission of documents, data or communications).

[0098] "Emulating" can include "copying", "replicating", "simulating", or "extending".

[0099] The first party may be the sender (transferor), the second party may be the receiver (assignee), or any other authorized party representing them. Preferably, the user's electronic device includes mobile and / or commercial off-the-shelf (COTS) devices.

[0100] In some examples, the controlled resource can be a physical resource, such as a vehicle, building, secure payment terminal / reader, IoT device (such as a smart TV), etc.; or it can be a virtual resource, such as a bank account, online account, digital wallet, virtual payment terminal, etc.

[0101] The security device may correspond to “another electronic device” as described in Clause Set 3.

[0102] Clause 2.2: The method of Clause 2.1, wherein: The step of “simulating or providing the state of the security device on the user’s electronic device” includes sending configuration data to the user’s electronic device to facilitate the generation of a simulation of the security device on the user’s electronic device.

[0103] The configuration data may include encrypted data, encryption keys, identifiers, machine-executable instructions, and other data. The simulation / providance can provide or implement the generation of a completely new instance of the simulation of the security device. This instance may be generated in a secure or protected storage / processing section of the user's electronic device. The generation of the simulation may be executed in response to a triggering event or condition (e.g., receiving an instruction). The simulation may be generated by software components (e.g., "applications" or "SDKs") installed on or executing on the user's electronic device.

[0104] Clause Set 3: Any feature or clause in Clause Set 3 may be combined with or incorporated into any other implementation scheme or clause set provided herein.

[0105] Additionally or alternatively, example embodiments of this disclosure may provide: Clause 3.1: A computer-implemented method comprising the steps of: simulating or providing the state of another electronic device on a user's electronic device (206, 207), wherein: i) The user's electronic devices include mobile and / or commercial off-the-shelf (COTS) devices; and / or ii) The other electronic device is a payment terminal.

[0106] In some implementations, the payment terminal may include hardware and software that are substantially as known in the art of payment solution devices, such as those described at: https: / / en.wikipedia.org / wiki / Payment_terminal.

[0107] Clause 3.2: According to the method of Clause 3.1, wherein: The step of simulating the state of the other electronic device on the user's electronic device is performed by a software component, the software component being installed on the user's electronic device and / or executed by the user's electronic device.

[0108] Clause 3.3: The method according to Clause 3.1 or 3.2, and further including the following steps: i) Provide a software component to the user's electronic device, the software component being used to simulate the state of the other electronic device on the user's electronic device; and / or ii) Installing and / or executing a software component on the user's device, the software component being used to simulate the state of the other electronic device on the user's electronic device.

[0109] Clause 3.4: The method according to Clause 3.2 or 3.3, wherein the software component is used to acquire authentication data to facilitate the authentication of the user's identity and / or the user's authorization for electronic transactions.

[0110] Clause 3.5: According to the method of Clause 3.4, the authentication data includes one or more of the following: Personal Identification Number (PIN); Passwords, codes, or other identifiers; Audio or voice-related data; Biometric data; Payment card data; At least one encryption key.

[0111] In some implementations, the at least one encryption key may be provided in a digital wallet; and / or in a device such as a tag, remote key, wearable device, physical token, chip or processing component embedded in a card or host device, or any other suitable device for containing the encryption key.

[0112] Clause 3.6: The method according to Clause 3.4 or 3.5, wherein the authentication data is obtained by at least one hardware and / or software component, wherein the at least one hardware and / or software component is provided on, within, or associated with the user's electronic device.

[0113] Clause 3.7: According to the method of Clause 3.6, the at least one hardware and / or software component provided on, within, or associated with the user's electronic device includes one or more of the following: a touchscreen; a physical or virtual keypad or keyboard; a microphone; a camera; a near field communication (NFC) reader or device; a short-range wireless component; a peer-to-peer component; a smart card reader; a magnetic stripe reader; or a fingerprint or iris scanner.

[0114] Clause 3.8: The method according to any of the foregoing clauses, and further including the following steps: obtaining from the user's electronic device: i) Transaction data relating to a (potential) electronic transaction between the sending resource (204) and the receiving resource (205); and ii) Authentication data; and using the transaction data and the authentication data to facilitate electronic transmission.

[0115] The electronic transmission may be a "potential" transmission, the successful execution of which may depend on meeting certain criteria, such as successful verification of the user's identity and authorization of the transmission. The authentication data may include authentication data mentioned in the foregoing clauses or elsewhere herein.

[0116] The sending resource may be associated with a user, such as the user's issuing bank. The receiving resource may be associated with the owner, operator, or controller of the other electronic device (e.g., a merchant), such as the merchant's acquiring bank or payment solution provider.

[0117] Clause 3.9: According to the method of any of the preceding clauses, the state of said other electronic device includes: i) Identification means for uniquely identifying the other electronic device; and / or ii) One or more encryption keys.

[0118] Clause 3.10: The method according to any of the preceding clauses, wherein: the step of simulating or providing the state of the other electronic device on the user's electronic device is performed as required or in response to a triggering event.

[0119] Clause 3.11: The method according to any of the preceding clauses, wherein: the state of the other electronic device is temporarily simulated on the user's electronic device.

[0120] Clause 3.12: The state of said other device according to any of the preceding clauses: i) Provided, specified, or determined by remote resources; and / or ii) Provided at least in part by the remote resource to the other device.

[0121] Clause 3.13: The method according to any of the preceding clauses, wherein: the step of simulating the state of the other electronic device on the user's electronic device includes: installing configuration data on the user's electronic device.

[0122] Clause 3.14: The method according to any of the preceding clauses further includes: removing the simulated / provided state from the user's electronic device; preferably, the state is removed after an operation involving interaction with a remote processing resource is completed.

[0123] Clause 3.15: A method for performing electronic transfer between a first party (204) associated with a user (201) of an electronic device (206, 207) and a second party (205) associated with a merchant (202), the merchant being associated with a payment terminal, the method comprising the steps of: i) Sending or otherwise providing from the second direction to the user's electronic device: configuration data to generate a simulation of the payment terminal on the user's electronic device; and data related to the electronic transmission; and ii) Using the simulation of the payment terminal, authorizing data is sent from the user's electronic device to the second party or an authorized representative of the second party, the authorizing data representing the user's authorization for the electronic transmission.

[0124] Clause Set 4: Any feature or clause in Clause Set 4 may be combined with or incorporated into any other implementation or clause set provided herein. Additionally or alternatively, example implementations of this disclosure may be provided: Clause 4.1: A computer-implemented method comprising the steps of: providing at least one software component, said at least one software component being used for one or more of the following: sending to a user's electronic device, downloading to a user's electronic device, installing on a user's electronic device, and / or executing on a user's electronic device, wherein: i) The at least one software component can be used to simulate the state and / or function of a security device on the user's electronic device; and ii) The safety device is used for Controlling access to controlled resources; and / or Facilitate the transfer between a first party and a second party (e.g., financial transactions or other electronic transfers, such as the transfer of documents or communications).

[0125] The methods and steps of any of the foregoing clause sets or the features disclosed herein may be combined with clause set 4.1.

[0126] Furthermore, embodiments of this disclosure may provide a computer device, including: A memory containing one or more storage units; and A processing apparatus comprising one or more processing units, wherein the memory stores code for running on the processing apparatus, the code being configured to perform methods for any of the terms or sets of terms described herein when executed on the processing apparatus.

[0127] Furthermore, embodiments of this disclosure may provide a computer program embedded in computer-readable storage, the program being configured to execute any of the terms or sets of terms described herein when run by one or more processors.

[0128] the term

[0129] The terms used below may have (but are not limited to) at least the following meanings in this document: Control entity: This refers to any entity that has the authority to grant or deny access to controlled resources; for example, resource owners, system administrators, data controllers, owners / occupiers of vehicles or buildings, account operators or providers, etc.; the controlling entity may include at least one human individual, at least one computing resource including hardware and / or software, or a combination thereof.

[0130] Controlled resources: This can include any type of entity, virtual or digital resource that the controlling entity wishes to keep secure and grant access to only entities authorized by it; for example, controlled resources can include one or more of the following: electronic devices (such as mobile phones or laptops), financial or other accounts, vehicles / buildings, computer networks / file systems or portions thereof, and sensitive data, etc.

[0131] Sensitive data: Sensitive data can include any data that the controlling entity wishes or needs to keep secret and not share (unless it is an entity with permission to access it); sensitive data can be described as a “controlled resource”; it can also be used to protect further controlled resources, such as electronic devices, accounts, vehicles / buildings, networks, etc.; for example, sensitive data can include passwords, identifiers, encryption keys, etc.

[0132] user: It may include at least one human individual, at least one computing resource including hardware and / or software, or a combination thereof.

[0133] Certification : Can be used interchangeably with "validation" and / or "verification", including a method for checking the identity and / or authorization of a user who is seeking, requesting, or attempting to obtain access to a controlled resource.

[0134] Install / Uninstall: "Install" may be used interchangeably with "activate", "set up", "provide for execution" or "provide"; correspondingly, the term "uninstall" may be used interchangeably with "disable", "disable", "prevent execution", "destroy", "delete", "erase" or "remove".

[0135] equipment The term "device" should not be understood as referring to a single, independent device; in many cases, "device" can include multiple hardware, software, and / or firmware components and can be implemented as a distributed resource. The term "resource" is used interchangeably with "system" and "device".

[0136] Electronic devices: The phrase "electronic device" may be used interchangeably with "computing device" or "processing device" herein. An electronic device may include hardware and / or firmware for storing data and / or executing instructions.

[0137] Get : can be interpreted as any term that conveys a result of “owning”, such as (but not limited to) receiving, calculating, generating, or determining from the sender.

[0138] trade The term “transaction” as used in this article includes one, some or all of “transfer,” “interaction,” or “exchange,” and should not be construed as limited to financial transactions.

[0139] An explanatory computing environment for implementing the scheme.

[0140] We now refer to Figure 3It illustrates an example device 2500. This device has a processor 2502 and a memory 2504, which can be used to implement some or all of the embodiments of the methods and processes disclosed in this application. Those skilled in the art will readily understand that many other forms and layouts of hardware, software, and / or firmware can be used for this purpose. Figure 3 The present section of this specification is merely one example of many possible variations. Memory 2504 may also host one or more databases and may include one or more forms of volatile data storage media (such as random access memory RAM) and / or one or more forms of non-volatile storage media (such as read-only memory ROM, flash memory, etc.).

[0141] Device 2500 is an example of a computing device or programmable device and is not intended to impose any limitations on the scope of use or functionality of device 2500 or its possible architecture. For example, device 2500 may include one or more computing devices, programmable logic controllers (PLCs), etc.

[0142] Furthermore, device 2500 should not be construed as having any dependency on any single or combination of the components shown in device 2500. For example, device 2500 may include one or more computers, such as laptops, desktops, mainframes, etc., or any combination or accumulation thereof. Device 2500 may also include bus 2508 designed to allow various components and devices, such as processor 2502, memory 2504, and local data memory 2510, to communicate with each other.

[0143] Bus 2508 may include one or more of several types of bus architectures, including memory bus or memory controller, peripheral bus, Accelerated Graphics Port (AGP), and processor or local bus using various bus architectures. Bus 2508 may also include wired and / or wireless buses. Local data storage 2510 may include fixed media (such as RAM, ROM, fixed hard disk, etc.) and removable media (such as flash drives, removable hard disks, optical disks, magnetic disks, etc.). One or more I / O devices may communicate through user interface (UI) controller 2514, which may be directly connected to I / O device 2512 or connected to I / O device 2512 via bus 2508.

[0144] In one possible implementation, network interface 2516 can communicate with the outside of device 2500 via a connected network. Media driver / interface 2518 can accept removable physical media 2520, such as flash drives, optical discs, removable hard drives, software products, etc. In one possible implementation, logic, computational instructions, and / or software programs containing the elements of module 2506 can reside on removable media 2520 that can be read by media driver / interface 2518.

[0145] In one possible implementation, I / O device 2512 may allow a user (e.g., a human annotator) to input commands and information into device 2500, while also allowing information to be presented to the user and / or other components or devices. Examples of input devices 2512 include, for example, sensors, keyboards, cursor control devices (e.g., mice), microphones, scanners, and any other input devices known in the art. Examples of output devices include, for example, display devices (e.g., monitors or projectors), speakers, printers, network interface cards, etc.

[0146] The various systems and processes disclosed herein can be described in the general context of software or program modules, or these techniques and modules can be implemented in pure computing hardware. Software typically includes routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. Implementations of these modules and techniques can be stored on or transmitted through some form of tangible computer-readable medium. A computer-readable medium can be any usable, tangible, and accessible data storage medium that can be accessed by a computing device. Therefore, a computer-readable medium can include a computer storage medium. "Computer storage medium" means tangible medium, including volatile and non-volatile, removable and non-removable tangible media implemented in any method or technique for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media include, but are not limited to: RAM, ROM, EEPROM, flash memory or other storage technologies; CD-ROM, digital versatile optical disc (DVD) or other optical storage devices; magnetic tape cassettes, magnetic tape, disk storage or other magnetic storage devices; or any other tangible medium that can be used to store desired information and is accessible by a computer. Some of the methods and processes described above can be executed by one or more processors. The term “processor” should not be construed as limiting the embodiments disclosed herein to any particular device type or system. A processor may include or be part of a computer system. Multiple processors may be used, and these processors may operate in parallel. A computer system may also include at least one computer processor (e.g., a microprocessor, microcontroller, digital signal processor, general-purpose computer, special-purpose machine, virtual machine, software container, and / or device) for performing any of the methods and processes described above. The system may be or include a decentralized, peer-to-peer, or distributed computing architecture.

[0147] Computer systems may also include memory, such as semiconductor storage devices (e.g., RAM, ROM, PROM, EEPROM, or flash programmable RAM), magnetic storage devices (e.g., floppy disks or fixed disks), optical storage devices (e.g., CD-ROMs), PC cards (e.g., PCMCIA cards), or other storage devices.

[0148] Alternatively or additionally, the processor may include discrete electronic components, integrated circuits (e.g., application-specific integrated circuits (ASICs)), and / or programmable logic devices (e.g., field-programmable gate arrays (FPGAs)) coupled to a printed circuit board. Any of the methods and processes described above can be implemented using such logic devices.

[0149] Some of the methods and processes described above can be implemented as computer program logic that works in conjunction with a computer processor. Computer program logic can be embodied in various forms, including source code or computer-executable form. Source code can include a series of computer program instructions in various programming languages ​​(e.g., object code, assembly language, or high-level languages ​​such as C, C++, or Java). Such computer instructions can be stored in a non-transitory computer-readable medium (e.g., memory) and executed by a computer processor. Computer instructions can be distributed in any form, such as on removable storage media with accompanying printed or electronic documentation (e.g., laminated software), pre-installed in a computer system (e.g., on system ROM or a fixed disk), or distributed from a server or electronic bulletin board via a communication system (e.g., the Internet or the World Wide Web).

[0150] Although only a few example embodiments have been described in detail above, those skilled in the art will readily understand that many modifications can be made to the example embodiments without substantially departing from the invention. Therefore, all such modifications are intended to be included within the scope of this disclosure as defined in the following claims. In the claims, means-plus-function clauses are intended to cover structures described herein as performing the functions described, including not only structural equivalents but also equivalent structures.

[0151] Conclusion

[0152] The above embodiments are for illustrative purposes only and are not intended to be limiting. Those skilled in the art can devise numerous alternative embodiments without departing from the scope of the invention as defined by the appended claims. In this document: the words “comprising” and “comprises” are synonymous with “includes” and do not exclude the presence of any features other than those listed in the claims or disclosed in the specification as a whole; “comprises” is intended to mean “includes or consists of”, while “comprising” is intended to mean “including or consisting of”. A singular reference to an element does not preclude a plural reference to that element, and vice versa. Embodiments of this disclosure can be implemented by hardware comprising several different elements, and by a suitably programmed computer. In the device or system claims that enumerate several means, several of these means can be embodied by the same item of hardware. The fact that certain measures are enumerated only in mutually different dependent claims does not imply that combinations of these measures cannot be advantageously used.

Claims

1. A computer-implemented method, comprising the following steps: Simulate or provide the state of another electronic device on the user's electronic device (206, 207), wherein: i) The user's electronic devices include mobile and / or commercial off-the-shelf (COTS) devices; and / or ii) The other electronic device is a payment terminal.

2. The method according to claim 1, wherein: The step of simulating or providing the state of the other electronic device on the user's electronic device is performed by a software component, the software component being installed on the user's electronic device and / or the user's electronic device executing the software component.

3. The method according to claim 1 or 2, further comprising the following steps: i) Provide a software component to the user's electronic device, the software component being used to simulate the state of the other electronic device on the user's electronic device; and / or ii) Installing and / or executing software components on the user's device, the software components being used to simulate or provide the state of the other electronic device on the user's electronic device.

4. The method according to claim 2 or 3, wherein, The software component is used to acquire authentication data to facilitate the authentication of the user's identity and / or the user's authorization for electronic transactions.

5. The method according to claim 4, wherein, The authentication data includes one or more of the following: Personal Identification Number (PIN); Passwords, codes, or other identifiers; At least one memorable word or phrase; Answer to at least one security question; Audio or voice-related data; biometric data; Payment card data; at least one encryption key.

6. The method according to claim 4 or 5, wherein, The authentication data is obtained by at least one hardware and / or software component, wherein the at least one hardware and / or software component is provided on, within, or associated with the user's electronic device.

7. The method according to claim 6, wherein, The at least one hardware and / or software component provided on, within, or associated with the user's electronic device includes one or more of the following: a touchscreen; a physical or virtual keypad or keyboard; a microphone; a camera; a near field communication (NFC) reader or device; a short-range wireless component; a peer-to-peer component; a smart card reader; a magnetic stripe reader; or a fingerprint or iris scanner.

8. The method according to any one of the preceding claims, further comprising the following steps: Obtained through the user's electronic device: i) Transaction data related to electronic transactions between sending resource (204) and receiving resource (205); ii) Authentication data; The transaction data and the authentication data are used to facilitate electronic transmission.

9. The method according to any one of the preceding claims, wherein, The state of the other electronic device includes one or more of the following: i) Identification means for uniquely identifying the other electronic device; ii) One or more encryption keys; iii) One or more machine-executable instructions.

10. The method according to any one of the preceding claims, wherein: Based on demand or in response to a triggering event, perform the steps of simulating or providing the state of the other electronic device on the user's electronic device.

11. The method according to any one of the preceding claims, wherein: The state of the other electronic device is temporarily simulated or provided on the user's electronic device.

12. The method according to any one of the preceding claims, wherein the state of the other device is: i) Provided, specified, or determined by remote resources; and / or ii) Provided at least in part by the remote resource to the other device.

13. The method according to any one of the preceding claims, wherein: The step of simulating the state of the other electronic device on the user's electronic device includes: The configuration data is installed on the user's electronic device.

14. The method according to any one of the preceding claims, wherein the method further comprises: Remove the simulated or provided state from the user's electronic device; Optionally, the state is removed after an operation involving interaction with a remote processing resource is completed.

15. A method for performing electronic transfer between a first party (204) associated with a user (201) of an electronic device (206, 207) and a second party (205) associated with a merchant (202), the merchant being associated with a payment terminal, the method comprising the steps of: i) Send from the second direction to the user's electronic device: Configuration data to generate a simulation of the payment terminal on the user's electronic device; and data related to the electronic transmission; and ii) Using the simulation of the payment terminal, authorizing data is sent from the user's electronic device to the second party or an authorized representative of the second party, the authorizing data representing the user's authorization for the electronic transmission.

16. A computer-implemented method, comprising the following steps: Provide at least one software component, said at least one software component being used for one or more of the following: sending to a user's electronic device, downloading to a user's electronic device, installing on a user's electronic device, and / or executing on a user's electronic device; in: i) The software component can be used to simulate the state and / or function of a security device on the user's electronic device; and ii) The safety device is used for: Controlling access to controlled resources; and / or Facilitate transmission between first-party and second-party systems.

17. A computer device, comprising: A memory that includes one or more storage units; and A processing apparatus comprising one or more processing units, wherein the memory stores code for running on the processing apparatus, the code being used to perform the method as described in any one of claims 1 to 16 when running on the processing apparatus.

18. A computer program embedded in computer-readable storage, the computer program being configured to perform the method as described in any one of claims 1 to 16 when executed on one or more processors.

Images