Patent Description:
Technical developments are ongoing in the electronic payments industry to implement payment form factors that increase protection against various forms of fraud. In this context, the three main card schemes Europay, Mastercard and Visa ('EMV') created the original EMV technical standard for payment cards, which is now managed by EMVCo and aspects of which are based upon ISO/IEC <NUM> for contact cards and ISO/IEC <NUM> for contactless cards.

Payment cards complying to the EMV standard are variously known as smart cards, chip cards and IC cards and store data on integrated circuits rather than magnetically on a stripe. EMV cards were originally contact cards insertable into readers interfacing a point of sale ('PoS') terminal or automated teller machine ('ATM') with the card chip, and are increasingly being replaced with contactless cards that can be read by a PoS or ATM over a short distance using radio-frequency identification ('RFID') technology.

EMV cards provide substantial protection for card-present transactions, i.e. those transaction conducted between a cardholder and a merchant at a till or the like and wherein the card is physically interfaced with a PoS, but there remains a need to minimise unauthorised use of cardholder account data and to reduce fraud opportunities for card-not-present transactions, typically those conducted over the phone or the Internet, and emerging transaction environments which combine elements of card-present and card-not-present transactions, such as contactless transactions at a retail location.

A recent development path that shows promise for solving the above issue is payment tokenisation systems. In most of these systems, a payment token is implemented as a surrogate replacing the number uniquely identifying a payment card within electronic payment networks, which is known as the Primary Account Number (PAN) of the card. Accordingly, it is known to use payment tokens in Cardholder Verification Methods (CVMs), including signature, online and offline PIN, and outside CVMs. For example, if an online PIN is used with a payment token, in accordance to ISO <NUM>-<NUM> PIN Block Format <NUM> or Format <NUM>, the PIN block would include the payment token in lieu of the card's PAN. In this context, token service providers are responsible for ensuring that the issuer of the payment card receives the PIN block with the PAN or payment token, as appropriate, for validation.

In these systems, a process must be followed to ensure that the payment token is replacing a PAN which is legitimately being used by the token requestor. This process is known as Identification and Verification (ID&V) and is performed each time a payment token is requested. Different types of ID&V may be performed, resulting in corresponding levels of token assurance, wherein no or minimal ID&V performed would result in a low assurance payment token, but a high level of ID&V would result in a high assurance payment token. <CIT> discloses a system for providing, along with a token, a token assurance level and data used to generate the token assurance level. At the time a token is issued, Identification and Verification (ID&V) methods may be performed to ensure that the token is replacing a PAN that was legitimately used by a token requestor.

Higher levels of ID&V rely on multifactor authentication techniques, typically <NUM> factors currently and, in that context, the three domain ('3D') Secure authentication protocol first deployed by Visa under the name 'Verified by Visa' and since adopted by other Card Schemes such as MasterCard and its MasterCard SecureCode, can be used as one of the two factors. A fundamental requirement of the <NUM>-D Secure protocol is the enrolment of a payment card in the service prior to the successful completion of an authenticated transaction. This can be implemented as a stand-alone process or integrated with an online retail event, and its purpose is both to validate the identity of the cardholder prior to use of the payment card and to assign a means of authentication to that card. The cardholder is presented with a user interface, typically a succession of at least two secure browser pages, before the enrolment process is complete and a transaction can be completed. However, the card industry reports that as many as <NUM> percent of users opt out of <NUM>-D Secure participation when first presented by the user interface, and an additional <NUM> percent close the activation window altogether. Each cardholder opting out of <NUM>-D Secure when prompted to enrol, is an example of a cardholder being inconvenienced by the enrolment-based system, eventually leading to dissatisfaction and abandonment of purchases by legitimate consumers.

Accordingly, there is a clear requirement for improving multifactor authentication of a payment card during the distributed processing of an electronic transaction.

The present invention mitigates the ergonomic deficiencies and other grounds of user unfriendliness inherent to the prior art techniques, that currently result in user reticence to ID&V enrolment, by pairing a personal computing device of a user or cardholder, for instance a user's cardholder's mobile telephone handset, with a payment card of the cardholder or user account information, without storing the Primary Account Number ('PAN') of the payment card, by tokenising the payment card or user account information with a high level of ID&V, that is assured through a security protocol. It will be appreciated different payment platforms other than EMV based can also be employed to implement the present invention. In the context of the present invention the method and system can be used effectively for online transactions or where a transaction is happening at a physical merchant terminal.

According to an aspect of the present invention therefore, there is provided a method of associating a payment card of a cardholder with a personal computing device of the cardholder in an electronic payment network, as set out in the appended claims. The method comprises the steps of providing the cardholder with the card and a device activation code for the personal computing device, wherein the card has a number uniquely identifying the card in the electronic payment network ; communicating the card number and the device activation code from the personal computing device to a first remote server ; at the first remote server, obtaining an issuer assured card token based on both the card number and the device activation code from a second remote server ; generating a device token and an authorisation token at the first remote server ; storing the card token, device token and authorisation tokens in a data structure at the first remote server ; and communicating the card token and device token to the personal computing device and storing same thereat. It will be appreciated that the functions carried out by the first and second server can be carried out on a single server or a plurality of servers depending on the implementation required.

This approach advantageously leverages the paired device as a first factor in a multifactor authentication solution and, further, obviating the requirement for the cardholder to interact with a security protocol, such as 3D Secure user interface or the like, at a later time during a transaction.

