Improved computer-implemented systems and methods for secure electronic transfers

Abstract

The disclosure provides solutions for authorization of a first party that is attempting to perform an operation in collaboration with a second party. The second party may need to verify the first party's permission to use or access a controlled resource prior to performing the operation. A preferred embodiment comprises obtaining authorisation data from a physical or virtual security token arrangement located at or in close proximity to the first party's device, and providing the authorization data from the first party's device to the second party's device via a secure communication channel that the second party's device has established with an authorisation data capture component provided on the first party's device. The authorisation data capture component may emulate a wireless close-proximity data communication.

Description

[0001] IMPROVED COMPUTER-IMPLEMENTED SYSTEMS AND METHODS FOR SECURE ELECTRONIC TRANSFERS

[0002] TECHNICAL FIELD

[0003] This disclosure relates generally to methods and systems for secure transfer or exchange of electronic data between a sending party and a receiving party. The disclosure is particularly suited for applications in which a first party needs to be authorized in order to perform an operation in collaboration with a second party. Furthermore, the disclosure is suited for contactless authorization of the first party. It is particularly suited for, but not limited, to use in authorization of one or more of the parties prior to allowing access to and / or transfer of a controlled resource. Additionally, or alternatively, embodiments may provide improved computer-implemented solutions for conducting secure communications between collaborating parties.

[0004] BACKGROUND

[0005] In recent years, contactless authorization techniques have been commonplace and are used frequently in situations where a party needs to prove that they are authorized (i.e. have legitimate right or permission) to perform a given operation. Such operations typically relate to the use of or access to a controlled resource of some sort, such as entering a building or vehicle, operating machinery, accessing funds in a bank account, accessing a computing network or data resource such as a file etc.

[0006] Typically, the authorizing user is in possession of some form of security token that stores secret authorization data associated with the user and which testifies as to their permissions in respect of the controlled resource. Such secret authorization data might comprise private cryptographic keys, digital certificates and so on. (Background information relating to security tokens can be found online at: https: / / en.wikipedia.Org / wiki / Security_token#NFC_tokens). The security token is typically issued by an issuing authority and associated with the user who is known to the issuer in some way. The issuer has a securely stored record of the user's authorizationdata, so is able to compare the authorization data presented in an authorization request against their records and, if the two match then the user authorization process succeeds, otherwise it fails.

[0007] When the user needs to authorize, (s)he presents their security token to a device that has the ability to read the authorization data from the token. In earlier usage of the technology, this comprised swiping a card with the data on a magnetic strip through a card reading terminal, but in later years this has been more commonly replaced with the practice of inserting a smart card into a reading device that is arranged to access the data from an Integrated Circuit Chip.

[0008] However, in even more recent times, contactless tokens have become more widespread and it has become commonplace to simply 'tap' the security device against the reading device - although the term 'tap' may be something of a misnomer as most arrangements allow for close-proximity of the security token to the reader device rather than actual, physical contact between the two. Hence, processes which utilize these technologies have become known as "contactless" authorizations.

[0009] Contactless authorization arrangements can make use of any wireless communication protocols or technologies which are capable of sharing data over the desired distance for a given implementation. For example, Bluetooth ™ may be suitable for situations where relatively non-critical data needs to be shared over short distances of up to 10 meters. In relation to the transfer of highly sensitive data, however, 10 meters may be too wide a transmission area due to potential eavesdropping and another protocol such as NearField Communication (NFC) may be more suitable as it covers a shorter distance of approximately 4cm to 10cm.

[0010] As contactless authorizations provide benefits in terms of speed, convenience and security, they have become more and more popular. Applications include access to electric vehicles, buildings, machinery, computer-implemented resources and so on.Perhaps the most well-known and widespread use of the technology is found in the financial industries for use in performing contactless payments. Therefore, examples provided herein may be chosen from this application area in order to elucidate the disclosed embodiments, as it is readily known and easily understood. However, embodiments of the disclosure are not limited to use only in respect of one application area or industrial applicability. As electronic and computing technologies advance, contactless authorization is becoming more and more widespread and other uses of the disclosed embodiment may be readily found in technical areas such as autonomous vehicles and virtual reality environments.

[0011] Due to the advantages of contactless benefits, coupled with the now ubiquitous presence of mobile devices such as smartphones, wearable devices and tablets, new arrangements have been developed in which the reader device is incorporated into consumer-off-the-shelf (CoTS) devices. For example, smartphones etc now include wireless communications capabilities such as NFC and Bluetooth™ etc as standard features. This can be used to advantage when coupled with a virtual (tokenised) security device provided on the phone, such as a virtual smart card. Tokenisation essentially provides a purely digital (virtual) version of a physical security token. These virtual security tokens are typically linked to a particular hardware device e.g. phone associated with the authorised user and managed via a software application such as a digital wallet which manages authorization requests, provision of the tokenised authentication data, any required user authentication needs etc. Thus, in use, when the user wishes to authorize an operation request, the user 'taps' their phone on the corresponding reader device (e.g. payment terminal / access control system) at the necessary location instead of a smart card. The corresponding reader device then detects the phone's presence and a close proximity wireless communication channel is established. The authentication data stored in the virtual card on the phone is obtained by the reader device via that channel. (Note, the term 'reader' is often used in the technical field to include a device which can read and transmit data via a wireless communication protocol). Thus, when the phone is held within range of the other party's reader device provided in e.g. a merchant's Point-of-Saleterminal, a car's door, or an access gate at a railway station, the device reader can wirelessly and contactlessly access the authentication data.

[0012] However, while the security token may be provided on the user's device, in all of these examples the reader device is:

[0013] a) embedded within a device provided by the other party rather than the user; b) at a location determined by the other party - the user has to be at that location in order to tap their card or phone on the other party's reader device;

[0014] c) expensive and technically complex to provide - for example, payment terminals are expensive due to the security and cryptographic controls that are embedded within them.

[0015] Thus, even though commonplace CoTS devices comprise wireless reader devices, there is no readily available technical solution which allows a user to 'tap' a contactless security token device on their own CoTS device to authorize an operation regardless of their location relative to the other party. This is usually so because it may not be desirable or permitted to use the wireless data readers in CoTS devices for the transmission of highly sensitive authorization data because CoTS devices are notoriously and inherently insecure.

[0016] Thus, there is a need to allow a user's CoTS device to act as a data reader device for secret authorisation data during an authorization process without relying on expensive hardware provided at the other party's location and without compromising security of the authentication data.

[0017] Embodiments of the disclosure provide solutions which address at least these technical problems.

[0018] SUMMARY

[0019] Aspects and embodiments of the present disclosure are set out in the accompanying claims.Embodiments of the present disclosure provide solutions (i.e. methods and systems) for secure communication of data, and for secure performance of operations such as transfers / exchanges conducted between two or more parties. Additionally, or alternative, embodiments may be described as providing systems and methods for performing authorization requests / processes, and / or authorizing a first party who wishes to perform an operation in collaboration with a second party.

[0020] The operation may comprise the transfer and / or exchange of data between the parties. Additionally, or alternatively, it may comprise access to or use of at least one controlled resource. This exchanged data may include sensitive data that needs to be transmitted, stored and / or processed in a secure manner. Performance of the operation may comprise performance of various subtasks or steps. Such subtasks may comprise the establishment of one or more secure communication channels between the parties, the authorization of at least one of the parties for the purpose of establishing that the at least one party has legitimate permission to perform the operation, and / or the transmission or sharing of sensitive data.

[0021] Preferred embodiments of the disclosure may provide solutions for secure connection of a first party's computing resource to a second party's computing resource. Any of the terms 'electronic device', 'device' or 'system' may be used interchangeably with 'computing resource'. The term 'first party's device' is intended to mean a device that the first user has access to or use / operation thereof, and which comprises memory associated with at least one processor that is capable of executing a set of instructions. In some embodiments, the first party's device may comprise a handheld, mobile or portable device, e.g. tablet, phone etc or some other form of computing device. It could be a CoTS device. It could, in some examples, comprise a laptop or PC.

[0022] Preferably, the first party device is provided with at least one wireless communication arrangement. This wireless communication arrangement may comprise one or morehardware, firmware and / or software elements that provide the first party's device with means (interface and protocol implementations etc) for receiving and / or transmitting data wirelessly with another device. Preferably, the wireless transmission interface comprises near or close proximity data transmission capabilities such as, for example, such as Radio Frequency Identification (RFID) communications, Near Field Communication (NFC) communication, Bluetooth ™, Ultra-wideband (UWB), radio communications etc.

[0023] In a preferred embodiment, the wireless communications arrangement comprises a reader component that comprises at least one sensor and is arranged to detect the presence of a target and read data from the target. The target may comprise a security token device that stores secret credential (authorization) data relating to the first party as described herein. The security token device may also be referred to herein as a "security token arrangement".

[0024] The first party's device may also comprise one or more of:

[0025] • at least one input device for presentation of data to a user of the device, e.g. a touchscreen and associated sensors for detection of input by the user; a microphone, biometric data capture capabilities, at least one camera, proximity sensor arranged to detect a target etc.,

[0026] • at least one output device e.g. a speaker for presentation of audio communications to a user.

[0027] In a preferred embodiment, when the first party wishes to perform an operation with the second party, the first party may initiate an operation process which we may refer to as a 'session'. During the session, the first party's device may act as a secure interface that communicates data to the second party's device. The session may be controlled, executed and / or implemented, at least in part, by an 'operation control' software component that is installed for execution on the second party's device and arranged to perform and provide any combination of the functionalities and features disclosed herein in accordance with an embodiment of the present disclosure.During the initiation, the first party's device and the second party's device may perform a cryptographic handshake so as to establish a first secure communication channel between them. The handshake may be initiated by the second party's device and responded to by the first party's device. Preferably, the first secure communication channel may be arranged to allow bi-directional flow of data between the first party's device and the second party's device.

[0028] This data, which can be sent in either direction between the parties along the first secure communication channel, may be referred to as "first data". The first data may comprise any data relating to the operation itself or any attribute(s) thereof, such as an identifier or other indicator of a resource being transferred, processed or controlled via the operation, a value for the resource, one or more timestamps relating to the operation such as time session is started etc. The channel may be secure in the sense that the data transmitted via the channel is encrypted and cannot be decrypted without the correct key. In accordance with the disclosure, the first communication channel is established between the two parties such that the parties have the necessary key(s) to encrypt and decrypt the data that is shared between them.

[0029] A second secure communication channel may be established between the second party's device and the first party's device following establishment of the first secure communication channel. The second channel may be secured by the first party's device using at least one key (possibly a public key) that is generated by the second party's device and sent to the first party's device via the first communication channel. The public key may correspond to a private key that can be used to decrypt data transmitted via the secure second channel such that data transmitted through the channel is encrypted via the public key at the first user's device and can only be decrypted by the second party who has the corresponding decryption / private key. Advantageously, the private key may not need to be shared by the second party's device, thus preserving security.The second communication channel may be established:

[0030] • between the second party's device and at least one software / hardware component that provides a virtual / physical wireless communications device (e.g. virtual / physical NFC reader) arrangement on or in association with the first party's device. The virtual / physical wireless communications device may be referred to as a virtual / physical reader device / arrangement. It may be operative to capture output from a physical wireless data reader of the first party's device (e.g. a physical NFC reader) and / or a digital token security arrangement (e.g. a digital wallet) provided on the first user's device; and / or

[0031] • between the (first) virtual / physical wireless communications device (e.g.

[0032] virtual / physical NFC reader) arrangement of the first party's device and a (second) virtual / physical wireless communications device (e.g. virtual / physical NFC reader) arrangement provided on or at the second party's device; and / or

[0033] • as a secure, one-way communication channel for transmission of second data from the virtual reader device to the second party's device. Preferably, this second data comprises authorization data that is obtained, at least in part, by the physical wireless data reader device or the digital security token arrangement of the first party's device. The physical wireless data reader device and the digital security token arrangement may be arranged to obtain authorization data from a security token arrangement / device. The security token device can be provided in a physical or virtual form (i.e. it may comprise a hardware security token arrangement or a software / soft token arrangement); it may comprise / store authorization data relating to permission to use a controlled resource;

[0034] for example:

[0035] o the security token arrangement may comprise a smart card, payment card, key fob, Hardware Security Module (HSM), Trusted Platform Module (TPM), a digital wallet etc;

[0036] o the authorization data may comprise one or more (preferably secret) data items; the authorization data may be issued by or on behalf of an owner or controller of the controlled resource; the authorization data may comprisedata item(s) that can be used to verify the first party's authorization (i.e. permission) to access or otherwise use the controlled resource; for example, cryptographic key(s), certificate(s) and / or one or more tokenized secrets i.e. tokens that can be used to establish the first party's authorisation to perform the operation in respect of the controlled resource.

[0037] In some embodiments (but not all), the first party may also be required to provide third data for the purpose of verifying the user's identity before being allowed to perform the operation in respect of the controlled resource. We may refer to this as "authentication data". Whereas the authorization data mentioned above provides credential(s) for verifying the first party's permissions and access rights, the authentication data may provide one or more credentials for verifying that the first party is, indeed, who they purport to be.

[0038] Thus, the third data may comprise one or more data items that are associated with the first party and known only to the first party and the second party, so that the second party can check the third data provided by the first party against a previously stored record of the first party's third data. If verification of the first party's third data by the second party is successful, the operation may be allowed to proceed. If the authentication fails, the session may terminate or the first party may be asked to attempt authentication again.

[0039] Thus, the authentication data may comprise data that is inputted by the first party into the first party's device e.g. a PIN, password, biometric or voice data and / or other data derived from user's direct entry into the device. Thus, the user's device may facilitate the secure input of the third data by the first party. This may be performed, at least in part, on the first party's device via a keypad displayed on the touchscreen or via other input device(s) provided on or in association with the first party's device e.g. hardware and / or software components for capture of the first party's biometric data. In cases where thethird data is inputted into the first party's device, the third data may be sent to the second party for verification from the first party's device via the first secure communication channel.

[0040] However, in other embodiments, the third data may be obtained by the wireless communication arrangement of the first party's device from a third data source. The third data source may comprise the security token arrangement, which may store at least part of the third data. In such cases, where the third data is obtained rom the security token arrangement, the third data may be communicated to the second party via the second secure communication channel.

[0041] The third data that is transmitted across the second secure channel may be transmitted to the second party's device.

[0042] In a preferred embodiment, subsequent processing and / or storage of the second and / or third data may occur on or at the second party's device.

[0043] Thus, embodiments of the disclosure provide novel arrangements for secure communication and transfer of data for performance of operations between two or more parties. As the second data (and, optionally also the third data in some embodiments) is received from by the second party's device via a secure channel set up with the wireless communication component of the first party's device, the operation is effectively performed at the second party's device regardless of where the first and second parties are geographically located relative to each other. Preferred embodiments enable the first party to use a security token arrangement (e.g. smart card) and a first party device (e.g. mobile phone) to physically present secret credential data to the second party, even when the parties are located remotely from each other. This provides enhanced security, use of use for both parties, and more versatile control apparatus for controlling access to a controlled resource.

[0044] BRIEF DESCRIPTION OF FIGURESAspects and embodiments of the present disclosure will now be described, by way of example only, and with reference to the accompany drawings, in which:

[0045] Figure 1 illustrates a typical transfer process between a first party and a second party as known in the prior art of financial transactions, for illustration only.

[0046] Figure 2 illustrates, at high level, an embodiment of the present disclosure.

[0047] Figure 3 illustrates the embodiment of Figure 2 from a different perspective.

[0048] Figure 4 is a schematic diagram that illustrates, without limitation, a computing environment in which various embodiments of the disclosure can be implemented at least in part.

[0049] Figure 5 shows an embodiment of the present disclosure that is implemented using a cloud-based, virtual point-of-sale (POS) terminal.

[0050] DETAILED DESCRIPTION & ILLUSTRATIVE EMBODIMENTS

[0051] With reference to the accompanying Figures, we now describe an illustrative embodiment of the present disclosure. In our example, we use a financial transaction as our example use case because it provides a well-known scenario that will be readily understood. However, it is important to note that the disclosure is not limited with regard to this use case and may be used to perform and control any operation between two parties during which secure authorization of a first party is required before the operation can be performed.

[0052] In our example, therefore, we will refer to the first party as a 'user' or 'consumer', and the second party as a 'merchant', and the operation as a 'transaction'. The user's device in our non-limiting example is a mobile phone or wearable device, and the merchant's device is a Point-of-Sale (POS) terminal. In other examples, however, the first user may be a driver or operator of a building / machine / vehicle equipped with an access control arrangement, and the second party may be an owner, controller or administrator of the vehicle / building / machine. In other examples, the first party may be a bank account holder and the second party's device may be an or Automatic Teller Machine (ATM) thatis operated by the second party. The ATM may be equipped with a wireless communications reader.

[0053] Turning now to the Figures, Figure 1 illustrates the prior art approach to performing a 'card present' transaction in a store. The method comprises steps which are shown in numbered circles in Figure 1:

[0054] 1. The user decides to purchase an item from a merchant store (1030) and proceeds to a POS terminal (1040) to perform the checkout process. The user scans the item at the POS so that the POS receives all relevant data relating to the potential purchase (e.g. price, size, colour, identifier etc). When ready to pay, the user (1010) brings their security token arrangement (1020) into proximity with an NFC reader (1090) provided on the merchant's POS terminal (1040) e.g., by tapping the security token arrangement (1020) on the card reader.

[0055] In some cases, the security token arrangement is a payment (smart) card (1020) that is issued by the user's financial institution and stores authorisation data that enables the individual to prove that they are authorised, i.e. have permission to access the funds in the account identified by the authorization data. The authorisation data comprises data items and credentials such as at least one identifier, name(s), EMV- data, ARQC data, primary account number (PAN), one or more cryptographic keys, cardholder (user) name, an expiration date, a card security (CVV) code etc.

[0056] In another embodiment, though, the user may not present a physical payment card as their security token arrangement. Instead, the user may present a virtual payment card stored on an electronic device operated by the user. This may be, for example, a mobile phone or wearable device that comprises a digital wallet arranged to store one or more virtual cards. The virtual payment card comprises the tokenised authorization data. Thus, the security token arrangement can be provided in physical or virtual (digital) form. In this latter case, the user taps theirphone that stores the virtual card on the POS terminal instead of a tapping physical payment card.

[0057] In either case, the user's physical payment card or smartphone comprises a physical NFC tag which is operative to transmit / provide the authorisation data for the user's physical or virtual card to a corresponding reader. The merchant's POS terminal (1040) comprises an NFC reader (1090) which is able to detect the card / phone when it is brought into proximity with the POS. The NFC reader provided on the POS (1090) reads the authorization data from the NFC tag on the user's payment card or phone (1020). The encrypted authorisation data is transmitted to the POS's NFC reader via a secure communication channel that is established between them. This secure communication channel is established by a cryptographic handshake to exchange encryption keys between the physical NFC tag of the card / phone and the POS reader (1090) when the user taps.

[0058] In some scenarios, the user may also be prompted to authenticate their identity as an additional form of security. This prompt may be a message that is displayed visually on a screen or provided via audible means by the POS terminal. Being prompted, the user enters their user authentication data e.g. PIN etc into the POS terminal (1040) via a virtual or physical keypad or some other input device provided in association with the terminal (1040);