In an embodiment of the associating method, the step of obtaining the issuer assured card token or token may comprise the further steps of communicating the card number and the device activation code from the first remote server to the second remote server ; verifying the respective validities of the card number and the device activation code at the second remote server with an issuer of the card ; and generating the issuer assured card token in case of a positive verification at the second remote server.

The issuer assured card token may be an EMV issuer assured card token and, in this embodiment of the associating method, the step of verifying preferably comprises the further step of processing the card number and the device activation code with a 3D Secure protocol.

In an embodiment of the associating method, the card number is a primary account number (PAN) and the step of communicating the card number to the first remote server may comprise the further step of inputting the PAN in the personal computing device through a near field communication (NFC). In an embodiment the step of inputting the PAN in the personal computing device can be performed by manual means or optical means.

In an embodiment of the associating method, the method may comprise the further steps of communicating the card number and the device activation code from the first server to the personal computing device ; and the step of communicating the card token and the personal computing device token to the personal computing device comprises the further steps of communicating the card token and the personal computing device token for processing. The communication can use a Public-Key Infrastructure (TLS) or other encryption communication techniques. It will be appreciated that the personal computing device can take the function of a merchant terminal device.

In an embodiment of the associating method, the step of generating an authorisation token may comprise the further step of generating the authorisation token based on at least one selected from the card number, card data, an image or photograph of the card, cardholder data, cardholder biometric data, one or more cardholder physical feature(s), one or more cardholder's facial feature(s), a cardholder's iris, a cardholder's fingerprint(s), a cardholder's vocal features.

This approach advantageously builds further on the paired device leveraged as a first factor in a multifactor authentication solution, by using other hardware features and associated functionality of the paired device, particularly the wireless networking means and/or imaging means of the means, to provide at least a second authentication factor, and possibly more factors still depending on the degree of token assurance required by an implementation context.

According to another aspect of the present invention, there is also provided a method of authenticating a payment card of a cardholder for an electronic transaction processed in an electronic payment network, as set out in the appended claims.

An embodiment of the authenticating method may comprise the further step of updating the transaction token after authenticating the electronic transaction.

An embodiment of the authenticating method may comprise the further steps of encoding a network address of the merchant terminal in the transaction token ; and communicating a notification of authentication to the merchant terminal at the network address after authenticating the electronic transaction.

An embodiment of the authenticating method may comprise the further steps of generating a new device token after authenticating the electronic transaction ; and updating the stored device token at the first remote server and at the personal computing device with the new device token.

In an embodiment of the authenticating method, the step of inputting authenticating data in the personal computing device may comprise at least one selected from inputting card number or card data through a near field communication (NFC), capturing physical features of the card through optical capturing means of the device, capturing cardholder biometric data through the optical capturing means of the device, inputting cardholder vocal data through audio capturing means of the device.

In an embodiment of the authenticating method, the step of communicating the transaction token to the personal computing device may comprise the further steps of encoding the transaction token in a QR code and communicating the QR code. In an alternative embodiment the transaction token may be encoded in a user-selectable button for rendering in a browser application or other user interface. A particularly ergonomic embodiment of the user-selectable button may be an Intents button of the Android™ operating system.

According to a further aspect of the present invention, there is also provided a distributed electronic transaction processing system comprising at least first and second remote servers and at least one personal computing device of a payment card cardholder connected to a network, as set out in the appended claims.

Various embodiments of the system may be devised, wherein the cardholder device, the first remote server and the second remote server are each further configured to implement the various steps of the association and authentication methodologies introduced and described herein.

Accordingly, in an embodiment of the system, the second remote server may be further configured to verify the respective validities of the card number and the device activation code with an issuer of the card, and to generate the issuer assured card token in case of a positive verification.

In another embodiment of the system, the cardholder device preferably comprises wireless networking means, the card number is a primary account number (PAN) and the card number is input to the cardholder device through a near field communication (NFC).

In a further embodiment of the system, the cardholder device is preferably further configured to download a set of instructions from the first remote server for communicating the card number and the device activation code thereto, and the first remote server is further configured to communicate the card token and the device token to the set of instructions.

An embodiment of the system preferably comprises a merchant terminal connected to the network and configured to initiate an electronic transaction, wherein the first remote server is further configured to generate a transaction token associated with the electronic transaction, communicate the transaction token to the personal computing device, compare tokens received from the cardholder device against the stored card token, device token and authorisation token, and to authenticate the electronic transaction if the comparison returns a match; and the cardholder device is further configured to receive authenticating data, to generate an authorisation token based on the authenticating data and to communicate the stored card token, the stored cardholder device token, the generated authorisation token and the communicated transaction token to the first remote server.

In a variant of this embodiment, the first remote server may be further configured to update the transaction token after authenticating the electronic transaction.

In another variant of this embodiment, the first remote server may be further configured to encode a network address of the merchant terminal in the transaction token, and to communicate a notification of authentication to the merchant terminal at the network address after authenticating the electronic transaction.

In a further variant of this embodiment, the first remote server may be further configured to generate a new device token after authenticating the electronic transaction, and to update the stored device token at the first remote server and at the cardholder device with the new device token.

In any of the above variants, the cardholder device preferably comprises wireless networking means and imaging means, and both the cardholder device and the first remote server are further configured to generate the authorisation token based on at least one selected from the card number, card data, an image or photograph of the card, cardholder data, cardholder biometric data, one or more cardholder physical feature(s), one or more cardholder's facial feature(s), a cardholder's iris, a cardholder's fingerprint(s), a cardholder's vocal features.