[0059] The POS terminal (1040) now has all the data required for the transaction to be processed:

[0060] ii) operation-related data relating to the purchase itself (e.g. price, payment type and time stamp etc); this data has been captured by the POS itself during the checkout process;

[0061] ii) authorization data which relates to and / or is stored in association with the user's virtual or physical payment card, and is obtained via the secure NFC channel set up between the NFC tag on the physical card / phone and theterminal's NFC reader; this data provides sensitive credentials that can be used to verify the user's permission (authorization) to make the payment; and iii) user authentication data (e.g. PI N, passcode or biometric data etc) obtained from the user in order to verify the individual user's identity. The POS encrypts the PIN and generates a PIN block as known in the art. It should be noted that in some situations the additional user authentication data is not required e.g. if the purchase price is below than a pre-determined threshold.

[0062] The POS encrypts and combines all three data components into a payment packet (message) and forwards it to the merchant's payment gateway via an API. The payment gateway then sends the message on to the acquiring bank's payment processor. The Acquirer may also be known as the 'merchant acquirer' or 'acquiring bank' (1050).

[0063] The acquirer's payment processor (1050) then sends the message to the scheme (1060) which is associated with the user's payment card e.g. Visa or Mastercard etc.

[0064] If the scheme (1060) itself is not the issuer (1070), the message is forwarded to the actual issuer i.e. the consumer's bank / financial institution. The issuer is responsible for controlling the user's account and authorising any requests for transfer of funds from that account. Thus, in this example, the 'controlled resource' is a bank account. The issuer knows or has access to the user's user authentication details such as password, PIN etc.

[0065] The issuer (1070) validates the transaction using the data in the message. If user authentication was required, the issuer will authenticate the user's inputted PIN against its stored records; it will also perform other checks such as whether the user's account contains sufficient funds to meet the transaction, whether the card has been reported lost or has expired etc. If the user authentication and cardchecks are successful the transaction can be completed, otherwise it will be declined. A 'success' or 'declined' result message is communicated from the issuer (1070) back to the scheme (1060)

[0066] 6. The scheme (1060) transmits the result message to the acquirer (1050);

[0067] 7. The acquirer transmits the result message to the merchant's POS terminal (1040);

[0068] 8. The merchant's terminal (1040) communicates the result message to the customer (user) e.g. by displaying a 'transaction approved' or 'transaction declined' message on the terminal screen.

[0069] However, in many situations the user (1010) is not present at the merchant store (1030) and cannot, therefore, bring the card or phone into physical proximity with the merchant's POS terminal to provide the necessary authorization data for the transaction process. Embodiments of the disclosure provide solutions that solve at least this technical problem, although the disclosure is not limited to solving only this problem and other technical problems may be addressed by one or more embodiments.

[0070] We now compare this prior art approach of Figure 1 with the novel approach of the present disclosure, which is described using our non-limiting example embodiment, and with particular reference to Figures 2 to 5.

[0071] In our example, a system is provided which comprises:

[0072] • User Device (2020):

[0073] In an embodiment, user device 2020 may be configured to implement functionality of the first party's device, described herein. In this example, the user's device is a mobile or wearable device but could take any suitable form of electronic device comprising data storage and processing capabilities. In contrast to prior art user device 1020, user's device (2020) comprises wireless (e.g. NFC)communication capabilities (2100) configured to provide a virtual NFC reader functionality, as described herein plus, preferably, at least one data input arrangement (2612, see Figure 4) to facilitate data input by the user (1010). The at least one data input arrangement (2612) could, in an example embodiment, comprise a touchscreen, coupled to a plurality of touch sensors, and associated software for provision of an operable keypad that the user can use to enter user authentication data such as a PIN, password etc. In other examples, the user's device (2020) may comprise a microphone and voice recognition software to enable entry of voice inputted data, or a camera, facial recognition technologies, a fingerprint sensor or other biometric capture arrangement(s).

[0074] The user device (2020) comprises a virtual NFC reader (2030) in accordance with an embodiment of the disclosure and that is generated and / or executed dynamically and on demand for execution on the user device by the second party's device.

[0075] The virtual NFC reader is explained in more detail below but, by way of overview, the virtual NFC reader functionality enables authorization data that has been obtained from the user's physical or digital security token to be transmitted to the NFC reader of the merchant's POS Terminal via a one-way, encrypted communication channel. The virtual NFC reader on the user's device functions as a replacement of the (prior art's) merchant NFC reader in the physical POS terminal that the user would tap on in-store. Instead of the authorization data being transmitted to the terminal's NFC reader by the transmitter (e.g. physical NFC tag of the card / phone), the authorization is instead captured, encrypted and diverted to the second secure communication channel. So, the user end of the second secure channel can be thought of as a virtual NFC reader because when it is received at the terminal end of the channel the data is processed as having been obtained by the terminal NFC reader directly from security token in close proximity.• Merchant POS Terminal (2040):

[0076] Merchant POS terminal (2040) may be referred to as the second party's device. In our example, merchant POS terminal (2040) comprises at least one computing resource that is either a virtual POS, hosted remotely e.g. in the cloud (1080) or provided at the merchant's location (1030) as a physical device. Merchant POS terminal (2040) includes two subsystems configured to facilitate the processing of a transaction - a transaction processor (2092) and POS NFC reader (2090).

[0077] Transaction processor (2092) provides a first interface, such as in cooperation with a merchant's web site, that is configured to gather details regarding a potential transaction from the user (1010). Typically, the user (1010) initiates a potential transaction by interacting with transaction processor (2092) by communicating with, for example, the merchant's website to select one or more products or services for purchase. The user (1010) can then initiate the transaction by providing an appropriate input (such as an instruction to "purchase items" provided to the merchant's web site). Upon receipt of the purchase instruction, Merchant POS terminal (2040) requests that the user (1010) provide payment information. In an embodiment, a message is transmitted by transaction processor (2092) of Merchant POS terminal (2040) to user device (2020), and possibly directly to the virtual NFC reader (2030) component of user device (2020), requesting that the user's device provide the payment information to POS terminal (2040). In contrast to a conventional POS terminal, which would require the user (1010) present a physical payment card including security token, such as a smart card, or a smart phone comprising a virtual security token, to a physical reader device connected directly to and in proximity of the NFC reader (2090), Merchant POS terminal (2040) includes a communication subsystem allowing Merchant POS terminal (2040) to receive payment card data via a secure communications channel established with user device (2020) rather than from the local physical card reader. In a particular embodiment, a secure communications channel is formed directly between POS NFC reader (2090) of Merchant POS terminal (2040) and virtual NFC reader (2030) of user device (2020). In that case,the secure communications channel may be an encrypted communication for which the security keys used to setup the communications are known only to POS NFC reader (2090) and virtual NFC reader (2030) and not known generally to the Merchant POS terminal (2040) and user device (2020). For example, the security keys may be distributed (e.g., in an encrypted form) by a manufacturer or distributor of one or both of POS NFC reader (2090) and virtual NFC reader (2030) at the time of manufacture (e.g., in the case of physical hardware device) or at the time of installation (e.g., when all or a portion of the reader is implemented in software). In that case, because the security keys are not known to either of Merchant POS terminal (2040) or user device (2020) generally, the secure communications channel cannot be monitored or tapped by other components of Merchant POS terminal (2040) and user device (2020) that may attempt to recover payment information from the secure communications channel. As such, the communications between POS NFC reader (2090) and virtual NFC reader (2030) may be controlled, for example, by a third party entrusted with validating and processing financial transactions (e.g., an issuing bank or payment processor).

[0078] • As described herein, this alternative communication channel enables Merchant POS terminal (2040), and, specifically, POS NFC reader 2090 to receive payment details from a remote source and not from a physical token reader device connected physically to POS NFC reader (2090). Upon receipt of those details, they can be processed as if received from a local reader by POS NFC reader (2090), which can validate the payment details. If valid, the corresponding output of POS NFC reader (2090) can then be passed to transaction processor, thereby enabling transaction processor (2092) to complete the proposed transaction.

[0079] • Accordingly, the POS terminal (1040) facilitates the transaction session by establishing two secure links with the user's device (1020):

[0080] o A first encrypted channel (2000) connected to the user's device (2020) (in an embodiment, the first encrypted channel (2000) can be formed between transaction processor (2092) and user device (2020) such as to enable the user of user device (2020) to browse available products andservices and initiate a transaction therefor); the first encrypted channel (2000) is a bi-directional channel meaning that the user can send and receive data to / from the merchant over this channel; conversely, the merchant can send and receive data to / from the user over this channel; this channel will be used for sharing of transaction-specific data that is described above as 'operation-related data' and can be used by transaction processor (2092) to receive details relating to a candidate transaction. This first encrypted channel (2000) can also be used by transaction processor (2092) to initiate the request for payment details for the transaction; it should be noted that this channel (2000) is not connected to the user's virtual NFC reader (2030);

[0081] A second encrypted channel (2010) that is connected to the virtual NFC reader (2030) on the user's device (1020). In an embodiment, this channel is formed using security keys known only to Merchant POS terminal (2040) and virtual NFC reader (2030) such that only those components can use, encrypt, decrypt, or otherwise access messages communicated using second encrypted channel (2010). This channel (2010) is a one-way transmission channel only, in that it operates purely as a transmission channel for sending of authorization data from the user's device to the merchant device.

[0082] Responsive to a request for payment information, payment authorization data could be obtained by the virtual NFC reader (2030) from the phone's physical NFC reader, which has read the authorization data from the user's physical security token arrangement, e.g., payment card. Alternatively, the virtual NFC reader (2030) may obtain the authorization data as output from a digital wallet that stores a virtual payment card comprising the tokenised authorization data. In either case, the authorization data that is captured by virtual NFC reader (2030) executing on the user's device (2020) is transmitted along the second channel (2010) to a data interception component (2060) executing on the terminal (2040). The datainterception component on the terminal receives the authorization data from the second channel (2010) and provides that data to the Merchant NFC reader (2090) in the place of locally retrieved authorization data (e.g., that might otherwise have been captured by a conventional local card reader). That authorization data can then be processed to ensure its validity, such as by POS NFC reader (2090) and, once validated, POS NFC reader (2090) can notify transaction processor (2092) of the same, enabling the transaction to proceed.

[0083] Advantageously, this arrangement ensures that no sensitive card data is stored or processed locally on the user's device (2020). In one or more embodiments, the content of the authorization data is determined by requirements set forth by a distributor of the POS NFC reader (2090). The kernel of the POS may be provided with such requirements hardcoded or pre-supplied. These requirements may specify the fields, format etc of the authorization data being transmitted via second encrypted channel (2010).

[0084] In preparing the authorization data, virtual NFC reader (2030) of user device (2020) is configured to read raw data from the presented physical or virtual payment card. That raw data is then encrypted and sent down the one-way second encrypted channel (2010). Upon receipt, POS NFC reader (2090) is configured to decrypt and process the authorization data locally for the merchant. That processing occurs at the merchant's terminal, using, in some cases, conventional payment information validation and authorization processing. As such, in an embodiment, virtual NFC reader (2030) of user device (2020) is configured to capture data from a physical or virtual payment card, encrypt the data, and send the encrypted data using second encrypted channel (2010) to the merchant terminal's POS NFC reader (2090) where the terminal accesses the data using its own NFC reader (e.g., POS NFC reader (2090)) just as if the payment data had been captured directly by POS NFC reader (2090) using a local physical card reader. As such, the data that is sent to Merchant terminal (2040) from userdevice (2020) can be indistinguishable to the merchant terminal from data that has been captured locally by the merchant terminal's POS NFC reader (2090) from a user that is physically present with the merchant.

[0085] • A security token arrangement: as explained above, this could comprise a physical or virtual device. It may comprise, for example, a smart card, key fob, wearable device, hardware security token or some other device that comprises the user's authorization data and an NFC tag (transmitter) arrangement capable of providing the authorization data to a corresponding data reader (1100). Alternatively, it could comprise a software-implemented arrangement such as a virtual smart card or some other virtual device that is arranged for storage and provision of tokenised authorisation data to a reader. The virtual payment card may be stored in an application such as a digital wallet that is either a standalone wallet or is embedded in another application. In some examples, upon request for an authorization, the virtual payment card is arranged to communicate its authorization data to the physical NFC reader that is provided with the user's device by the manufacturer.

[0086] In a preferred embodiment, a 'virtual reader component' (2030) is provided for execution on the user device so as to capture the authorization data outputted from the physical reader (1100) or digital wallet (2050) and direct the authorization data to the second communication channel (2010) for transmission to the merchant (1040) instead of to the physical NFC transmitter of the device for transmission to a closely located physical reading device. In an alternative form of wording, this component may be referred to as an "authorization data capture component" as it obtains the authorization data that the user's device has obtained from the security token device. The authorization data capture component receives the data that has been read by the physical NFC reader or wallet provided on the user's device and instead of the authorization data being provided to the NFC data transmitter for sharing with a corresponding reader thatis brought into in close proximity with the user device, the authorization data is sent to the remotely located merchant terminal via the second secure channel. Thus, an embodiment may be described as providing a software-implemented (i.e., virtual) reader / transmitter (2030) on the user's device, which is generated upon demand when a session is triggered and then destroyed once the required authorization data has been transmitted to and received by the merchant.

[0087] Additionally, or alternatively, a data interception component (2060) may be provided on the merchant's terminal (1040) to intercept the authorization data that is received at the terminal (1040) via the second channel (2010) rather than allowing the authorization data to be directed to the CPU of the terminal.

[0088] This arrangement provides a technical improvement over conventional payment processes in that the present solution allows for a remote authentication of payment details in circumstances where conventionally such authorization would only be capable locally. In particular, using the present invention, a user can pay for goods and services by tapping their payment card or using the digital wallet on their own mobile device, even when they are not physically present in the same location as the merchant. By enabling such remote authentication, the present invention allows for "card present" processing of transactions even when the user initiating payment is remote from the merchant and is unable to use the merchant's local physical card reader.

[0089] To ensure proper payment information processing, the NFC reader on the user's device (instead of the merchant's device) is utilized to capture the necessary data from the user's payment card (virtual or physical). That data is then transmitted via a secure communications channel (i.e., second encrypted channel (2010)) to the merchant for processing and validation.