In any of the above variants again, the first remote server may be further configured to encode the transaction token in a QR code and to communicate the QR code to the cardholder device. Alternatively, the transaction token may be encoded in a user-selectable button for rendering in a browser application or other user interface. The user-selectable button may for instance be embodied as an Intents button of the Android™ operating system.

For any of the above embodiments of the methods and system, the cardholder device is preferably selected from the group comprising: desktop computers, mobile telephone handsets, tablet computers, portable computers, personal digital assistants, portable media players, portable game consoles.

It will be appreciated that in the context of the present invention the use of the term 'token' should be afforded the widest possible interpretation and should include any digital token that can be used associated with a user and a user account information.

Other aspects of the invention are defined as set out in the appended claims.

The invention will be more clearly understood from the following description of an embodiment thereof, given by way of example only, with reference to the accompanying drawings, in which:-.

There will now be described by way of example a specific mode contemplated by the inventors. In the following description numerous specific details are set forth in order to provide a thorough understanding. It will be apparent however, to one skilled in the art, that the present invention may be practiced without limitation to these specific details. In other instances, well known methods and structures have not been described in detail so as not to unnecessarily obscure the description.

The words "comprises/comprising" and the words "having/including" when used herein with reference to the present invention are used to specify the presence of stated features, integers, steps or components but does not preclude the presence or addition of one or more other features, integers, steps, components or groups thereof.

Referring now to the figures and initially <FIG>, there is shown a network environment in which several data processing terminals <NUM>, <NUM>, <NUM>, <NUM> are connected to a Wide Area Network (WAN) <NUM>, in the example the Internet. Network connectivity and interoperable networking protocols of each terminal allow the terminals to connect to one another and communicate data to and receive data from one another according to the methodology described herein.

The data processing terminal <NUM> is a mobile personal communication device operated by the holder of one or more payment card(s) <NUM>. The cardholder device <NUM> emits and receives data, including voice and/or alphanumerical data, encoded as a digital signal over a wireless data transmission <NUM>, wherein the signal is relayed respectively to or from the device <NUM> by the geographically-closest communication link relay <NUM> of a plurality thereof. The plurality of communication link relays <NUM>N allows digital signals to be routed between mobile devices <NUM>N and their intended recipient by means of a remote gateway <NUM>. Gateway <NUM> is for instance a communication network switch, which couples digital signal traffic between wireless telecommunication networks, such as the network within which wireless data transmissions <NUM> take place, and the WAN <NUM>. The gateway <NUM> further provides protocol conversion if required, for instance if the device <NUM> uses a Wireless Application Protocol ('WAP') or Secure Hypertext Transfer Protocol ('HTTPS') to communicate data.

The data processing terminal <NUM> is a first server operated by an Access Control Service ('ACS') provider and is a personal computer device which emits and receives data encoded as a digital signal over a wired or wireless data transmission <NUM>, wherein said signal is relayed respectively to or from the computer <NUM> by a local router device <NUM> implementing a wired local network operating according to the IEEE <NUM>-<NUM> Gigabit Ethernet transmission protocol and/or a high-bandwidth wireless local network operating according to the IEEE <NUM> Wi-Fi wireless transmission protocol. The router <NUM> is itself connected to the WAN <NUM> via a conventional ADSL or optical fibre connection over a wired telecommunication network <NUM>.

The data processing terminal <NUM> is a second server operated by a card scheme such as Visa™, Mastercard™, JCB™, American Express™ or the like, and is again a personal computer device which emits and receives data encoded as a digital signal over a wired or wireless data transmission <NUM>, relayed respectively to or from the computer <NUM> by a local router device <NUM>, itself connected to the WAN <NUM> via a conventional ADSL or optical fibre connection over a wired telecommunication network <NUM>, as described hereinabove.

The data processing terminal <NUM> is a point-of-sale ('PoS') terminal operated by a merchant at a retail location, which emits and receives data encoded as a digital signal over a wireless data transmission <NUM> conforming to the IEEE <NUM> ('Wi-Fi') standard, wherein the signal is relayed respectively to or from the PoS terminal by a local router device <NUM> interfacing the PoS terminal <NUM> to the WAN communication network <NUM>. The PoS terminal <NUM> further comprises a High Frequency Radio Frequency Identification (RFID) networking interface implementing Near Field Communication (NFC) interoperability and data communication protocols for facilitating wireless data communication over a short distance with correspondingly-equipped devices such as the cardholder mobile phone <NUM> and an NFC-enabled payment card <NUM> of the cardholder. The PoS terminal <NUM> may for instance be a ViVOpay™ <NUM> contactless POS terminal manufactured by VIVOtech™ or an MX <NUM>™ series terminal manufactured by VeriFone™,.

A typical hardware architecture of the cardholder device <NUM> is shown in <FIG> in further detail, by way of non-limitative example. As skilled persons will readily understand, the hardware architecture of the PoS terminal <NUM> is substantially similar to that of the cardholder device <NUM> described hereafter, for purposes of ergonomic handling and miniaturisation. Skilled persons will also readily understand that the respective hardware architectures of the first and second servers <NUM>, <NUM> are also substantially similar to that of the cardholder device <NUM> and point of sale terminal <NUM>, albeit with components designed for durability and redundancy of operation, by contrast with the components of the mobile phone <NUM> and PoS <NUM> designed for improved portability.

The mobile phone <NUM> thus firstly includes a data processing unit <NUM>, for instance a general-purpose microprocessor, for instance conforming to the Cortex™ architecture manufactured by ARM™, acting as the main controller of the data processing terminal <NUM> and which is coupled with memory means <NUM>, comprising volatile random-access memory (RAM), non-volatile random-access memory (NVRAM) or a combination thereof.