[0090] In effect, this arrangement (e.g., second encrypted channel (2010)) establishes a "virtual cable" from the NFC reader of the user's device to the Merchant's POS NFC reader (2090) that is a one-way, encrypted communications channel established between the NFC reader on the user's phone (e.g., virtual NFC reader (2030)) and the NFC reader on themerchant's (cloud / mPOS) terminal (e.g., POS NFC reader (2090)). By doing this, anything that is received by the NFC reader at the merchant's end of the channel appears to the merchant device as if it has been provided locally by the user operating the merchant's POS device at the merchant's physical store, rather than remotely. The advantage of this is that the merchant and user do not need to be physically present or co-located, but the authentication of the user is secure. It also means that the authentication can be treated the same way as a "card present" transaction because, as described herein, the user can provide additional authentication information (e.g., a PIN or biometric authentication data) provided to the user's device (e.g., user device (2020)). This may provide a significant benefit to Merchants because transactions that can qualify as "card present" transactions can reduce liability for the issuers and banks responsible for transaction clearing and settlement.

[0091] In-use example:

[0092] Referring now to Figure 3, suppose the user (1010) is shopping on the merchant's web site. When the user (1010) wishes to purchase an item, (s)he proceeds to the checkout section in order to begin the transaction. The user initiates a secure link that establishes a first secure communication channel between the user device (1020) and the merchant terminal (1040). The user (1010) triggers this by performing a triggering action such using his / her mobile phone camera to scan a QR code, or by inputting data such as phone number into a data entry field on a checkout webpage, or clicking on a link / button provided on the merchant's checkout page. Depending on the embodiment concerned, the user either provides their mobile phone number or it is retrieved from an account or profile which the user has previously stored in association with the merchant's organisation.

[0093] In response to the triggering event, a set of machine-executable instructions (the 'operation control' software component mentioned above) begins to execute on a processor of the merchant's device (1040) so as to begin the transaction session.Firstly, the first communication channel (2000) is established between the user device and the terminal. A cryptographic handshake is performed so that the keys are exchanged. During the handshake, the connecting devices verify each other's identities, agree on one or more encryption algorithms that will be used for their subsequent communications, and also generate shared private keys that will be used to encrypt / decrypt the sensitive data that will be transmitted across the channel.

[0094] Secondly, the second communication channel (2010) is established between the NFC reader of the user device and the merchant's terminal. This second channel enables the user's authorization data, captured by the NFC reader on their phone, to be provided securely to the NFC reader of the terminal as if the terminal's own NFC reader had captured it directly from the user's smart card. This second communication channel is achieved by generating, at the terminal (1040) at least one new encryption key pair and sending the corresponding public key(s), via the first encryption channel, from the merchant terminal to the user device. This public encryption key(s) will be used to encrypt the data that will be sent from the user's NFC reader to the merchant terminal (1040). The merchant terminal has the corresponding private key so will be able to decrypt it. Note that the private key does not need to be communicated across any channels and, therefore, the disclosure provides a secure authorization process.

[0095] The virtual NFC reader (2030) may be generated on the user device at this time or may have been previously installed and is activated for execution upon demand by the terminal. Therefore, the disclosure can be viewed as providing an authorization data (NFC) reader on demand at the user's device when requested by the merchant's device.

[0096] The transaction process now proceeds, and the user is prompted to tap their physical payment card on their phone (1020) to authorise the payment, or authorise the payment using their stored virtual card (e.g. by double clicking a button on their phone and / or providing user authentication such as a PIN or facial recognition etc). This causes the authorization data to be captured and outputted from the physical NFC reader of thephone (in the case of a physical card), or outputted by the digital wallet (in the case of a virtual card). The virtual NFC component (2030) on the phone captures (obtains) this outputted authorization data from the relevant source (i.e. physical NFC reader or digital wallet), and directs it to the second communication channel (2010). It is then transmitted across the one-way encrypted channel to the merchant terminal where it is received by the interception component (2060) upon arrival at the terminal.

[0097] Depending on the circumstances of the transaction, the user may be prompted on the touchscreen of their device (1020) to input their user authorisation data so that their identity can be established. This user authentication data can comprise any type of data such as a PIN provided, or password or biometric data as explained above. This input may be captured by one or more components of the user's device, such as a virtual keypad displayed on the touchscreen, a camera, fingerprint detector, microphone and voice recognition software etc. The user's authentication data is encrypted at the user's device and sent, along with any other necessary operation-related data to the merchant terminal using the first secure channel 2000. In some embodiments, the PIN and / or biometric data is processed, and the user is verified in a secure element residing on the user's device. In other embodiments, the PIN and / or biometric authentication data is encrypted at the phone and then sent to an external third party that operates as an authenticating party (e.g., a government agency or other group authorized to perform such authentication). That third party decrypts the data and uses the decrypted data to attempt verification of the user. The success or failure of that authentication process can then be communicated by the third party back to the user's device and / or the relevant merchant. With both the payment data and authentication data, the merchant's terminal now has all the data it needs to proceed with the transaction. The traditional transaction processing steps are performed between the merchant, acquirer, scheme and issuer. These are shown as steps 2 to 7 in the prior art illustration of Figure 1.

[0098] Upon successful authentication of the user and authorization of the transaction, the result is securely transmitted back to the consumer's device. This is shown as step 8 inthe prior art illustration of Figure 1. Thus, the transaction is conducted without storing or processing any sensitive information at the user's end of the process.

[0099] If the merchant's terminal comprises a physical NFC reader (1090) as shown in Figure 1, it is effectively disconnected or deactivated when the second communication channel is established because the encrypted authorization data coming into the terminal from the second communication channel (2010) will be processed by the terminal's interception software (2060) as if it had been received from the terminal's own reader (1090). The terminal's interception software will decrypt the encrypted authorization data using the private key(s) that it generated for establishment of the second communication channel.

[0100] Conversely, the virtual NFC component (2030) that is executing on the user's device (1020) captures the authorization data received from the user's physical NFC reader (1100) if a physical payment card has been tapped on the phone, encrypts the authorization data using the public key that was sent from the terminal when the second channel was established, and sends the encrypted authorization data using the second communication channel (2010) to the terminal (1040). If a digital payment card has been used for authorization, the output generated by the digital wallet (i.e., the authorization data) is captured by the virtual reader (2030) rather than the output being sent to the phone's physical NFC reader for transmission via the traditional NFC transmission route. The output generated by the digital wallet is encrypted using the public key provided by the terminal and sent using the second communication channel to the terminal, which has no way to distinguish this incoming authorization from the phone's virtual reader from authorization data that is received by an NFC reader provided at a physical POS terminal as shown in Figure 1 of the prior art.

[0101] Thus, when the user device transmits the authorization data to the merchant's terminal, it is transmitted in a secure manner directly from the virtual NFC reader of the user device to the terminal. The virtual NFC reader is connected for communication to the physicalreader of the user's device and / or the digital wallet and / or any other type of virtual security token that is being used by the user.

[0102] From the terminal perspective, the transaction has been performed exactly as it would if the user is physically located at the terminal and bringing their security token device into proximity. No storage or processing of sensitive data is performed on the user's device, and the user's device (1020) simply serves as a conduit for secure communication and interaction, linking with the merchant's terminal to enable transaction processing without replicating sensitive functions on the consumer's device (1020). This provides a secure and efficient system for performing the transaction regardless of the user's physical proximity to the terminal.

[0103] As shown most clearly in Figure 3, in some embodiments the merchant's device (1040) can be implemented as a virtual device that is provided in the cloud. Thus, in Figure 3, the merchant store and POS terminal indicated by elements (1030) and (1040) respectively may be partially or wholly implemented by one or more cloud-based servers (1080). In wholly cloud-based embodiments, there may be no need for the virtual POS device to comprise interception software as there is no physical POS reading component that the authorization data needs to be diverted away from.

[0104] With reference to Figure 3, an embodiment of the disclosed process can be described generally as follows, and as shown by the circled numbers on Figure 3. In this embodiment, the merchant's computing resource comprises a virtual POS terminal that is implemented on a server 1080 in the cloud:

[0105] 1. the user (1010) has triggered a transaction session on a checkout page, so the user's device (1020) and the merchant's POS terminal (1040) perform the cryptographic handshake as explained above and exchange cryptographic keys; 2. the terminal connects to the virtual NFC reader (2030) provided on the user's device (1020) such that a secure communication channel is established between them;3. the user taps their payment card on their device (1020) and the NFC reader (1100) reads the authorization data from the card; alternatively, the user activates a virtual payment card stored on the user's device to provide the authorization data. The authorization data is obtained from the physical or virtual payment card by the virtual NFC reader (2030) which transmits it to the merchant POS terminal (1040) across the second secure communication channel (2010).

[0106] 4. In some situations, the user is required to input their authentication data e.g. PIN into the device (1020) which generates a PIN block and transmits it to the terminal (1040) via the first communication channel (2000). The transaction process proceeds as per prior art steps 2 to 8 shown in Figure 1 and explained above, and the 'approved' or 'declined' message is communicated to the user at the end of the process in 8. If approved, the controlled resource is accessed, processed or operated in some specified way.

[0107] When the transaction session terminates, the user's device is disconnected from the merchant terminal i.e. the communication channels established between them are disabled.

[0108] TERMINOLOGY

[0109] Herein, the following terms / phrases may be used as follows:

[0110] • Transaction:

[0111] this term is used herein in a generic sense and is not intended to be limited to solely financial transactions. Herein, a 'transaction' may include any operation, transfer or exchange performed between two or more parties. The transaction may comprise exchange or transfer or of any type of resource between the parties. Additionally, or alternatively, it may comprise the transfer of a controlled resource itself or control of the controlled resource;

[0112] • Transfer:

[0113] This term as used herein is intended to include the term 'exchange'; these two terms may be used synonymously and interchangeably herein

[0114] Controlled resource:This may comprise any type of resource, electronic, virtual or physical, which is controlled by an owning and / or controlling party. This could be, for example, a bank account, a computing network, a building, a device or system, a vehicle, a document or file etc. The controlled resource may only be used by party's that are authorized (i.e. have permission) to do so. The owning / controlling party may store or maintain a record of one or more authorised parties who have permission to use the controlled resource.

[0115] • Authentication:

[0116] This term may be used herein to comprise a process that seeks to establish the identity of a particular party and / or the party's authority or permission to access / process a controlled resource. The term may be used interchangeably with 'identity check' or 'validation'

[0117] • Authorization:

[0118] is used herein to establish a party's permission or otherwise to use a controlled resource. 'Use' means access, control, operate, read to, write from, interact with or in any way process the controlled resource.

[0119] • Keypad:

[0120] while this term is intended to be synonymous with 'pin pad' and 'keyboard', the term 'keypad' will be used herein for simplicity and clarity. The keypad may comprise a 'virtual' keypad that is implemented by way of software and hardware provided on an electronic / computing device comprising one or more processors. The hardware may comprise a touchscreen and sensor(s) arranged for detection of contact by a user with the surface of the touchscreen. Signals generated by the sensors may be used by the keypad software to determine which virtual key the user has touched, and a symbol or other indicia associated with the touched virtual key may be input into memory and processed accordingly

[0121] • Contactless authorization:

[0122] An authorization process that seeks to establish a party's permission to perform an operation (e.g. access a controlled resource, perform a transfer etc) by presenting secret authentication / authorization data to an authorising party from asecurity device in a wireless but close-proximity fashion. The security device may store the secret authentication / authorization data and can be physical e.g. an ICC card, HSM etc, or virtual e.g. a virtual card stored in a digital wallet or other software arrangement operative to store, access and transmit the secret authorization data to a recipient data sharing device (e.g. a card reader). User authentication may be required in or to access the secure authorization data from the security device. The authorization is contactless in the sense that it does not require the authorizing party to physically enter their security device into a physical reading device for the data to be read from it, and transmits the data to the recipient without the need for wired / cabled communication. The contactless authorization does, however, require the authorizing party (or at least their security device) to be in close proximity to the reading device.

[0123] • Payment terminal:

[0124] This term may be used synonymously with 'Point of Sale (POS) terminal', 'POS' or 'terminal', 'merchant device' or 'second party's device';

[0125] • User:

[0126] This term is intended to include a human individual or group of individuals, or a device, system or apparatus that is associated with, owned by and / or operated by the user;

[0127] • 'user device':

[0128] This term may be used synonymously with 'electronic device', 'consumer device', 'first party's computing resource', 'handset' or 'first party's device'. In a preferred embodiment it may comprise a mobile device such as a smart phone or tablet, and may comprise a touchscreen, sensors coupled to the touchscreen, and software for executing a virtual keypad on the user device in conjunction with the touchscreen and sensors. In other embodiments it may comprise a laptop or desktop PC coupled to a wired or physical or virtual keypad for input of data by the user.

[0129] • 'device':

[0130] this term is used herein to include any type of physical or virtual arrangement, andcan be used interchangeably with 'system', 'arrangement' or 'computing resource'. The device may comprise hardware and / or software components.

[0131] By way of summary, and without limitation, embodiments provide improved alternatives for performing secure electronic transaction. In accordance with the prior art approach of performing in-store transactions, the merchant's in-store POS system has an NFC reader connected to the terminal via a physical cable so that when the user provides their authorization data for the purchase it is sent from the NFC reader via the cable directly to the terminal's processing unit for secure processing.

[0132] However, in accordance with some embodiments of the disclosure, the user taps their payment card on their own device rather than the merchant's device, or uses the digital wallet on their own mobile device, because they are not physically present in the same location as the merchant. Therefore, the prior art use of a physical cable attached to the merchant's NFC reader in their PoS system is not a viable solution for situations where the user is not physically present in the same location as the merchant.

[0133] Embodiments of the disclosure involve the customer (user) tapping or otherwise presenting their card / token on their own device, or using a digital wallet on their phone / tablet etc., while not physically present in the merchant's store.

[0134] In one embodiment, the merchant terminal is in the cloud but in other embodiments the merchant could be using their mobile device (phone / tablet) as a PoS terminal as known in the prior art see, for example, mPOS solutions described at https: / / www.techtarget.com / searchcio / definition / mPOS-mobile-point-of-sale.

[0135] Therefore, in accordance with the disclosure and in contrast to the prior art approach, it is the NFC reader on the user's device (instead of the merchant's device) that captures the necessary data from the user's smart card. In effect, this creates a "virtual cable" that is a one-way, encrypted VPN channel established between the NFC reader on the user'sdevice and the NFC reader on the merchant's (cloud / mPOS) terminal. By doing this, any data that is received by the NFC reader at the merchant's device appears to the merchant device as if it has been provided locally by the user operating the merchant's POS device at the merchant's physical store, rather than remotely. An advantage of this is that the merchant and user do not need to be physically present, but the authorization of the user's transaction is secure. It also means that the authorization can be processed the same way as a "card present" transaction because the user is able to authenticate themselves (ie prove their identity) by entering their PIN or providing biometric data.