The cardholder device <NUM> further includes networking means. Communication functionality in mobile phone <NUM> is provided by a modem <NUM>, which provides the interface to external communication systems, such as the GPRS, <NUM> or <NUM> cellular telephone network <NUM>, <NUM> shown in <FIG>, associated with or containing an analogue-to-digital converter <NUM>, which receives an analogue waveform signal through an aerial <NUM> from the communication link relay <NUM> and processes same into digital data with the data processing unit <NUM> or a dedicated signal processing unit. Alternative wireless communication functionality is provided by a wireless network interface card (WNIC) 206A interfacing the mobile phone <NUM> with the wireless local area network generated by a local wireless router <NUM>. Further alternative wireless communication functionality is provided by a High Frequency Radio Frequency Identification (RFID) networking interface 206B implementing Near Field Communication (NFC) interoperability and data communication protocols for facilitating wireless data communication over a short distance with correspondingly-equipped devices such as the PoS terminal <NUM> and the NFC-enabled payment card <NUM> of the cardholder.

The CPU <NUM>, NVRAM <NUM> and networking means <NUM> to 206B are connected by a data input/output bus <NUM>, over which they communicate and to which further components of each device <NUM>, <NUM> are similarly connected in order to provide wireless communication functionality and receive user interrupts, inputs and configuration data. Accordingly, user input may be received from a data input interface <NUM>, which for mobile phone <NUM> is a keypad with a limited number of multi-functional keys and/or a capacitive or resistive touch screen feature of the display unit <NUM>. Further input data may be received as analogue sound wave data by a microphone <NUM>, digital image data by a digital camera lens <NUM> and digital data via a Universal Serial Bus (USB) <NUM>. Processed data is output as one or both of display data output to the display unit <NUM> and audio data output to a speaker unit <NUM>.

Power is supplied to the above components by the electrical circuit <NUM> of devices <NUM>, <NUM>, which is interfaced with an internal battery module <NUM>, which itself may be recharged on an ad hoc basis by an electrical converter <NUM>.

In the distributed payment system of <FIG>, the cardholder device <NUM> and the first server <NUM> implement association and authentication methods for the or each payment card <NUM> of the cardholder. The associating method pairs the cardholder device <NUM> with the or each payment card <NUM> without storing the Primary Account Number ('PAN') of the payment card in either the cardholder device <NUM> or the remote server <NUM>. The pairing is implemented by tokenising a payment card <NUM> on the basis of a one-time code, for instance called a Device Active Code (DAC), that is uniquely associated with the card and representative of the cardholder device <NUM> at the time of the card-device association process. The tokenising process is performed by the remote server <NUM> and implements a high level ID&V method in association with the second remote server <NUM> of the card issuer or, more securely still, the card scheme that provided the PAN to the card issuer for issuing the card, wherein the second remote server <NUM> is able to process the card and one-time code data through the 3D Secure protocol and return an EMV issuer assured token to the first server <NUM> for subsequent use during instances of the payment card authenticating method.

Accordingly, with reference now to <FIG>, a logical diagram shows the contents of the memory means <NUM> of the cardholder device <NUM> at runtime, both when the terminal is configured for association with a card and when the terminal is configured for authenticating an associated payment card during an electronic transaction processed by the merchant device <NUM>.

An operating system is shown at <NUM> which, if the device <NUM> is for instance an iPhone® mobile phone handset or an iPad® tablet computer manufactured by Apple® Inc. of Sunnyvale, USA, is iOS® likewise distributed by Apple® Inc. or, if the device <NUM> is for instance an Galaxy® mobile phone handset manufactured by Samsung® Electronics Co. , Ltd of Suwon, Republic of Korea, is Android® distributed by Google® Inc.

The OS <NUM> includes communication subroutines <NUM> to configure the data processing terminal <NUM> for bilateral network communication via the modem <NUM> and both the NIC 206A and the NFC module 206B. The OS <NUM> also includes input subroutines <NUM> for reading and processing input data variously consisting of user direct input to the keypad <NUM> and to the touchscreen interface <NUM>, image data captured by the CCD <NUM> and audio data supplied by the Digital Analog Converter <NUM> after processing input from the microphone <NUM>.

A payment card application is shown at <NUM>, which configures the cardholder device <NUM> to perform data processing steps described hereafter with reference to <FIG>, which embody both the card payment associating and authenticating methods in the electronic payment network of <FIG> insofar as the cardholder device <NUM> is concerned. The application <NUM> is interfaced with the OS <NUM>, particularly the network communication and input data processing subroutines <NUM> and <NUM> of the OS <NUM>, via one or more suitable Application Programmer Interfaces <NUM>. Whenever the functionality of the payment card application <NUM> is called by a relevant cardholder input or an electronic stimuli (such as a transaction notification for authentication purposes as described hereafter) the payment card application <NUM> instantiates a user interface <NUM> on the display <NUM> to facilitate interaction with the cardholder.

The payment card application <NUM> can be downloaded to the device <NUM> from the first remote server <NUM> via a relevant remote repository server, for instance Apple's App Store™ or Google's Playstore™. In another embodiment an app can be downloaded directly from the likes of Apple's App Store™ or Google's Playstore™. Alternatively, in a preferred embodiment, the payment card application <NUM> is first downloaded directly from the first remote server <NUM> when the cardholder receives a device activation code <NUM> for a payment card <NUM> from their card issuer in a written communication or electronic message, for instance embodied as a <NUM>-digit PIN code.

The associating method initially requires the cardholder to both input the DAC <NUM> in the user interface <NUM> and the device <NUM> to read data <NUM> encoded in the payment card <NUM>, via an NFC communication performed by a physical tap of the card <NUM> against the device <NUM>. The card data <NUM> is communicated by the cardholder device <NUM> to the first remote server <NUM> for obtaining the token <NUM> which, when the associating method is completed remotely by the first remote server <NUM>, is eventually returned to the mobile application <NUM> for local storage, together with a unique cardholder device token <NUM> generated by the first remote server <NUM>.

The authenticating method is initiated at the cardholder device <NUM> by a transaction initialising code <NUM>, which is preferably embodied as a QR code if the transaction is conducted by the cardholder on a desktop computing device, and as an Intents button if the transaction is conducted by the cardholder on the device mobile <NUM>, wherein the transaction initialising code <NUM> is in all cases rendered by a browser application (not shown). The transaction initialising code <NUM> is processed by the OS subroutine <NUM> according to either a relevant selection input by the cardholder on the touch-sensitive display <NUM> if the code is an Intents button, or an imaging of the QR code on the desktop computer display with the cardholder device's CCD <NUM>, in either case resulting in a call to instantiate and process the payment card application <NUM> for purposes of authenticating the payment card <NUM> involved in the transaction and associated with the cardholder device <NUM>.

The instantiation of the payment card application <NUM> obtains a transaction token <NUM> associated with the ongoing electronic transaction from the instantiating transaction initialising code <NUM>. In this embodiment, the authenticating method at the cardholder device <NUM> again requires the device <NUM> to read data <NUM> encoded in the payment card <NUM> via an NFC communication performed by a physical tap of the card <NUM> against the device <NUM>, in order to generate an authorisation token <NUM>. Alternative embodiments contemplate generating the authorisation token <NUM> on the basis of data captured by the device CCD <NUM>, such as a photograph or video frame of either the payment card or physical cardholder biometric feature(s) including the cardholder's iris or fingerprint(s), and/or on the basis of data captured by the device microphone <NUM> such as a voiceprint of the cardholder, in all cases uniquely representative of the card <NUM> and cardholder.

The payment card application <NUM> includes a communications module <NUM> for communicating card and token data to, and receiving token data from, the first remote server <NUM> across the networked environment of <FIG>, wherein all such communications are encoded or decoded with a cryptographic subroutine <NUM> of the communications module <NUM> for purposes of data security. Outgoing encoded communications of the payment card application <NUM> will accordingly include the NFC card data <NUM> and DAC <NUM> when the card <NUM> and cardholder device <NUM> are being initially associated, and the card token <NUM>, device token <NUM>, transaction token <NUM> and the generated authorisation token <NUM> when the card <NUM> is being authenticated during an electronic transaction. Incoming encoded communications of the payment card application <NUM> will accordingly include the card token <NUM> and device token <NUM> upon association of the card <NUM> with the cardholder device <NUM>, and the transaction initialising code <NUM> and transaction token <NUM> associated with an ongoing electronic transaction.

Further local data <NUM> and network data <NUM> may be stored in the memory means <NUM> of the cardholder device <NUM> at runtime, some or all of which may be processed either by the application <NUM>, or by or for other application(s) <NUM> being processed in parallel with the application <NUM>. An example of further local data is for instance local user input <NUM> read by the OS <NUM> in real time from the hardware interface <NUM>, but which user input lies outside the user interface <NUM> of the application <NUM>. An example of further network data is for instance remote application or OS updating data <NUM> communicated by a remote server over the WAN <NUM>.

With reference now to <FIG> now, and by contrast with <FIG>, a logical diagram shows the contents of the memory means <NUM> of the first remote server <NUM> at runtime, when the data processing terminal is configured to both associate cardholder devices <NUM>N with cards <NUM>N and authenticate associated payment cards <NUM>N during electronic transactions processed by merchant devices <NUM>N in real-time.

An operating system is shown at <NUM> which, if the server <NUM> is for instance an desktop computing device manufactured by DELL® Inc. of Round Rock, Texas, USA, is Windows Server <NUM> R2 distributed by Microsoft® Inc. of Redmond, Washington, USA. The OS <NUM> includes communication subroutines <NUM> to configure the data processing terminal <NUM> for bilateral network communication via an NIC interfaced with the wired connection <NUM> to the local router <NUM>. The OS <NUM> also includes input subroutines <NUM> for reading and processing input data variously consisting of user direct input to human interface devices, namely a keyboard and a computer mouse.

A payment card server application is shown at <NUM>, which configures the server <NUM> to perform data processing steps described hereafter with reference to <FIG>, which embody both the card payment associating and authenticating methods in the electronic payment network of <FIG> insofar as the first server <NUM> is concerned. The application <NUM> is interfaced with the OS <NUM>, particularly the network communication and input data processing subroutines <NUM> and <NUM> of the OS <NUM>, via one or more suitable Application Programmer Interfaces <NUM>. Whilst the payment card server application <NUM> is processed by the first server <NUM> at runtime, the application instantiates a user interface <NUM> on a display unit connected to a video graphics output of the server for facilitating interaction with the server user.