[0136] The (second) secure channel that is established between the user device's NFC reader and the merchant device's NFC reader is a one-way communication channel. Data can only travel from the user's end to the merchant's end. This channel only reads data at the user device's end and sends it to merchant device directly from the user device's NFC reader. The merchant's NFC reader is always read-only, so it cannot transmit data to other devices for security reasons. However, NFC readers in phones / tablets can read and write. Therefore, in accordance with embodiments of the disclosure, the second communication channel is configured as a one way tunnel when it is set up. When the second communication channel is set up, the user's phone is turned to 'read only' mode / configuration - in the same way that the merchant's payment terminal is, to prevent potential exploits by third parties. Thus, for security, the second channel connection is configured for 'read only' status at the merchant's end of the channel, so that the merchant's device cannot send any data back down the channel to the user's device In other words, at the point that the second channel is established from the NFC sensor on the user's device, the sensor is put into read only mode.

[0137] When the connection between the NFC readers is set up, the kernel that is provided on the merchant terminal (cloud or physically present) determines what needs to be read from the user's smart card. The data is not processed on the consumer's phone, it is read and then processed at the kernel level on the merchant's terminal after it has beenreceived via the second communication channel. The kernel specifies which data fields on the NFC are read.

[0138] As the data is being captured from the smart card at the user's device, it is encrypted by the secure, read-only tunnel (ie the second communication channel) and then sent via the tunnel to the kernel and decrypted at the kernel, processed as if received locally by the merchant terminal. The kernel on the terminal processes the data - kernel can be cloudbased or in a merchant's own device e.g. phone / tablet that is acting as a terminal (ie mPOS), as explained above.

[0139] ENUMERATED CLAUSES

[0140] Embodiments of the present disclosure are provided in the following enumerated clauses for the purpose of illustration, and without limitation. Any feature or clause provided below in respect of a particular clause or clause set is not intended to be thus limited and can be used in combination with one or more other clauses and / or clause sets.

[0141] Generally speaking, embodiments of the disclosure may provide systems and methods that are described using any one or more of the following wordings:

[0142] authorization methods / systems; security methods / systems; methods / systems for performing secure transactions via wireless communication channels.

[0143] Clause Set 1:

[0144] There may be provided:

[0145] Clause 1. A computer-implemented system for:

[0146] authorizing a first party by a second party prior to or as a pre-requisite to performing an operation; (the operation may comprise a transfer of data, providing access to a controlled resource, making a booking or reservation, or any other type of operation that requires authorization of at least one of the first / second parties); and / or

[0147] performing an authorization process, optionally wherein:

[0148] the authorization process is a contactless (payment) process, and / orthe process is performed during, prior to, or as a pre-requisite to a transfer operation conducted between a first party and a second party.

[0149] The computer-implemented system may comprise a second party device operative to:

[0150] i) establish a first secure communication channel with a first party device that is operative to obtain authorization data for the first party from a security token arrangement;

[0151] ii) send second secure channel data to the first party device over the first secure communication channel to establish a second secure communication channel with the first party device;

[0152] iii) receive the authorization data for the first party from the first party device via the second secure communication channel; and

[0153] iv) use the authorization data to attempt authorization of the first party and performing or not performing the operation based on the outcome of the attempted authorization.

[0154] The security token arrangement may be in the possession of, and or operated by, and / or used by the first party.

[0155] Clause 2. The system of Clause 1, wherein:

[0156] i) the security token arrangement comprises a physical or virtual device operative to store at least one item of authorization data and provide it to a wireless communication arrangement provided on or in association with the first party device, wherein the wireless communication arrangement is operative to send and / or receive data via a close proximity communication; and / or

[0157] ii) the first party device is arranged to obtain the authorization data from the security token arrangement via one or more of:

[0158] a wireless close-proximity communication;

[0159] a contactless communication arrangement;iii) the security token arrangement comprises one or more of: a data transmitter (such as an NFC tag); or a digital wallet arranged to store the authorization data;

[0160] iv) the second secure channel data comprises at least one encryption key for encrypting data that is to be transmitted over the second secure communication channel.

[0161] Clause 3. The system of Clause 1, wherein one or more of the following applies:

[0162] i) the security token arrangement comprises one or more of: a smart card, integrated circuit card, key fob, wearable device, digital wallet;

[0163] ii) the at least one item of authorization data comprises at least one credential for establishing the permission of the first party to use, access, process or interact with a controlled resource;

[0164] iii) the wireless close-proximity communication is a close-range wireless communication that comprises: a Near Field Communication (NFC), Radio Communication, shortwave communication, radio-frequency identification communication (RFID), Bluetooth communication, or an ultra-wideband (UWB) communication.

[0165] Clause 4. The system of any preceding Clause, wherein second party device is further operative to:

[0166] provide and / or activate an authorization data capture component on the first party device, and wherein the authorization data capture component is operative to receive the authorization data obtained from the security token arrangement and transmit it to the second party via the second secure communication channel.

[0167] Clause 5. The system of any preceding Clause, wherein the first party device comprises:

[0168] i) a mobile, handheld wearable or portable computing device, a smart phone, a laptop, or a PC; andii) at least one component operative to send and / or receive data via a wireless close-proximity communication.

[0169] Clause 6. The system of any preceding Clause, wherein the second party device comprises:

[0170] a cloud-based computing resource and / or a physical or virtual Point-of-Sale terminal.

[0171] Clause 7. The system of any preceding Clause, wherein:

[0172] the first and / or second secure communication channel is established by performing a cryptographic handshake.

[0173] Clause 8. The system of any preceding Clause, wherein:

[0174] the second party device is operative to receive, from the first party device, authentication data for authenticating the first party.

[0175] Clause 9. The system of Clause 8, wherein:

[0176] i) the authentication data is provided to the second party by the first party via the first secure communication channel; and / or

[0177] ii) the authentication data is obtained from the first party at or on the first party device; and / or

[0178] iii) the authentication data comprises one or more of a PIN, a secret identifier or code, a password, a secret phrase, biometric data, voice-related data, photographic or video data, or any other data suitable for establishing the identity of the first party.

[0179] Clause 10. The system of any preceding clause, wherein:

[0180] the second secure communication channel is established between a first wireless data reader provided on or at the first party device and a second wireless data reader provided on or at the second party device;preferably wherein the first and / or second wireless data reader comprises a nearfield communication (NFC) reader.

[0181] Advantageously, the establishment of a secure connection between the NFC reader of the user's device and the NFC reader of the merchant device allows the data to be received at the merchant's device as if it had been captured locally by the PoS Terminal's NFC reader. This means that the data received at the PoS terminal is indistinguishable to the kernel provided on the terminal from data that has been captured locally from the customer's card, as if the customer were present at the same location as the terminal.

[0182] Clause 11. A computer-implemented method for authorizing a first party by a second party prior to performing an operation, the method comprising:

[0183] i) establishing a first secure communication channel between a second party device and a first party device;

[0184] ii) using the first secure communication channel to transmit second secure channel data to the first party device to establish a second secure communication channel between the second party device and an authorization data capture component provided on the first party device;

[0185] iii) receiving authorization data by the second party device across the second secure communication channel from the authorization data capture component on the first party device, wherein the authorization data is obtained by the authorization data capture component from:

[0186] - a wireless communication arrangement provided on or in association with the first party device and operative to read the authorisation data from a security token arrangement via a wireless closeproximity communication; or

[0187] - a digital wallet associated with the first party device and operative to store the authorisation data and provide it to a wirelesscommunication arrangement provided on or in association with the first party device;

[0188] iv) using the authorization data, at the second party device, to attempt authorization of the first party and performing or not performing the operation based on the outcome of the attempted authorization.

[0189] Clause 12. The method of Clause 11, and further comprising:

[0190] receiving, at the second party device and from the first party device, authentication data for authenticating the first party, preferably wherein the authentication data is received by the second party from the first party via the first secure communication channel.

[0191] Clause 13. The method of Clause 12, wherein:

[0192] ii) the authentication data is obtained from the first party at or on the first party device; and / or

[0193] iii) the authentication data comprises one or more of a PIN, a secret identifier or code, a password, a secret phrase, biometric data, voice-related data, photographic or video data, or any other data suitable for establishing the identity of the first party.

[0194] Clause 14. The method of Clauses 11 to 13 wherein:

[0195] the first party device comprises a mobile, portable or handheld device that comprises a wireless close-proximity communications arrangement and / or a digital wallet comprising one or more digital security tokens; and

[0196] the second party device comprises a physical or virtual Point-of-Sale device.

[0197] Clause 15. A computer-implemented apparatus comprising one or a plurality of computer-implemented resources, wherein each of the one or plurality of computer-implemented resources comprises:

[0198] at least one processor; andmemory including executable instructions that, as a result of execution by the at least one processor, causes the apparatus to perform the computer-implemented method of any of clauses 11 to 14 or any embodiment of a method disclosed herein.

[0199] Clause 16. A non-transitory computer-readable storage medium having stored thereon executable instructions that, as a result of being executed by at least one processor of a computer system comprising one or more computers, cause the computer system to perform the computer-implemented method of any one of clauses 11 to 14 or any embodiment of a method disclosed herein.

[0200] Clause set 2:

[0201] There may be provided: an authorization method; a contactless authorization method; a method for authorizing a party prior to permitting access to a controlled resource; and / or a method of authorizing a first party that is attempting to perform an operation in collaboration with a second party, the first party and the second party having first and second devices respectively. The operation may comprise the transfer of at last one asset, or transfer of ownership of at least one asset; or providing access to a controlled resource; or sending data or an electronic communication from a source to a recipient.

[0202] The method may comprise any feature(s) as disclosed in the clauses of this clause set and / or in combination with the feature(s) described above or in clause set 3.