The associating method is initiated and performed by the server application <NUM> for each association request received from a remote cardholder device <NUM> which includes both NFC card data <NUM> and a card-respective DAC <NUM>. The server application <NUM> decodes each such request, then communicates the DAC <NUM> and NFC card data <NUM> to the second remote server <NUM> configured and operated either by the issuer of the payment card <NUM>, or by the card scheme who has attributed the card PAN to the card issuer, for the second remote server <NUM> to perform a verification of the authenticity and validity of the payment card <NUM> based on the DAC <NUM> and card data <NUM> with a 3D Secure protocol and, in case of a positive verification, to return a token <NUM> uniquely representative of the verified card <NUM> and respective DAC <NUM> to the first server <NUM>.

Accordingly, the server application <NUM> maintains a database <NUM> of card-respective records, wherein each record is instantiated for a successful association, and stores the token <NUM>, together with both a cardholder device token <NUM> generated by the server <NUM> application to be uniquely representative of the requesting cardholder device <NUM> that initiated the association, and an authorisation token generated by the server <NUM> application on the basis of, in this embodiment, the card data <NUM> in the initial association request. Alternative embodiments contemplate generating the authorisation token <NUM> at the server <NUM> on the basis of data captured by the cardholder device CCD <NUM>, such as a photograph or video frame of either the payment card or physical cardholder biometric feature(s) including the cardholder's iris or fingerprint(s), and/or on the basis of data captured by the device microphone <NUM> such as a voiceprint of the cardholder, in all cases uniquely representative of the card <NUM> and cardholder, wherein this data is encoded in the association request in addition to the card data <NUM>. Accordingly still, a cardholder device <NUM> may be associated with a plurality of payment cards <NUM> of a same cardholder, each such association having a respective record in the database <NUM>.

The authenticating method is initiated at the first server <NUM> for each transaction initialising request received from a merchant terminal <NUM> connected to the electronic payment system of <FIG> whereby, for each transaction, the server application <NUM> initialises a respective transaction record and generates and stores a corresponding transaction token <NUM> uniquely associated with the transaction in the database <NUM>, then returns the transaction initialising code <NUM> to the merchant terminal <NUM> for output to the respective cardholder device <NUM> involved in the transaction.

The server application <NUM> accordingly also receives encoded communications from cardholder devices <NUM> involved in transactions for purposes of authenticating the payment card <NUM> involved therewith, wherein each such communication comprises a card token <NUM>, a device token <NUM>, the transaction token <NUM> and an authorisation token <NUM> generated by the sending mobile payment card application <NUM>. The server application <NUM> is thus able to reconcile transaction records in the database <NUM> based on the transaction token <NUM> communicated by a cardholder device <NUM>, and authenticate the payment card <NUM> based on a comparison of the co-communicated card token <NUM>, device token <NUM> and authorisation token <NUM> against the stored card-respective records in the database <NUM>.

The payment card application <NUM> thus also includes a communications module <NUM> for receiving card data <NUM> and DAC <NUM> from remote cardholder devices <NUM> and communicating same to the second remote server <NUM>, receiving EMV issuer assured card tokens from the second remote server <NUM>, communicating respective card tokens <NUM> and device tokens <NUM> to remote cardholder devices <NUM>, communicating transaction initialising codes <NUM> to merchant terminals <NUM>, receiving transaction-respective sets of tokens from remote cardholder devices <NUM> and communicating payment card authenticating outcomes to merchant terminals <NUM>, across the networked environment of <FIG>, wherein all such communications are encoded or decoded with a cryptographic subroutine <NUM> of the communications module <NUM> for purposes of data security.

Further local data <NUM> and network data <NUM> may be stored in the memory means <NUM> of the first remote server <NUM> at runtime, some or all of which may be processed either by the server application <NUM>, or by or for other application(s) <NUM> being processed in parallel with the server application <NUM>. An example of further local data is for instance local user input <NUM> read by the OS <NUM> in real time from the HiD devices, but which user input lies outside the user interface <NUM> of the application <NUM>. An example of further network data is for instance remote application or OS updating data <NUM> communicated by a remote server over the WAN <NUM>.

With reference to <FIG> now, after powering up a cardholder device <NUM> conventionally at step <NUM>, either the associating functionality or the authenticating functionality of the payment card application <NUM> may be called. The associating functionality is called whenever a cardholder wishes to associate a new payment card <NUM> with the mobile device <NUM>, having preferably received a card-respective device activation code <NUM> from the card issuer at step 502A. The payment card application <NUM> is accordingly started for the purpose at step <NUM> and, if the cardholder device <NUM> has never yet been associated with a payment card <NUM>, the payment card application <NUM> may also be first downloaded at said step <NUM>, and the user interface <NUM> is next instantiated on the device display <NUM> at step <NUM>.

A first question is accordingly asked at step <NUM>, asking to confirm that an association request should be sent for a payment card <NUM>. When answered positively, then at step <NUM> the mobile application <NUM> request the cardholder to locate the payment card <NUM> proximate the cardholder device <NUM> for performing a NFC communication therebetween and for the mobile application <NUM> to obtain the card data <NUM>. At a next step <NUM>, the mobile application <NUM> request the cardholder to input the device activation code <NUM> in the user interface <NUM>. At a next step <NUM>, the mobile application <NUM> encrypts and communicates the NFC card data <NUM> and the DAC <NUM> to the remote server application <NUM> processed by the first remote server <NUM>. At a final step <NUM>, the mobile application <NUM> eventually receives the card token <NUM> and the device token <NUM> generated on the basis of the communicated card data <NUM> and DAC <NUM> from the first remote server <NUM> and stores the pair of tokens locally. Control thereafter returns to the question of step <NUM>, allowing the mobile application <NUM> to start associating a next card <NUM> or, as described hereafter, to receive a transaction initiation code <NUM>. Alternatively, the cardholder may terminate the mobile application <NUM> with a relevant input in the UI <NUM> or the OS <NUM>, answering the question of step <NUM> positively.