[0203] Clause 2.1 the method may comprise:

[0204] i) establishing a secure communications channel with a physical or virtual wireless communications device provided on or at a first party's device; (preferably, the wireless communications device comprises a close- proximity / near-field communications device)

[0205] ii) using the secure communications channel to:receive authentication and / or authorization data by a second party's device and from the physical or virtual wireless communications device; or

[0206] send authentication and / or authorization data from the physical or virtual wireless communications device to the second party's device; wherein:

[0207] the authentication and / or authorization data is obtained by the physical or virtual wireless communications device from a security token arrangement via a data reading arrangement provided on or at the first party's device, and the data reading arrangement comprises a physical close-proximity communications device or a digital wallet.

[0208] Embodiment(s) disclosed herein may be implemented using a computer implemented system. The system may be arranged and / or operative to perform any method step or combination of method steps described, illustrated and / or claimed herein.

[0209] Embodiment(s) disclosed herein may be implemented using at least one item of computer-implemented apparatus. The apparatus may be referred to as a system. The computer-implemented apparatus may comprise one or a plurality of computer-implemented resources (e.g. network, node, device, terminal, input / output device, communications technologies, storage resources etc). The computer-implemented apparatus may comprise, hardware, firmware and / or software arranged to execute on the hardware and / or firmware. At least some of the resources may be operative for transmission and / or receipt of electronic data. The at least one computer-implemented apparatus may comprise:

[0210] at least one processor; and

[0211] memory including executable instructions that, as a result of execution by the at least one processor, causes the system / apparatus to perform any variation of a computer-implemented method claimed, illustrated or described herein.Embodiment(s) disclosed herein may provide at least one non-transitory computer-readable storage medium having stored thereon executable instructions that, as a result of being executed by at least one processor of at least one computer system, cause the computer system(s) to perform any embodiment of a method claimed, illustrated or described herein.

[0212] Clause set 3:

[0213] There may be provided: A system, comprising:

[0214] a merchant computing device, including:

[0215] a transaction processor configured to:

[0216] determine a candidate transaction; and

[0217] transmit a payment request for the candidate transaction, and a first wireless communications reader configured to receive payment information from a first payment card in (direct) wireless communications with the first wireless communications reader; and

[0218] a user device including a second wireless communications reader, the user device being configured to:

[0219] create a first encrypted channel to enable secure communications between the user device and the transaction processor,

[0220] receive, using the first encrypted channel, the payment request for the candidate transaction from the transaction processor,

[0221] responsive to receive the payment request, cause the second wireless communications reader to create a second encrypted channel to enable secure communications between second wireless communications reader and the first wireless communications reader,

[0222] read, using at last one wireless communication, payment information from a second payment card in (direct) wireless communication with the second wireless communications reader, and

[0223] transmit, using the second encrypted channel, the payment information to the first wireless communications reader.The merchant may also be referred to as a "second party". The merchant device may be described as one or more of: "a cloud based PoS Terminal", "a point-of-sale (PoS) terminal", "a second party computing device", "an automated teller machine (ATM)", "a handheld computing device", or "a handset".

[0224] The candidate transaction may be a transaction for payment for goods and services. The payment information may also be referred to as "transaction data", and may comprise data including, but not limited to, one or more of:

[0225] operational data or attributes relating to a transaction between the first and second parties (ie the customer and the merchant) such as the transaction amount, date / time of the transaction, first / second party's name or identifier etc;

[0226] authorization data relating to, or provided a payment or security device that attests to the first party's authorization to make the transaction e.g. a physical or virtual (ie digital) payment card;

[0227] data relating to the goods / services being exchanged between the parties in return for the payment.

[0228] The system may comprise a computer-implemented system. In an embodiment, the wireless communication may be, or comprise, a near-field communication. Additionally, or alternatively, the first and / or second wireless communications reader may be, or comprise, a near-field communications reader.

[0229] In an embodiment, the first wireless / near-field communications reader or another (different) component of the merchant point-of-sale terminal computing device may be configured to, upon receipt of the payment information, validate the payment information. If the payment information is validated, the first wireless / near-field communications reader or the other component of the merchant point-of-sale computing device is configured to transmit an indication that the payment information is valid to thetransaction processor. The transaction processor is configured to, after receiving the indication that the payment information is valid, complete the candidate transaction for goods and / or services.

[0230] The first encrypted channel and the second encrypted channel may be established using different encryption keys. In an embodiment, an encryption key used to create the second encrypted channel is known only to at least one of the first wireless / near-field communications reader and the second wireless / near-field communications reader.

[0231] ILLUSTRATIVE COMPUTING ENVIRONMENT

[0232] Turning now to Figure 4, there is provided an illustrative, simplified block diagram of a computing device 2600 that may be used to practice at least one embodiment of the present disclosure. In various embodiments, the computing device 2600 may be used to implement any of the systems illustrated and described above. In some embodiments, computing device 2600 may be a standalone device, or may form part of system. Computing device 2600 may take any form and configuration suitable for its use in accordance with an embodiment of the disclosure, including one or more of: a portable, mobile or handheld computing device, a smart phone, tablet computer, a workstation, server, node on a network or any other device described herein. It may be a node on a network, and / or form part of a wider computing system comprised of interconnected devices arranged for electronic communication with one another. Thus, the hardware and / or software of computing device 2600 may take any suitable known form to enable a chosen embodiment to be implemented on it. As shown in Figure 4, the computing device 2600 may include one or more processors with one or more levels of cache memory and a memory controller (collectively labelled 2602) that can be configured to communicate with a storage subsystem 2606 that includes main memory 2608 and persistent storage 2610. The main memory 2608 can include dynamic random-access memory (DRAM) 2618 and read-only memory (ROM) 2620 as shown. The storage subsystem 2606 and the cache memory 2602 and may be used for storage of information, such as details associated with transactions and blocks as described in the present disclosure. Theprocessor(s) 2602 may be utilized to provide the steps or functionality of any embodiment as described in the present disclosure.

[0233] The processor(s) 2602 can also communicate with one or more user interface input devices 2612, one or more user interface output devices 2614, and a network interface subsystem 2616.

[0234] A bus subsystem 2604 may provide a mechanism for enabling the various components and subsystems of computing device 2600 to communicate with each other as intended. Although the bus subsystem 2604 is shown schematically as a single bus, alternative embodiments of the bus subsystem may utilize multiple busses.

[0235] The network interface subsystem 2616 may provide an interface to other computing devices and networks. The network interface subsystem 2616 may serve as an interface for receiving data from, and transmitting data to, other systems from the computing device 2600. For example, the network interface subsystem 2616 may enable a data technician / user / operative to connect the device to a network such that the data technician may be able to transmit data to the device and receive data from the device while in a remote location, such as a data centre. The device may comprise telecommunications capabilities.

[0236] The user interface input devices 2612 may include one or more user input devices such as a keyboard; pointing devices such as an integrated mouse, trackball, touchpad, or graphics tablet; a scanner; a barcode scanner; a card reader e.g. for reading data from a smart card; a QR code reading arrangement; at least one camera; a touch screen incorporated into the display; audio input devices such as voice recognition systems, microphones; and other types of input devices. The device may comprise one or more hardware / software components for capture of biometric data from a user. In general, use of the term "input device" is intended to include all possible types of devices and mechanisms for inputting information to the computing device 2600. The device 2600 may comprise a touchscreen and sensors coupled with the touchscreen to detect contact with the surface of the touchscreen and generate a signal in response to the contact. The signal may be processed to determine the location of the contact on the touchscreen.Data derived from the signal may be used by software installed for execution on the device and arranged to provide the functionality of a virtual keypad / keypad / keyboard. The one or more user interface output devices 2614 may include a display subsystem, a printer, or non-visual displays such as audio output devices, etc. The display subsystem may be a cathode ray tube (CRT), a flat-panel device such as a liquid crystal display (LCD), light emitting diode (LED) display, or a projection or other display device. In general, use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from the computing device 2600. The one or more user interface output devices 2614 may be used, for example, to present user interfaces to facilitate user interaction with applications performing processes described and variations therein, when such interaction may be appropriate.

[0237] The storage subsystem 2606 may provide a computer-readable storage medium for storing the basic programming (machine executable logic and instructions) and data constructs that may provide the functionality of at least one embodiment of the present disclosure. Applications embodying the disclosure (programs, code modules, instructions), when executed by one or more processors, may provide the functionality of one or more embodiments of the present disclosure, and may be stored in the storage subsystem 2606. These application modules or instructions may be executed by the one or more processors 2602. The storage subsystem 2606 may additionally provide a repository for storing data used in accordance with the present disclosure. In some embodiments, for example, the main memory 2608 and cache memory 2602 can provide volatile storage for program and data. The persistent storage 2610 can provide persistent (non-volatile) storage for program and data and may include (for example only and without limitation) flash memory, memory card(s) or stick(s), network-attached storage (NAS) device one or more solid state drives, one or more magnetic hard disk drives, one or more disk drives with associated removable media, one or more optical drives (e.g. CD-ROM or DVD or Blue-Ray) drive with associated removable media, and other like storage media. Such program and data can include programs for carrying out the steps of one or more embodiments as described in the present disclosure as well as data associated with transactions and blocks as described in the present disclosure. The computing devicemay also comprise or be arranged for communication with at least one area of secure memory designed to facilitate the storage and processing of sensitive data. This secure memory may comprise one or more of: a secure element, Trusted Execution Environment (TEE), Trusted User Interface (TUI), secure enclave etc. The secure memory may be used to perform or provide, at least in part, one or more of the method steps or system functionalities disclosed herein.

[0238] Additionally, or alternatively, computing device 2600 may comprise hardware and / or software to enable it to communicate with remote or virtual storage resources such as (for example and without limitation) cloud-based storage facilities or storage devices that are located separately from the computing device 2600.