The authenticating functionality is called whenever a cardholder initiates an electronic transaction with a payment card <NUM>N already associated with the cardholder device <NUM> at the first remote server <NUM> at step 502B. The payment card application <NUM> is accordingly started for the purpose at step <NUM> and the user interface <NUM> is next instantiated on the device display <NUM> at step <NUM>. The question of step <NUM> is answered negatively and a next question is accordingly asked at step <NUM>, asking to confirm that a transaction initiation code <NUM> has been received. When answered positively, then at step <NUM> the transaction initiation code <NUM> is processed to extract the transaction token <NUM>. At a next step <NUM>. the mobile application <NUM> request the cardholder to locate the payment card <NUM> proximate the cardholder device <NUM> for performing a NFC communication therebetween and for the mobile application <NUM> to obtain the card data <NUM>. At a next step <NUM>, the mobile application <NUM> generates the authorisation token <NUM> on the basis of the card data <NUM>. At a next step <NUM>, the mobile application <NUM> encrypts and communicates the stored card token <NUM>, the stored device token <NUM>, the extracted transaction token <NUM> and the locally-generated authorisation token <NUM> to the remote server application <NUM> processed by the first remote server <NUM>.

With reference to alternative embodiments wherein the authorisation token is generated based on data other than, or additional to, the card data <NUM> which requires and NFC 'tap' of the payment card106 with the cardholder device <NUM>, such an alternative embodiment is shown in dotted lines in <FIG> as alternatives steps <NUM>' and <NUM>' which may be performed as an alternative to, or in addition to, steps <NUM> and <NUM> previously described, and wherein the authenticating data input step <NUM>' requires the cardholder to scan their iris with the device CCD module <NUM> and the authenticating token generating step <NUM>' accordingly generates the authenticating token from the image data of the cardholder's iris rather than from card data <NUM>. Further, at an optional final step (not shown), the mobile application <NUM> may eventually receive a confirmation of authentication success or failure from the first remote server <NUM>. Control thereafter returns to the question of step <NUM>, allowing the mobile application <NUM> to start associating a next card <NUM> or to receive a next transaction initiation code <NUM>.

If the successive questions of steps <NUM> and <NUM> are successively answered negatively, a final question is asked at step <NUM>, as to whether the cardholder has input an mobile application closing command in the UI <NUM> or via the OS <NUM>. If the question of step <NUM> is answered negatively, then the application logic loops and control returns to the question of step <NUM>, allowing the mobile application <NUM> to start associating a next card <NUM> or to receive a next transaction initiation code <NUM>. Alternatively, the application <NUM> is unloaded from the memory <NUM> and the cardholder device <NUM> may eventually be switched off.

With reference to <FIG> now, after powering up the first server <NUM> at step <NUM>, the payment card server application <NUM> is loaded into the server memory and started locally at step <NUM>, together with its database, and a user interface <NUM> is instantiated on the display unit of the server <NUM> at step <NUM>. The server is then ready to process network communications to and from remote terminals consisting of cardholder devices 101N, remote merchant terminals <NUM> processing electronic payment card transactions, and the second remote server <NUM> of the card issuer or card scheme providing conventional 3DS processing of card data, for associating payment cards <NUM>N with respective cardholder devices <NUM>N and authenticating payment cards <NUM>N involved in electronic transactions TN.

The associating functionality is called whenever a cardholder device communication comprising NFC card data <NUM> and a respective DAC <NUM> encoded therein, preferably in encrypted form, is received at any one time at a step <NUM>. The authenticating functionality is called whenever a merchant terminal communication comprising card data <NUM>, or a representative portion thereof sufficient to identify the payment card <NUM>N in the database, is received at any one time at a step <NUM>. Communications are queued by the server application <NUM> and processed sequentially or in parallel, subject to the embodiment of the server application <NUM> taking advantage of the server central processing unit (CPU) architecture, particularly if it is a CPU with multiple, independently-addressable data processing cores.

A first question is accordingly asked at step <NUM>, as to whether the next communication to process is an association request. When answered positively, then at step <NUM> the server application <NUM> decrypts the communication to extract the card data <NUM> and DAC <NUM> and forward same to the second remote server <NUM> for performing a conventional 3DS verification on the data and issue a token <NUM>, which is either received at step <NUM> (normal case) or not if the 3DS verification fails. When the card token <NUM> is received, the server application <NUM> next generates a device token <NUM> at step <NUM>, which may be any form of tokenisation apt to uniquely identify the cardholder device <NUM> within the system of <FIG>.

At a next step <NUM>, the server application <NUM> generates an authorisation token <NUM> based on, in this embodiment, the received NFC card data <NUM>. With reference to the alternative, cardholder iris-based embodiment of steps <NUM>', <NUM>' in <FIG>, the server application may instead generate the authorisation token <NUM> based on image data of the cardholder iris, which the mobile application <NUM> must request from the cardholder in the association request procedure prior to step <NUM>.

At a next step <NUM>, the server application <NUM> stores the card token <NUM> received from the second remote server <NUM>, the device token generated at step <NUM> and the authorisation token generated at step <NUM> in a record of the database <NUM> which is, effectively, uniquely representative both of the payment card <NUM>N and its association with the cardholder device <NUM>. At a final step <NUM>, the server application <NUM> encrypts and sends the pair of card token <NUM> and device token <NUM> to the mobile application <NUM> at the remote cardholder device <NUM> for storing thereat.

Control thereafter returns to the question of step <NUM>, allowing the server application <NUM> to process a next association request from a remote cardholder device <NUM> or, as described hereafter, to process a next transaction call from a remote merchant terminal <NUM>. Accordingly, if the next communication to process is an authentication request, the first question of step <NUM> is answered negatively, and a next question is accordingly asked at step <NUM>, asking to confirm whether a next transaction call has been received. When answered positively, then at step <NUM> the server application <NUM> first generates a transaction token <NUM> for the transaction in a respective database record. At a next step <NUM>, the server application encodes the transaction token in a transaction initiation code <NUM> and communicates the code <NUM> to a remote browser application in use by the cardholder.

Adverting to steps <NUM> to <NUM> at the remote mobile application <NUM>, the server application eventually receives the encrypted card token <NUM>, device token <NUM>, transaction token <NUM> and generated authorisation token <NUM> from the remote mobile application <NUM> and decrypts the communication at step <NUM>. The server application <NUM> next sends the card token <NUM> to the second remote server for a conventional 3DS verification that the payment card <NUM> tokenized with the token <NUM> is still valid at step <NUM>. The second remote server <NUM> ordinarily returns a positive verification whereby, at step <NUM>, the server application <NUM> next attempts to match the card token <NUM>, device token <NUM> and authorisation token <NUM> against a record of the database <NUM> storing the same card token <NUM>, device token <NUM> and authorisation token <NUM>. It will be appreciated that the steps at the second remote server can also be performed as the first remote server.

The matching operation ordinarily returns a positive result whereby, at step <NUM>, the server application <NUM> authenticates the payment card <NUM> and the transaction, the respective transaction token <NUM> of which it updates, as well as the corresponding transaction record in the database <NUM> at step <NUM>. The server application <NUM> finally communicates the updated authentication status to the corresponding merchant terminal <NUM> at step <NUM>, such that processing of the electronic transaction may be completed according to any further conventional data processing steps outside the scope of the present disclosure.

Alternative embodiments of the authenticating method however contemplate additional steps intermediate the local transaction record update of step <NUM> and the communication step of the authentication outcome <NUM>, which are also shown in <FIG> in dotted lines and implement additional security in the electronic transaction processing system. At a first intermediate step <NUM>' that follows step <NUM>, the server application <NUM> may generate a new device token <NUM> for the cardholder device <NUM> associated with the payment card <NUM> involved in the transaction, in compliance with PSD guidelines. At a next intermediate step <NUM>", the server application <NUM> updates the device token entry in the corresponding database record with the new device token <NUM> and, at a final intermediate step <NUM>‴, the server application <NUM> encrypts and communicates the new device token <NUM> to the remote mobile application <NUM> at the cardholder device <NUM> for replacing the previous instance of the device token still stored thereat.

If the successive questions of steps <NUM> and <NUM> are successively answered negatively, a final question is asked at step <NUM>, as to whether the next communication to process is a user interrupt input by the user of the server <NUM>, for instance a server application closing command in the UI <NUM>. If the question of step <NUM> is answered negatively, then the application logic loops and control returns to the question of step <NUM>, allowing the server application <NUM> to process a next association request from a remote cardholder device <NUM> or to process a next transaction call from a remote merchant terminal <NUM>. Alternatively, the application <NUM> is unloaded from the terminal memory and the server <NUM> may eventually be switched off, for instance for a hardware maintenance or upgrade task.

The present invention thus provides a distributed electronic transaction system, in which any payment card <NUM>N of a cardholder is easily, ergonomically and promptly associated with a cardholder device <NUM> during a single association procedure performed between the cardholder device <NUM> and the first remote server <NUM> with minimal input from the cardholder into the cardholder device <NUM>, in a preferred embodiment consisting merely of an NFC communication of card data to the cardholder device <NUM> through e.g. a 'tap' of the card <NUM> against the device <NUM>, and an input of <NUM> alphanumerical characters into a user interface. In that distributed electronic transaction system, the associated cardholder device <NUM> can subsequently provide the functionality of a multifactor authentication during any subsequent electronic transaction processed by the system, for which a merchant terminal <NUM> requires authentication of the payment card <NUM> involved in the transaction to comply with regulatory requirements, again with minimal input from the cardholder into the cardholder device <NUM>, in a preferred embodiment consisting of only the NFC communication of card data to the cardholder device <NUM> through the 'tap' of the card <NUM> against the device <NUM>.

Claim 1:
A method of associating a payment card (<NUM>) of a cardholder with a cardholder computing device (<NUM>) of the cardholder in an electronic payment network, the method comprising the steps of:
providing the cardholder with the card and a device activation code (<NUM>) for the cardholder computing device to be associated with the card, wherein the card has a number uniquely identifying the card in the electronic payment network and wherein the device activation code comprises a one-time code uniquely associated with the card;
communicating the card number and the device activation code from the cardholder computing device to a first remote server (<NUM>); wherein
at the first remote server, obtaining an issuer assured card token (<NUM>) generated from a second remote server, the issuer assured card token based on both the card number and the device activation code;
generating a device token (<NUM>) and an authorisation token (<NUM>) at the first remote server,
wherein the device token is uniquely representative of the cardholder computing device ;
storing the card token, the device token and the authorisation token in a data structure at the first remote server ; and
communicating the card token and the device token to the cardholder computing device and storing same thereat.