[0239] Additionally, the computing device 2600 may include software and / or hardware for connection of the computing device 2600 to at least one other device via wireless means such as Bluetooth, NFC or other wireless communication protocols or techniques.

[0240] Additionally, or alternatively, the computing device 2600 may include at least one other device that may be connected to the computing device 2600 through one or more ports (e.g., USB, a headphone jack, Lightning connector, HDMI, Ethernet port, Serial port, PS2 pinout, parallel port etc.). The device that may be connected to the computing device 2600 may include a plurality of ports configured to accept fibre-optic connectors.

[0241] Accordingly, this device may be configured to convert optical signals to electrical signals that may be transmitted through the port connecting the device to the computing device 2600 for processing. Due to the ever-changing nature of computers and networks, the description of the computing device 2600 depicted in Figure 4 is intended only as a specific example for purposes of illustrating a possible embodiment of the device. Many other configurations having more or fewer components than the system depicted in Figure 4 are possible.

[0242] In preferred embodiments of the present disclosure, the first party's device (e.g. phone) and / or second party's device (e.g., POS terminal) may comprise a wireless communications arrangement that may also be referred to as a wireless communications component. The wireless communications component may comprise hardware and / orsoftware components which are arranged to enable the device to conduct close proximity communications such as radio communications, RFID communications, Near Field Communications (NFCs), Bluetooth communications etc with other such enabled devices that are in close physical proximity. NFC communications and the technologies that implement NFC protocols are known in the art such as, for example, as disclosed at: https: / / en.wikipedia.org / wiki / Near-field_communication. As the skilled person will readily understand, the term 'reader' is known as meaning a device or embedded component which is operative to communicate with a passive or active transmitting device such as a tag or chip that is in close proximity and read data from it. The term reader is typically used in the art to mean a device that can send as well as receive data wirelessly. The tag or microchip may be embedded within a device and typically comprises a unique identifier, storage for (potentially tokenised) data, a chip coupled to an antenna. The terms 'smart tag', 'RFID tag' or 'info tag' may be used as alternatives to 'NFC tag'. Examples of active NFC devices known in the art include mobile wallets implemented on smartphones, having the ability to both send (transmit) and receive (read) data.

[0243] The second party's device may comprise an access control arrangement substantially as disclosed in any embodiment disclosed in the art at: https: / / en.wikipedia.Org / wiki / Access_control#Electronic_access_control.

[0244] It should be noted that the above-mentioned embodiments illustrate rather than limit the disclosure, and that those skilled in the art will be capable of designing many alternative embodiments without departing from the scope of the disclosure as defined by the appended claims. In the claims, any reference signs placed in parentheses shall not be construed as limiting the claims. The word "comprising" and "comprises", and the like, does not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. In the present specification, "comprises" means "includes or consists of" and "comprising" means "including or consisting of". Throughout this specification the word "comprise", or variations such as "includes", "comprises" or"comprising", will be understood to imply the inclusion of a stated element, integer or step, or group of elements, integers or steps, but not the exclusion of any other element, integer or step, or group of elements, integers or steps. The singular reference of an element does not exclude the plural reference of such elements and vice-versa. The disclosure may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In a device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

[0245] Disclaimer

[0246] All references cited herein are incorporated by reference to the maximum extent allowable by law. Any incorporation by reference of documents above is limited such that no subject matter is incorporated that is contrary to the explicit disclosure herein. Any incorporation by reference of documents above is further limited such that no claims included in the documents are incorporated by reference herein. Any incorporation by reference of documents above is yet further limited such that any definitions or terminology provided in the documents are not incorporated by reference herein unless expressly included herein.

Claims

CLAIMS:

1. A system for authorizing a first party, by a second party, prior to performing an operation, the system comprising a second party device operative to:i) establish a first secure communication channel with a first party device that is operative to obtain authorization data for the first party from a security token arrangement;ii) send second secure channel data to the first party device over the first secure communication channel to establish a second secure communication channel with the first party device;iii) receive the authorization data for the first party from the first party device via the second secure communication channel; andiv) use the authorization data to attempt authorization of the first party, and perform or not perform the operation based on the outcome of the attempted authorization.

2. The system of claim 1, wherein:i) the security token arrangement comprises a physical or virtual device operative to store at least one item of authorization data and provide it to a wireless communication arrangement provided on or in association with the first party device, wherein the wireless communication arrangement is operative to send and / or receive data via a close proximity communication; and / orii) the first party device is arranged to obtain the authorization data from the security token arrangement via one or more of:a wireless close-proximity communication;a contactless communication arrangement;iii) the security token arrangement comprises one or more of: a data transmitter; or a digital wallet arranged to store the authorization data;iv) the second secure channel data comprises at least one encryption key for encrypting data to be transmitted over the second secure communication channel;v) the operation is a contactless payment.

3. The system of claim 1, wherein one or more of the following applies:i) the security token arrangement comprises at least one of: a smart card, integrated circuit card, key fob, wearable device, digital wallet;ii) the at least one item of authorization data comprises at least one credential for establishing the permission of the first party to use, access, process or interact with a controlled resource;iii) the wireless close-proximity communication is a close-range wireless communication that comprises a Near Field Communication (NFC), Radio Communication, shortwave communication, radio-frequency identification communication (RFID), Bluetooth communication, or an ultra-wideband (UWB) communication.

4. The system of any preceding claim, wherein the second party device is further operative to:provide and / or activate an authorization data capture component on the first party device, and wherein the authorization data capture component is operative to receive the authorization data obtained from the security token arrangement and transmit it to the second party via the second secure communication channel.

5. The system of any preceding claim, wherein the first party device comprises:i) a mobile, handheld wearable or portable computing device, a smart phone, a laptop, or a PC; and / orii) at least one component operative to send and / or receive data via a wireless close-proximity communication.

6. The system of any preceding claim, wherein the second party device comprises one or more of: a cloud-based computing resource, a physical Point-of-Sale terminal, a cloud-based Point-of-Sale terminal or virtual Point-of-Sale terminal.

7. The system of any preceding claim, wherein: the first and / or second secure communication channel is established by performing a cryptographic handshake.

8. The system of any preceding claim, wherein:the second party device is operative to receive, from the first party device: authentication data for authenticating the identity of the first party; and / or confirmation that the identity of the first party has been successfully authenticated using authentication data.

9. The system of claim 8, wherein:i) the authentication data is provided to the second party by the first party via the first secure communication channel; and / orii) the authentication data is obtained from the first party at or on the first party device; and / oriii) the authentication data comprises one or more of a PIN, a secret identifier or code, a password, a secret phrase, biometric data, voice-related data, photographic or video data, or any other data suitable for establishing the identity of the first party.

10. The system of any preceding claim, wherein:the second secure communication channel is established between a first wireless data reader provided on or at the first party device and a second wireless data reader provided on or at the second party device;preferably wherein the first and / or second wireless data reader comprises a nearfield communication (NFC) reader.

11. A computer-implemented method for authorizing a first party by a second party prior to performing an operation, the method comprising:i) establishing a first secure communication channel between a second party device and a first party device;ii) using the first secure communication channel to transmit second secure channel data to the first party device to establish a second secure communication channel between the second party device and an authorization data capture component provided on the first party device;iii) receiving authorization data by the second party device across the second secure communication channel from the authorization data capture component on the first party device, wherein the authorization data is obtained by the authorization data capture component from:- a wireless communication arrangement provided on or in association with the first party device and operative to read the authorisation data from a security token arrangement via a wireless closeproximity communication; or- a digital wallet associated with the first party device and operative to store the authorisation data and provide it to a wireless communication arrangement provided on or in association with the first party device;iv) using the authorization data, at the second party device, to attempt authorization of the first party and performing or not performing the operation based on the outcome of the attempted authorization.

12. The method of claim 11, and further comprising:receiving, at the second party device and from the first party device, authentication data for authenticating the first party, preferably wherein the authentication data is received by the second party from the first party via the first secure communication channel.

13. The method of claim 12, wherein:i) the operation is a contactless payment; and / orii) the authentication data is obtained from the first party at or on the first party device; and / oriii) the authentication data comprises one or more of a PIN, a secret identifier or code, a password, a secret phrase, biometric data, voice-related data, photographic or video data, or any other data suitable for establishing the identity of the first party.

14. The method of claims 11 to 13 wherein:the first party device comprises a mobile, portable or handheld device that comprises a wireless close-proximity communications arrangement and / or a digital wallet comprising one or more digital security tokens; andthe second party device comprises a physical or virtual Point-of-Sale device.

15. A method of authorizing a first party that is attempting to perform an operation in collaboration with a second party, the first party and the second party having first and second devices respectively, the method comprising:i) establishing a secure communications channel with a physical or virtual wireless close-proximity communications device provided on or at the first party's device;ii) using the secure communications channel to:receive authorization data by the second party's device and from the physical or virtual close-proximity communications device; orsend authorization data from the physical or virtual close-proximity communications device to the second party's device;wherein:the authorization data is obtained by the virtual close-proximity communications device from a security token arrangement via a data reading arrangement provided on or at the first party's device, andthe data reading arrangement comprises a physical close-proximity communications device or a digital wallet.

16. A computer-implemented apparatus comprising one or a plurality of computer-implemented resources, wherein each of the one or plurality of computer-implemented resources comprises:at least one processor; andmemory including executable instructions that, as a result of execution by the at least one processor, causes the apparatus to perform the computer-implemented method of any of claims 11 to 14 or any embodiment of a method disclosed herein.

17. A non-transitory computer-readable storage medium having stored thereon executable instructions that, as a result of being executed by at least one processor of a computer system comprising one or more computers, cause the computer system to perform the computer-implemented method of any one of claims 11 to 14 or any embodiment of a method disclosed herein.

Images