Patent Description:
Many people routinely carry a portable electronic device (e.g. a smartphone) on their person that has the necessary hardware to communicate with a point of sale device. In view of this, it has been recognised that by virtualising a payment instrument (also known as 'Tokenisation'), a person can use their electronic device as a payment device without having to make use of a more traditional plastic payment card or other such payment instrument. So-called 'contactless' payment using smartphones, where a person brings their smartphone into proximity with a point of sale terminal or PIN Entry Device having Near Field Communication (NFC) capabilities to effect a payment, is an example of this.

A key part of the virtualisation process is the creation of the virtual payment instrument on the electronic device. The process of creating a virtual payment instrument is often referred to in the art as 'payment instrument provisioning', 'instrument provisioning', 'card provisioning', or just simply 'provisioning'. In the provisioning process, a payment instrument is loaded onto an electronic device, such that a virtual equivalent of the payment instrument (the 'provisioned payment instrument) is created. Here the provisioned payment instrument may also include other provisioning elements, such as cryptographic keys, and other settings associated with the payment instrument. This allows the electronic device to be used to effect payments, both physically, e.g. at a point of sale in a store and electronically, e.g. online purchasing through apps stored on the electronic device. The provisioned payment instrument is stored securely on the electronic device, which may involve storing the provisioned payment instrument in a so-called 'Secure Element' provided on the device, as is known in the art. Alternatively the provisioned payment instrument (including cryptographic keys and settings, if present) can be stored in the so-called 'cloud' and not kept in its entirety on the electronic device. This is also known in the art.

As is known in the art of payment instrument provisioning systems, three provisioning 'paths' are defined. A first path defines a provisioning process for payment instruments that can be provisioned to an electronic device without the electronic device having to contact the instrument issuer for verification during the provisioning process. A second path defines a provisioning process for payment instruments that cannot be provisioned to an electronic device, such that there is no need to contact the instrument issuer for verification during the provisioning process. This path may contain blacklisted instruments, for example. A third path defines a provisioning process for payment instruments for which approval from an instrument issuer must be sought by the owner of the electronic device and payment instrument before the payment instrument can be provisioned to the device. The present invention is concerned with payment instrument that fall under this third path.

Typically, a user is required to enter various pieces of information associated with the payment instrument into the electronic device that the payment instrument is being provisioned onto. In the case where the payment instrument is a payment card of the type well known in the art, the information usually comprises the user's name, a unique identifier associated with the payment card (e.g. a Primary Account Number or 'PAN'), the expiry date of the payment card and the cardholder security code from the signature strip. All of this information is typically printed on the payment card. The user can therefore manually enter this information into the electronic device via e.g. a touchscreen or keypad simply by reading it directly from the payment card, or in some cases an image of the payment card is captured by a camera on the electronic device and processed by the device to obtain the necessary information.

A problem with the provisioning process is that it is possible for an unauthorised user to provision a payment instrument without the knowledge or consent of the authorised user. In this specification, an authorised user is understood to be the instrument holder, i.e. the person to whom the payment instrument was issued by an issuer. An unauthorised user can, for example, provision a stolen payment card simply by reading off the required information directly from the payment card and entering it into their own electronic device. Alternatively the unauthorised user can use stolen payment card data bought from what is known in the art as a 'carding forum' or other criminal network.

Once successfully provisioned, the unauthorised user is free to use the provisioned payment instrument to commit fraud.

Prior art provisioning techniques attempt to solve this problem by including identity checks in the provision process. For example, in the case where the payment instrument is a payment card, the provisioning process may involve requiring the user to input additional information that is not directly available from the payment card, such as a social security number or a piece of 'memorable information' (e.g. mother's maiden name, name of first school, place of birth, etc.). The inputted information is checked against corresponding information stored in the records of the card issuer and the payment card is only provisioned onto the electronic device if the information is found to match. Alternative examples include using out of band communications such as sending a unique SMS code to the cardholder to input, or receiving a phone call where a unique number is played though the cardholders phone. This procedure is adopted for provisioning third path payment instrument.

However, these identity checks do not entirely prevent fraud. It has been found that unauthorised users have been able to successfully pass the identity checks by e.g. using social engineering techniques to gain access to the authorised user's social security number or memorable information or in particular through the simultaneous theft of the payment instrument (e.g. card) and electronic device (e.g. mobile phone). It is therefore clear that improvements in the security of card provisioning are still needed, and in particular which reduce the effectiveness of such social engineering techniques.

<CIT> describes a method and system for provisioning payment credentials usable by a mobile device in conducting a payment. The method is conducted at a provisioning system and comprises the steps of: receiving payment credentials from a receiving device, the payment credentials having been obtained from a portable payment device presented by a consumer at the receiving device; receiving, from the receiving device, an identifier entered by the consumer; identifying a mobile device or a secure element corresponding to the identifier; and communicating the payment credentials or a derivation of the payment credentials to the identified mobile device or the secure element to be securely stored in association with the mobile device. The method may include: encrypting the received payment credentials, the encrypted payment credentials having a unique decryption key; and wherein communicating a derivation of the payment credentials communicates the unique decryption key.

In a first aspect, the present invention provides a method of authenticating a request to provision a payment instrument onto an electronic device, as set out in independent claim <NUM>.

In a second aspect, the present invention provides a system for authenticating a request to provision a payment instrument, as set out in independent claim <NUM>.

In a third aspect, the present invention provides a method of authenticating a request to provision a payment instrument onto an electronic device, as set out in independent claim <NUM>.

In a fourth aspect, the present invention provides a system for authenticating a request to provision a payment instrument onto an electronic device, as set out in independent claim <NUM>.

Further preferred features of these aspects of the invention are set out in the appended dependent claims.

Embodiments of the present invention are now described, by way of example only, with reference to the accompanying drawings, in which:.

The following detailed description is structured as follows. <FIG> and related description show and describe a system <NUM> suitable for implementing all embodiments of the present invention. <FIG>, <FIG> and <FIG> show operation of the various components of system <NUM> according to a first embodiment and <FIG>, <FIG> and <FIG> show operation of the various components of system <NUM> according to a second embodiment, not forming part of the claimed subject matter. <FIG> is a sequence diagram showing the operation of system <NUM> according to the first embodiment and <FIG> is a sequence diagram showing the operation of system <NUM> according to the second embodiment not forming part of the claimed subject matter.

In the present disclosure, a payment instrument is understood to encompass any device, means or mechanism for effecting a non-cash payment. A very well-known payment instrument is a payment card, and for this reason the following disclosure focusses on embodiments that make use of payment cards. It should however always be kept in mind that the present invention is applicable to payment instruments in general and that therefore references to a 'payment card' in the following should be understood to be a reference to a payment instrument in general. Other examples of payment instruments include virtual (provisioned) payment cards and fobs. Many other examples of payment instruments will be known to a skilled person, and such payment instruments are also compatible with the present invention.

<FIG> shows a schematic diagram of a system <NUM> suitable for implementing all embodiments of the present invention. System <NUM> includes a payment card <NUM>, a secure data entry device <NUM>, an electronic device <NUM>, a server <NUM> and a card issuer server <NUM>. Each of these elements is described in turn below.

In <FIG>, payment card <NUM> is a physical plastic payment card of the type well known in the art. However, the invention is not limited in this respect and payment card <NUM> can alternatively be any payment instrument known to a skilled person.

Payment card <NUM> includes a storage module <NUM> on which data relating to payment card <NUM> is stored. This data may include, for example, a Primary Account Number (PAN) associated with the card, the name of an authorised user, an expiry date of the card and/or any other data deemed useful by a skilled person. In this embodiment storage module <NUM> is an integrated circuit, such that in this embodiment payment card <NUM> is suitable for use with the 'chip and PIN' payment system that is well known in the art. It will be appreciated that the invention is however not limited in this respect, and storage module <NUM> may be any other storage means known to the skilled person such as a magnetic stripe or secure element in an electronic device. Payment card <NUM> may alternatively or additionally includes an antenna (not shown) to allow it to communicate wirelessly with secure data entry device <NUM>. This is known in the art as a 'contactless' payment system.

System <NUM> also includes a secure data entry device <NUM>. Secure data entry device <NUM> can be any secure data entry device known in the art that has been modified to include a mode select module <NUM> as described later in this specification. In this embodiment, secure data entry device <NUM> is a Pin Entry Device ('PED') such as the VeriFone® VX <NUM> Card Secure PIN entry device as available from VeriFone® UK Limited. The invention is however not limited in this regard and any device suitable for receiving entry of secure data from a user can be used instead of a Pin Entry Device.

Secure data entry device <NUM> is configured to allow a user to input secure data that is associated with payment card <NUM>. Secure data entry device <NUM> includes a payment instrument reading module that, in this embodiment, takes the form of card reading module <NUM>. Card reading module <NUM> is configured to read data from storage module <NUM> of payment card <NUM>. In this embodiment card reading module is an integrated circuit reader. It will be appreciated that the invention is however not limited in this respect, and card reading module <NUM> may be any reading means known to the skilled person that is suitable for reading data from storage module <NUM>, such as a magnetic stripe reader or Near Field Communication (NFC) reader. Card reading module <NUM> may comprise multiple card reading means. In the case where the payment instrument is not a payment card, a skilled person will be able to readily select an appropriate form for the payment instrument reading module.

Secure data entry device <NUM> also includes a user input module <NUM> that is configured to accept input from a user. In this embodiment, user input module <NUM> is a keypad configured to allow a user to enter a Personal Identification Number (PIN) into secure data entry device <NUM>. In this embodiment, as mentioned above, secure data entry device <NUM> may be referred to as a PIN Entry Device (PED). As is known in the art, a PIN is a numeric code that is associated with payment card <NUM> and is known (at least in theory) only by an authorised user of payment card <NUM>. In this way, a PIN is one example of secure data in the context of the present invention. During a transaction, secure data entry device <NUM> compares an entered PIN with a PIN that is stored on a record associated with payment card <NUM>. If these are found to match, then the transaction is authorised. If the entered PIN does not match the PIN on record for payment card <NUM>, then the transaction is declined, or the user is asked to re-enter their PIN.

Other embodiments in which user input module <NUM> takes a different form are also contemplated. For example, in another embodiment user input module <NUM> is a fingerprint scanner. In this alternative embodiment, the secure data is the fingerprint of the user. A skilled person having the benefit of the present disclosure will be able to determine other suitable forms for user input module <NUM> and for the corresponding secure data. For example, other biometric scanning means may be used to user input module <NUM>, with the corresponding biometric data being used as the secure data.

User input module <NUM> can optionally also be used by a merchant or retailer to input retailer commands, typically amount to be entered, cash back amount, and to amend any of the settings on secure data entry device <NUM>. This functionality is preferred where secure data entry device <NUM> is deployed in an environment where there is not a separate retailer till system (a 'Point of Sale' terminal) connected to secure data entry device <NUM>.

Secure data entry device <NUM> further includes a processor <NUM> that is configured to control the operation of the other components of secure data entry device <NUM>, including any combination of card reading module <NUM>, user input module <NUM>, mode select module <NUM> and network interface module <NUM>. It will be appreciated that secure data entry device <NUM> may include other hardware and/or software components that are not explicitly shown in <FIG>, and further that processor <NUM> may be configured to control any such further components. Processor <NUM> comprises any known data processing means, and in this embodiment processor <NUM> is a microcontroller.

Secure data entry device <NUM> preferably also includes a mode select module <NUM>. Mode select module <NUM> has a first setting which, when selected, causes secure data entry device <NUM> to behave in the same manner as a prior art secure data entry device.

This first setting is referred to herein as data processing device operating in 'normal' mode.

Mode select module <NUM> also has a second setting which, when selected, causes secure data entry device <NUM> to behave in a manner different from that of a prior art secure data entry device. This second setting is referred to herein as data processing device operating in 'identity verification' mode. Further description of secure data entry device <NUM> operating in identity verification mode is set out later in this specification. It will thus be understood that prior art secure data entry devices do not include a component equivalent to mode select module <NUM>.

In this embodiment, mode select module <NUM> includes a button that is provided in an exterior housing of secure data entry device <NUM> such that it is accessible to a user of secure data entry device <NUM>. A user depresses the button to switch secure data entry device <NUM> from the normal mode to the identity verification mode. The invention is however not limited in this respect, and mode select module <NUM> can be implemented in many other forms. For example, mode select module <NUM> may alternatively be communicatively coupled to a point of sale terminal (not shown) and may be configured to receive commands from the point of sale terminal in order to switch between operating modes. Mode select module <NUM> may be communicatively coupled to network interface module <NUM> to facilitate reception of commands. Additionally, instead of a button, mode select module <NUM> may include any other user interface means suitable for toggling operation modes, such as a touchscreen, or a combination of buttons such as a 'shift-F1' type combination. Additionally, secure data entry device <NUM> could default to having identity verification mode as the initial operation without any user input.

It is also contemplated that secure data entry device <NUM> can be provided without mode select module <NUM>. In this case the normal payment options of secure data entry device <NUM> are disabled or otherwise not present, such that secure data entry device <NUM> can only operate in a stand-alone single purpose identity verification mode. It will be understood that this arrangement is covered by the present invention, as it may be thought of as a secure data entry device for which mode select module <NUM> is permanently set in identity verification mode.

Secure data entry device <NUM> additionally includes a network interface module <NUM> that is configured to transmit data out from secure data entry device <NUM> and to receive data into secure data entry device <NUM>. Network interface module <NUM> is well known in the art and as such is not described in further detail here. Network interface module <NUM> is connectable to any suitable private or public network, such as the Internet. Network interface module <NUM> may be in communication with any combination of server <NUM>, card issuer server <NUM>, a point of sale terminal, and/or any other data processing device or the like.

Secure data entry device <NUM> is not limited to a PED. For example, secure data entry device <NUM> may be an Automated Teller Machine (ATM), an Unattended Payment Terminal (UPT), a Semi attended Cardholder Activated Payment Terminal (SACAT) or an Automated Fuel Dispenser (AFD). Further modifications are possible.

In the case of an ATM in particular, the ATM preferably includes a communication module that is capable of transmitting data to electronic device <NUM>; i.e. one-way communication. The communication module can be any of:.

It will be appreciated that regardless of the configuration of the communication module, data does not need to be transmitted from electronic device <NUM> to the ATM.

System <NUM> also includes an electronic device <NUM> that is configured for provisioning payment card <NUM>. It will be appreciate that, in the interests of clarity, only those elements of device <NUM> that are pertinent to the present invention are shown in <FIG> and that consequently electronic device <NUM> may include additional non-illustrated elements.

Electronic device <NUM> is preferably a portable electronic device; i.e. it is suitable for being carried around on a user's person. However, the invention is not limited in this respect. In the illustrated embodiment electronic device <NUM> is a mobile telephone, preferably a smartphone, but it will be appreciated that the invention is not limited in this respect and that device <NUM> could be any of a tablet, a games console, a smart television, a wearable electronic device, a watch, a beacon, or a payment card alternative such as 'Coin' as supplied by Coin, Inc or a looppay case or card as supplied by ©<NUM> LoopPay Inc. Other suitable electronic devices compatible with the present invention will be apparent to a skilled person having the benefit of the present disclosure.

Electronic device <NUM> includes an applications processor <NUM> that is configured to execute one or more applications ('apps') that are stored on a storage module <NUM>. Applications processor <NUM> can be any suitable data processing device known in the art, such as a microprocessor. Applications processor <NUM> is communicatively coupled to a Near Field Communication (NFC) controller <NUM>, and NFC controller <NUM> is in turn communicatively coupled to an antenna <NUM>. This arrangement allows device <NUM> to transmit data to and receive data from other external devices such as secure data entry device <NUM> using well known NFC communication techniques. This arrangement of hardware and its operation to transmit and receive data is well known in the art and hence is not described in detail here. It will be appreciated that NFC controller <NUM> can be replaced with, or provided in addition to, any other network interface component, such as a Wi-Fi module and/or a Bluetooth module.

Applications processor <NUM> is also communicatively coupled to user input module <NUM>, display <NUM> and network interface module <NUM> and is configured to control these components of electronic device <NUM>. Applications processor <NUM> may also be configured to control any additional hardware and/or software components that are provided in electronic device <NUM>.

Electronic device <NUM> may also include a secure element <NUM>, which is where provisioned payment card details are stored. As noted earlier, the payment card details may be stored with additional information such as any combination of cryptographic material, payment card configuration, private cryptographic keys and public cryptographic keys. The payment card details can be, for example, a Primary Account Number ('PAN') or a tokenised PAN, and in the case of a payment instrument that is not a payment card the details may be e.g. a sort-code and account number combination. Other suitable details will be readily selected by a skilled person having the benefit of the present disclosure, according to the nature of the payment instrument.

Alternatively the payment card details and the above-mentioned optional additional information can be stored in software, perhaps with some of the data stored remotely from the electronic device on a server. This is referred to in the art as 'the cloud'. This is defined for example in Visa cloud based payments specification:
https://technologypartner. com/Mobile/MobilePublications. aspx#<NUM>. In this case secure element <NUM> can be omitted.

As is known in the art, secure element <NUM> may be a non-volatile memory card such as a micro Secure Digital card (microSD) or a Subscriber Identity Module (SIM) card. In the illustrated embodiment secure element <NUM> is communicatively coupled to NFC controller <NUM> to facilitate payment using a provisioned card. NFC controller <NUM> may be embedded in the chipset of electronic device <NUM>. Alternatively, secure element <NUM> may be communicatively coupled to a dedicated NFC controller and antenna, or may itself include an integrated NFC controller and antenna. Whatever the specific configuration of secure element <NUM>, what is important is that apps executed by applications processor <NUM> cannot access secure element <NUM>. This separation ensures the security of provisioned card data. Secure element <NUM> is not essential to the invention and it may be replaced by e.g. a Trusted Execution Environment (TEE) as is known in the art or cloud based payments as is known in the art.

Electronic device <NUM> may further include a user input module <NUM> that is configured to accept input from a user. Any suitable human interface device may be used for user input module <NUM>, including but not limited to a touchscreen, a keypad having one or more buttons, a trackpad, a keyboard, a mouse, etc. User input module <NUM> may comprise more than one human interface device. Electronic devices that do not include user input module <NUM> are also contemplated; for example, a wearable electronic device may accept and use remote connected user input.

Electronic device <NUM> may additionally include a display <NUM> that is configured to display information to a user. Any display known to the skilled person can be used for display <NUM>. Display <NUM> may be a touchscreen display, in which case display <NUM> may be part of user input module <NUM>. Electronic devices that do not include display <NUM> are also contemplated. For example, display <NUM> can also be a remote display that is provided on another device, for example used when a wearable communicates to the user via an interface on a mobile telephone. Alternatively, display <NUM> can be removed and replaced by an audio interface, or other human interface (e.g. haptic, audio, braille, smell, etc.).

System <NUM> also includes a processor server <NUM> that is configured to transmit data to and receive data from secure data entry device <NUM> and any suitable private or public network, e.g. the Internet. Processor server <NUM> is also configured to transmit data to and receive data from a card issuer server <NUM> via any suitable private or public network, e.g. the Internet. Hereinafter processor server <NUM> is referred to simply as 'server <NUM>', for brevity.

Server <NUM> is a server that is associated with an entity that is providing an identity verification service according to the present invention. This entity could be, for example, a card acquirer, a Payment Service Provider, or some other processor of identity verification services. Card acquirer and Payment Service Provider are both terms of art. Here, 'associated with' is understood to mean that the associated entity can transmit data and/or instructions to and receive data and/or instructions from card issuer server <NUM>. The present invention is however not limited in this respect and server <NUM> can be associated with any entity deemed appropriate by a skilled person.

Card issuer server <NUM> is a server that is associated with a card issuing entity. Alternatively, card issuer server <NUM> may be associated with a separate entity that is acting on behalf of a card issuing entity, e.g. an agent or other such intermediary such as a payment scheme operator. Here, 'associated with' is understood to mean that the associated entity can transmit data and/or instructions to and receive data and/or instructions from card issuer server <NUM>.

In <FIG> server <NUM> and card issuer server <NUM> are shown as separate entities. This is done purely in the interests of clarity of illustration and it will be appreciated that the invention is not limited in this respect. For example, server <NUM> and card issuer server <NUM> may be the same data processing device or the same distributed system. Therefore, in the event server <NUM> and card issuer server <NUM> are the same data processing device or the same distributed system, references to server <NUM> in the following should be understood to be synonymous with references to card issuer server <NUM>, and references to card issuer server <NUM> in the following should be understood to be synonymous with references to server <NUM>. An example of this is an ATM, where the card issuer may be the same as the ATM provider, in which case server <NUM> and card issuer server <NUM> may be the same entity.

Additionally or alternatively, one or both of server <NUM> and card issuer server <NUM> may comprise a distributed system in which multiple data processing devices are communicably coupled to one another in a manner that allows the coupled data processing devices to interact with one another to achieve a common objective. The individual data processing devices may communicate directly with one another, or via additional routing components, over one or more private and/or public networks, e.g. the Internet. The individual data processing devices may be at a common physical location, or they may be at different physical locations. Further such modifications are possible. Such distributed systems are well known in the field of computing and hence are not described in detail here.

Operation of the present invention according to the first embodiment is described below with reference to <FIG>, <FIG> and <FIG>.

With reference to <FIG>, the operation of secure data entry device <NUM> according to the first embodiment is described below.

In step <NUM>, mode select module <NUM> causes secure data entry device <NUM> to enter identity verification mode. In this embodiment, an operator presses a button that is part of mode select module <NUM> to cause secure data entry device <NUM> to enter identity verification mode. The button could be a physical button or it could be a touch button as known in the art. It will be appreciated that the present invention is not limited in this respect and that other mechanisms for switching secure data entry device <NUM> to identity verification mode can alternatively be used. For example, a combination of buttons could be pressed to enter identity validation mode. It should also be appreciated that the normal mode operation of secure data entry device <NUM> is as any prior art secure data entry device operates during a transaction involving a payment card, and further that identity verification mode is different to this normal operating mode. Here, 'normal operating mode' includes any type of transaction that is known in the art, including a financial transaction such as a purchase or a refund, a balance enquiry, a pre-authorisation transaction and a payment card-validity check transaction. In some cases one or more function keys are provided to allow an operator to select the transaction type. It should be appreciated that these prior art function keys are not equivalent to mode select module <NUM>, since they do not enable operation of secure data entry device <NUM> according to the present invention, as described below.

As noted earlier, in an alternative embodiment secure data entry device <NUM> is defaulted to identity verification mode. In that case, step <NUM> is omitted and the method instead starts at step <NUM>.

In step <NUM>, a transaction is initiated. In this embodiment, the transaction is a zero value authorisation transaction of the type well known in the art. In this type of transaction, the payment amount associated with the transaction is zero. In this case a zero transaction amount may be displayed to a user by secure data entry device <NUM>. Alternatively, the transaction may relate to a non-zero amount, indicating that goods and/or services are being paid for in addition to the identity verification procedure. Other transaction types known to the skilled person, such as a one dollar authentication transaction, may alternatively be initiated in step <NUM>. The nature of the transaction is not critical to the working of the invention.

Whatever the nature of the transaction, in step <NUM> the user is also prompted to enter their secure data into secure data entry device <NUM>. In the illustrated embodiment the secure data is a PIN associated with payment card <NUM>, but the invention is not limited in this respect and any other secure data known to the skilled person can alternatively comprise the secure data. For example, the secure data may be biometric data, e.g. a fingerprint, or the secure data may be magnetic stripe data generated when card reading module <NUM> reads a magnetic stripe (MSR) on payment card <NUM>. The invention is however not limited in this respect and any known or future Cardholder Verification Method (CVM) or other method of verifying an individual's identity can alternatively be used.

Following this, in step <NUM> the user enters their secure data into secure data entry device <NUM> using user input module <NUM>. Entry of secure data into a secure data entry device is well known in the art and hence is not described in detail here.

In step <NUM>, the secure data entered in step <NUM> is checked against the secure data that is stored on a record associated with payment card <NUM>. If the entered secure data does not match the secure data on record for payment card <NUM> then the method proceeds to step <NUM> where the transaction may be declined, or the user may be prompted to re-enter their secure data. If the transaction is declined then the process ends and card provisioning is not authorised. The secure data may be stored on payment card <NUM>, and specifically in storage module <NUM> and hence the checking may comprise using card reading module <NUM> to access storage module <NUM> to retrieve the stored secure data. Alternatively, the checking may comprise contacting one or both of server <NUM> and card issuer server <NUM> and requesting the secure data stored on record for payment card <NUM>.

If the entered secure data does match the secure data on record for payment card <NUM> then in step <NUM> a request message is transmitted by secure data entry device <NUM> to server <NUM>. In this embodiment the request message is an authorisation request message. The authorisation request message is of the type known in the art and so is not described in detail here. Briefly, the authorisation request message comprises a request for a transaction to be authorised by the issuer of payment card <NUM>. It will be appreciated by those skilled in the art that the request message can comprise any other message known in the art that is associated with requesting a service from the card issuer. For example, the request message can be substituted by a card validity check request message, a balance enquiry message, or any other message associated with checking details relating to a payment card with the payment card issuer. Preferably, only the request message is transmitted by secure data entry device <NUM> to server <NUM>. Secure data entry device <NUM> does not need to transmit any information relating to electronic device <NUM>, e.g. a mobile telephone number etc..

Additionally, other events may trigger an authorisation request message being sent by secure data entry device <NUM> to server <NUM> in step <NUM>. For example, if cryptographic checks fail indicating card data in storage module <NUM> is compromised, or that there may be a replay attack or another compromise of card details is detected, then this may trigger an authorisation request message or another type of known message to be transmitted in step <NUM>.

The request message can optionally include an indication that secure data entry device <NUM> is operating in identity verification mode. The indication may be a flag that indicates that secure data entry device <NUM> is operating in identity verification mode; e.g. the flag takes a first value when secure data entry device <NUM> is operating in normal mode and a second, different value when secure data entry device <NUM> is operating in identity verification mode. The invention is however not limited in this respect and other suitable indications will be apparent to the skilled person having the benefit of the present disclosure. The indication that secure data entry device <NUM> is operating in identity verification mode may be generated by mode select module <NUM> directly, or operation of mode select module <NUM> may cause another component of secure data entry device <NUM>, e.g. processor <NUM>, to generate the indication. The details of the mechanism that causes the creation of the indication are not critical and hence many modifications will be readily apparent to a skilled person having the benefit of the present disclosure.

If the indication is present, it can be used for tracking the occurrences of identity validation mode transactions. This information may be collated and used for billing purposes; specifically, a card acquirer can bill a card issuer for providing the identity validation service on a 'per transaction' basis. Where the indication is a flag, this flag could be passed down later to an acquirer during a reconciliation, log download or settlement event. Alternatively, there could be a special file or message sent to the acquirer from secure data entry device <NUM> detailing a list of all (or one) of the identity validation transactions to bill the issuer for.

Following transmission, in step <NUM> secure data entry device <NUM> receives a response from server <NUM>. In the case that the request message is an authorisation request message, the response from server <NUM> is known as the 'authorisation response message' in the art. It will be appreciated that, in cases where a message other than an authorisation request message is transmitted in step <NUM>, a corresponding response message will be received in step <NUM>.

Secure data entry device <NUM> then determines in step <NUM> whether the received response contains authorisation data that indicates approval of the transaction.

The authorisation data itself can be any data that is created or otherwise made available during the transaction process. This includes data from an issuer response message and/or data relating to the transaction itself. For example, the authorisation data can be an authorisation code of the type associated with a magnetic stripe reader, an Authorisation Response Cryptogram (ARPC), an EMV Random Number, an Authorisation code, one or more Scripts and/or combinations thereof; essentially, any cryptographic data or other such predictable data that is created and/or available during the transaction and which can be validated by a card issuer. It will therefore be appreciated that the invention is not limited to any specific form of authorisation data, and that the authorisation data can be any data that indicates that the secure data entered in step <NUM> matches corresponding secure data that is on record for the payment card involved in the transaction.

If the authorisation response message does not contain authorisation data, or if the received data indicates that the transaction has been declined, then in step <NUM> the transaction is declined. It will be appreciated that a card is not provisioned on the basis of a declined transaction, and so after declining the transaction the process ends by proceeding directly to step <NUM>.

If the authorisation response message received indicates that the transaction is requiring a voice authorisation (also called a voice referral in the art), then step <NUM> instead comprises referring the transaction. This is a known function of payment card processing in the art, in which a well-known process in the art is initiated where the issuer can ask the cardholder questions, sometimes directly, sometimes via the merchant operator. This will result in either an authorisation where the operator inputs manually an authorisation code or a decline where the decision to decline is manually input by the operator. This may be used to ask further security questions from the issuer to the cardholder.

If the authorisation response message does contain authorisation data indicating approval of the transaction, then in step <NUM> the authorisation data is received by electronic device <NUM>.

In the voice authorisation case discussed in the immediately preceding paragraph, assuming that the transaction is authorised, the authorisation data received by electronic device <NUM> in step <NUM> is the authorisation data that was entered by the operator as part of the voice authorisation process.

Electronic device <NUM> can receive the authorisation data via many different mechanisms. In this embodiment, step <NUM> involves the user manually reading the authorisation data on e.g. a display of secure data entry device <NUM> and entering the authorisation data manually into electronic device <NUM> using e.g. user input module <NUM>. Alternatives are possible; for example, in step <NUM> electronic device <NUM> may receive an electronic transmission from secure data entry device <NUM> that contains the authorisation data. This may involve, for example, moving electronic device <NUM> proximate secure data entry device <NUM> to facilitate wireless communication between electronic device <NUM> and secure data entry device <NUM>. The wireless communication may be NFC communication or Bluetooth or Bluetooth low energy. Alternatively, the authorisation data may be received by electronic device <NUM> by using electronic device <NUM> to read a barcode or Quick Response (QR) code that is provided on a receipt generated by secure data entry device <NUM>. Alternatively, the authorisation data may be transmitted by secure data entry device <NUM> by broadcasting sound encoded with the data for the authorisation data, which sound is received by a microphone that is part of electronic device <NUM>. The receipt may be a paper receipt or an electronic receipt that is displayed in a suitable location, e.g. on a display of secure data entry device <NUM>. Any of Bluetooth, Bluetooth Low Energy (BLE), Wi-Fi, an acoustic signal (e.g. sound), a light signal (e.g. a series of light pulses), and/or a series of vibrational pulses may be used to transmit the authorisation data from secure data entry device <NUM> to electronic device <NUM>. In each case the authorisation data is encoded in the respective signal. The invention is however not limited in this respect and other techniques for causing electronic device <NUM> to receive the authorisation data can also be used.

In step <NUM>, the electronic device <NUM> transmits the authorisation data that it received in step <NUM> to card issuer server <NUM>, e.g. by using network interface module <NUM> to communicate with card issuer server <NUM> via any suitable private or public network, e.g. the Internet. Card issuer server <NUM> compares the authorisation data received from electronic device <NUM> to the authorisation data generated by card issuer server <NUM> earlier in the process. This is described in more detail later in this specification in connection with <FIG>.

In step <NUM>, electronic device <NUM> receives a response from card issuer server <NUM>. This response indicates whether electronic device <NUM> has authority to provision payment card <NUM> onto itself. The indication can take any form known to a skilled person, and in the illustrated embodiment the indication is a flag that takes a first value to indicate 'authorised' and a second, different value to indicate 'not authorised'.

In the event that authorisation is given, in step <NUM> the payment card is provisioned onto electronic device <NUM>. Here, provisioning payment card <NUM> onto electronic device <NUM> is understood to include provisioning payment card <NUM> into a remote server (known as 'cloud storage' in the art) via electronic device <NUM>. In all cases, provisioning occurs in the manner well known in the art that will vary according to the specific payment instrument that is being provisioned. In the event that authorisation is not given, the provisioning of payment card <NUM> onto electronic device <NUM> is not authorised and the process ends at step <NUM>.

It will be appreciated that the process described above in connection with <FIG> advantageously allows a card issuing entity to be confident that electronic device <NUM> is associated with an authorised user of payment card <NUM> and further that both electronic device <NUM> and payment card <NUM> were in the possession of said authorised user when the user identity validation occurred. An additional advantage is that the location of secure data entry device <NUM> and electronic device <NUM> may be known to <NUM> server and/or card issuer server <NUM>, and hence determining whether these locations match can provide further confidence that the authorisation is genuine if the locations are found to match, or indicate that the authorisation may not be genuine if the locations are not found to match.

With reference to <FIG>, the operation of electronic device <NUM> according to the first embodiment is described below.

In step <NUM>, a user initiates a provisioning process on electronic device <NUM>. In this embodiment the provisioning process is initiated by activating a provisioning software application (often referred to as an 'app' in the art) that is stored on storage module <NUM> and initiating functionality within this application to provision a new payment instrument, which in this case is a payment card. The invention is however not limited in this respect and other mechanisms for initiating the provisioning process on electronic device <NUM> known to a skilled person can alternatively be used. These mechanisms will vary according to the nature of the payment instrument that is being provisioned.

In step <NUM>, the user enters information relating to payment card <NUM> that they wish to provision into electronic device <NUM>, e.g. by using user input module <NUM>. The information may include, for example, a PAN and/or an expiry date, although the invention is not limited in this respect and the entered information can comprise any data deemed necessary and/or useful by a skilled person. Optionally, the user may be able to enter information by using electronic device <NUM> to capturing an image of payment card <NUM>, and electronic device <NUM> processes the captured image to obtain the necessary information. Alternatively this card information could be populated by using the NFC "read" capability of the electronic device (e.g. phone).

Following this, in step <NUM> the payment card path is determined. As explained in the background section of this specification, in the art three payment paths are defined. A first path defines a provisioning process for payment instrument that can be provisioned onto an electronic device without the electronic device having to contact the instrument issuer for verification. A second path defines a provisioning process for payment instrument that cannot be provisioned onto an electronic device, such that there is no need to contact the instrument issuer for verification. This path may contain blacklisted cards, for example. A third path defines a provisioning process for payment instrument for which approval from an instrument issuer must be sought by the electronic device before the payment instrument can be provisioned onto the device. It is envisaged that, from time to time and for other reasons including fraud checking, the cardholder may be asked to re-confirm their identify using the third path; i.e. a payment instrument that has previously been on another path may be switched to the third path from time to time.

Determination of the payment card path is known in the art and is not described in detail here. In the event that payment card <NUM> is determined to be on the first path, then in step <NUM> the payment card is provisioned on electronic device <NUM>. In the event that payment card <NUM> is determined to be on the second path, then in step <NUM> the provisioning of payment card <NUM> is declined. As noted earlier, the present invention is not concerned with first and second path payment cards and so processing of these types of cards is not described in detail here.

In the event that payment card <NUM> is determined to be on the third path, then in step <NUM> electronic device <NUM> informs the user they are required to attend an identity verification point in order to provision payment card <NUM>. Electronic device <NUM> can inform the user of this in any suitable way, and in this embodiment a message such as "Please go to your local identity verification point to complete loading of this card onto your device" is displayed to the user by electronic device <NUM> on display <NUM>. The invention is not limited in this respect and any mechanism for informing a user that attendance of an identity verification point is required known to a skilled person can be used. For example, the user may receive an electronic message such as an email or SMS message informing them that attendance of an identity verification point is required. The user may also be provided with a mechanism to locate nearby identity verification points, such as an electronic map of the type well known in the art, possibly also including directions. It is important to appreciate that, at this point, payment card <NUM> has not yet been provisioned onto electronic device <NUM> and is therefore not yet available for use in making payments. Instead, a provisioning request is pending at server <NUM> and/or issuer server <NUM> and awaiting user identification at the identity verification point in order to validate the provisioning request.

Step <NUM> also includes electronic device <NUM> sending a provisioning request message to server <NUM> and/or card issuer server <NUM>. The provisioning request message can be sent by any communication channel that is available to electronic device <NUM>, perhaps via antenna <NUM>, such as a radio frequency transmission over a telecommunications network or a WiFi transmission to a router that is connected to a network such as the Internet. The provisioning request message includes a unique identifier suitable for identifying payment card <NUM>, such as a Payment Account Reference ('PAR'), a PAN or tokenised PAN, or a sort-code and account number combination, but this is not essential to the invention and any other unique identifier that can be used to uniquely identify a payment card <NUM> may alternatively be used. The provisioning request message may additionally include information that uniquely identifies electronic device <NUM> such as an International Mobile Station Equipment Identity (IMEI) number, a mobile equipment identifier (MEID), a MAC address, or any other unique device identifier. The provisioning request message may be stored by server <NUM> and/or card issuer server <NUM> in a provisioning request message database.

As used herein, the term 'identity verification point' refers to a location at which one or more secure data entry devices like secure data entry device <NUM> are provided. Thus, the identity verification point can be a retailer's premises, a kiosk, a booth, an 'in bank branch' device, a data terminal, an ATM, etc. having at least one secure data entry device <NUM> available for use. Numerous suitable identity verification points will become apparent to a skilled person having the benefit of the present disclosure.

Following the request, in step <NUM> the user attends an identity verification point and indicates that they wish to use the identity verification functionality of secure data entry device <NUM>. At this point, secure data entry device <NUM> is operated in the manner described above in connection with <FIG>. It will be appreciated that significant time may elapse, e.g. a day or more, between steps <NUM> and <NUM>.

In an alternative non-illustrated embodiment step <NUM> is omitted so that, after the provisioning process is initiated in step <NUM>, the user is prompted to attend an identity verification point. Data relating to the user's payment instrument is automatically entered onto electronic device <NUM> when the user attends the identity verification point. Data transfer may be achieved in any manner known to the skilled person, such as using electronic device <NUM> to scan a Quick Response code or bar code that is displayed on secure data entry device <NUM> or printed on a receipt, or initiating Near Field Communication between secure data entry device <NUM> and electronic device <NUM>. Advantageously, this avoids the user having to manually enter data relating to their payment instrument, saving time and also avoiding data entry errors. In this alternative embodiment, the optional provisioning request message described in the context of step <NUM> may be transmitted by electronic device <NUM> to server <NUM> and/or issuer server <NUM> following automatic entry of data relating to the user's payment instrument.

Referring to <FIG>, the operation of server <NUM> and card issuer server <NUM> according to the first embodiment is described below.

In step <NUM>, server <NUM> receives a request message that has been transmitted by secure data entry device <NUM> (see step <NUM> of <FIG>). The request message is transmitted from secure data entry device <NUM> to server <NUM> via any available private or public network, e.g. the Internet. As discussed above, the request message contains all of the usual content that one skilled in the art would expect to find in a request message as known in the art. Optionally, the request message may contain an indication such as a flag that indicates that secure data entry device <NUM> is operating in identity validation mode.

Following this, in step <NUM>, server <NUM> transmits the request message to card issuer server <NUM> and in step <NUM> card issuer server <NUM> validates the transaction in the manner well known in the art. It is important to note that, from the perspective of server card issuer server <NUM>, the transaction is a normal transaction as known in the art.

Following validation, in step <NUM> card issuer server <NUM> transmits a response message to server <NUM>, where the response message indicates whether the transaction has been approved, declined or referred in the case of voice authorisation as discussed earlier in this specification in connection with step <NUM>. This is also well known in the art. In the case that the transaction has been approved, the response message includes authorisation data of any type discussed earlier in this specification. In the case that the transaction has been declined, the response message will omit the authorisation data and/or will include some indication (e.g. a flag) to indicate that the transaction has been declined.

In step <NUM>, server <NUM> transmits the response message that it received in step <NUM> on to secure data entry device <NUM>. At this point, secure data entry device <NUM> determines whether the response message contains authorisation data (<FIG>, step <NUM>) and, if yes, transmits the authorisation data to electronic device <NUM> (<FIG>, step <NUM>). Electronic device <NUM> then transmits a message to card issuer server <NUM>, where the message contains the authorisation data it has received.

In step <NUM>, card issuer server <NUM> analyses the message received from electronic device <NUM> to determine if it contains the authorisation data that was transmitted to server <NUM> in step <NUM>. In the event that the message received from electronic device <NUM> does contain this authorisation data, card issuer server <NUM> also determines whether a provisioning request has been made in connection with payment card <NUM> via a provisioning request message (see step <NUM>). This determination can be made by performing a lookup in a provisioning request message database, for example.

In the event the message received from electronic device <NUM> does contain the authorisation data and optionally the provisioning request message was found in provisioning request message database then the method then moves to step <NUM> and card issuer server <NUM> transmits a provisioning approved message to electronic device <NUM>. The provisioning approved message authorising the provisioning of payment card <NUM> onto electronic device <NUM>. The provisioning of this card takes place as described above in connection with step <NUM> of <FIG>.

Step <NUM> can optionally include validating the location of secure data entry device <NUM>, which information may have been included as part of step <NUM>.

In the event that the message received from electronic device <NUM> does not contain the authorisation data that was transmitted to server <NUM> in step <NUM>, and/or a request to provision payment card <NUM> is not found, and/or, if determined, the location does not match, the method moves to step <NUM> and card issuer server <NUM> transmits a provisioning declined message to electronic device <NUM>. The provisioning declined message declines the provisioning of payment card <NUM> onto electronic device <NUM>, so that payment card <NUM> is not provisioned onto electronic device <NUM>.

It will be appreciated that the determination of step <NUM> advantageously allows the present invention to determine, with good confidence, that: <NUM>) a payment instrument and electronic device <NUM> were simultaneously physically present at an identity verification point; and <NUM>) an authorised user was in control of both electronic device <NUM> and the payment instrument and hence in full control of the provisioning process. This allows the present invention to provision third path payment instruments with a good degree of confidence, reducing the opportunity for fraud.

Additionally, it will be appreciated that in all embodiments information relating to electronic device <NUM> (e.g. a device identifier) does not need to be supplied to secure data entry device <NUM>. That is, electronic device <NUM> does not need to transmit data to secure data entry device <NUM>; communication can be entirely one directional from the secure data entry device to the electronic device. This is because the various data processing devices involved in the identification process (i.e. electronic device <NUM>, secure data entry device <NUM>, server <NUM> and card issuer server <NUM>) can tie together a single identification request as it passes through the various devices using information relating to payment card <NUM> such as a PAN, tokenised PAN, PAR, etc. This advantageously simplifies the identification process.

Step <NUM> can optionally make use of additional transaction data to perform a further validation beyond comparing the content of the message received from electronic device <NUM> with the authorisation data that was transmitted to server <NUM>.

In one embodiment the additional transaction data is the location of secure data entry device <NUM> and electronic device <NUM>. In this embodiment, in step <NUM> (<FIG>) electronic device <NUM> additionally transmits its location to server <NUM>. The location of electronic device <NUM> can be determined using well known mechanisms, such as using GPS signals and/or using multilateration techniques on radio signals. The location of electronic device <NUM> is compared to the location of secure data entry device <NUM>, which is either already known to server <NUM> or transmitted by secure data entry device <NUM> in step <NUM> (<FIG>). Typically the location of secure data entry device <NUM> will be the address of the premises in which secure data entry device <NUM> is located.

If the location of electronic device <NUM> matches the location of secure data entry device <NUM> then the card issuing entity can be highly confident that electronic device <NUM> and payment card <NUM> were simultaneously present at the same location during the identity validation process shown in <FIG>, which is an indicator of a genuine attempt to provision payment card <NUM> by an authorised user. Locations that do not match may be an indication that fraud is being attempted, i.e. an unauthorised user is attempting to provision payment card <NUM>. In that case card provisioning may be declined even if the authorisation data received from electronic device <NUM> is found to match the authorisation data that was transmitted to secure data entry device <NUM>.

In another embodiment, the optional additional transaction data comprises first and second time stamps. The first time stamp is generated by secure data entry device <NUM> at an appropriate point during the transaction, e.g. in step <NUM> when a request message is transmitted by secure data entry device <NUM>. The second time stamp is generated by electronic device <NUM> at an appropriate time during the transaction, e.g. in step <NUM> when the electronic device transmits a message to card issuer server <NUM>. Alternatively, server <NUM> may generate the first and second time stamps based on the time at which it receives the request message and the message from electronic device <NUM>, respectively. Server <NUM> is configured to compare the first time stamp with the second time stamp to determine the time difference between these time stamps. Server <NUM> is further configured to compare the calculated time difference with a threshold value to determine whether the time difference exceeds the threshold value. In the event that the threshold value is exceeded, card provisioning may be declined even if the authorisation data received from electronic device <NUM> is found to match the authorisation data that was transmitted to secure data entry device <NUM>. The threshold value is set at a value that is reasonably expected for the time between the request message and the receipt of authorisation data from electronic device <NUM>. For example, the threshold value may be in the range of thirty seconds to five minutes. The invention is however not limited in this respect and a skilled person having the benefit of the present disclosure will be able to determine an appropriate value for threshold value.

It will be appreciated that the time difference calculated by server <NUM> provides an indication of the time that has elapsed between a user entering their secure data into secure data entry device <NUM> and the receiving of authorisation data by electronic device <NUM>. It is expected that the time between these two actions will be relatively short, e.g. of the order of thirty seconds to five minutes. Thus, if the time difference between these two actions is greater than expected, e.g. five minutes or more, then this may be an indication that fraud is being attempted.

Further modifications to the principle of providing further validation will be apparent to a skilled person having the benefit of the present disclosure. It will also be appreciated that more than one further validation can be performed in a single transaction; e.g. both the location and the timestamp information may be compared in step <NUM>.

It will be appreciated that the first embodiment and modifications thereof advantageously allows a payment instrument issuing entity to be confident that a provisioning request was initiated by an authorised user. This is because an unauthorised user should not have been able to enter the user's secure data into secure data entry device <NUM>. In addition, the first embodiment and modifications thereof advantageously allows a payment instrument issuing entity to be confident that electronic device <NUM> and a payment instrument were in the possession of said authorised user when the user identity validation occurred.

Operation of the present invention according to a second embodiment, not forming part of the claimed subject matter but considered useful for understanding the invention, is described below with reference to <FIG>, <FIG> and <FIG>.

With reference to <FIG>, the operation of secure data entry device <NUM> according to the second embodiment is described below. A number of aspects of the operation of secure data entry device <NUM> are the same in both the first and second embodiment, and to indicate this elements of <FIG> that are the same as elements of <FIG> have been given the same suffix. It will be appreciated that, when secure data entry device <NUM> operates according to <FIG>, electronic device <NUM> operates according to <FIG> and server <NUM> and card issuer server <NUM> operate according to <FIG>.

In step <NUM>, mode select module <NUM> causes secure data entry device <NUM> to enter identity verification mode. Step <NUM> is the same as step <NUM> and so is not described in further detail here. In the case that secure data entry device <NUM> defaults to identity verification mode, or only offers identity verification mode because the normal transaction mode has been disabled, step <NUM> is omitted and the method begins at step <NUM>.

In step <NUM>, a transaction is initiated and the user is prompted to enter secure data into secure data entry device <NUM>. Step <NUM> is the same as step <NUM> and so is not described in further detail here.

In step <NUM>, the user enters their secure data into secure data entry device <NUM> using user input module <NUM>. Step <NUM> is the same as step <NUM> and so is not described in further detail here.

In step <NUM>, the secure data entered in step <NUM> is checked against the secure data on record for payment card <NUM>. Step <NUM> is the same as step <NUM> and so is not described in further detail here. If the entered secure data does not match the secure data on record for payment card <NUM> then the method proceeds to step <NUM> where the transaction may be declined, or the user may be prompted to re-enter their secure data. If the entered secure data does match the secure data on record for payment card <NUM> then the method proceeds to step <NUM> where a request message is transmitted by secure data entry device <NUM> to server <NUM>.

Steps <NUM> and <NUM> are the same as steps <NUM> and <NUM>, respectively, and so are not described in further detail here. It is preferred that, in step <NUM>, the request message includes an indication that secure data entry device <NUM> is operating in identity verification mode. The indication can be of the type discussed earlier in connection with step <NUM>.

In step <NUM>, secure data entry device <NUM> receives a response from server <NUM> referred to as an authorisation response message. Step <NUM> is the same as step <NUM> and so is not described in further detail here.

In step <NUM>, secure data entry device <NUM> receives an 'identification' message from server <NUM>. The identification message indicates the success or failure of the identity validation process. It will be appreciated that provisioning of payment card <NUM> onto electronic device depends on the success or failure of the identity validation process; specifically, successful validation can result in payment card <NUM> being provisioned onto electronic device <NUM> and unsuccessful validation cannot result in payment card <NUM> being provisioned onto electronic device <NUM>. In this embodiment the identification message simply contains a flag which takes a first value to indicate success and a second, different value to indicate failure. This is however not essential to the invention and the identification message can take any form that is capable of indicating success or failure of an event that is known to the skilled person.

In step <NUM>, secure data entry device <NUM> indicates the success or failure of the identity validation process to the user. In this embodiment this indication takes the form of a message such as "Identification Successful" which is displayed on a display of secure data entry device <NUM>. The invention is however not limited in this respect and any other mechanism for indicating the success or failure of the identity validation process that is known to a skilled person can alternatively be used. For example, a coloured light (e.g. an LED) can be used to indicate success or failure, with a first colour (e.g. green) indicating success and a second colour (e.g. red) indicating failure. Many modifications of this will be apparent to a skilled person having the benefit of the present disclosure.

It will be appreciated that step <NUM> advantageously makes a user aware of the status of the provisioning of payment card <NUM> onto electronic device <NUM>. Additionally, successful provisioning is contingent on the correct secure data being entered into secure data entry device <NUM>, meaning that an unauthorised user should not be able to provision payment card <NUM>. Fraud is thus at least more difficult to perpetrate.

With reference to <FIG>, the operation of electronic device <NUM> according to the second embodiment is the same as the operation of electronic device <NUM> in the first embodiment. To indicate this similarity, elements of <FIG> that are the same as elements of <FIG> have been given the same suffix.

Optionally, in the second embodiment, any of steps <NUM>, <NUM> or <NUM> may additionally comprise electronic device <NUM> transmitting a unique identifier associated with the payment instrument that is being provisioned to card issuer server <NUM>. In the case of payment card <NUM>, the unique identifier is preferably a PAN, but other unique identifiers known to a skilled person may alternatively be used depending on the nature of the payment instrument. Card issuer server <NUM> may store this unique identifier in a database as discussed below in connection with step <NUM> of <FIG>.

Alternatively, card issuer server <NUM> may independently maintain a list of unique identifiers of payment cards on the third path in a database, such that electronic device <NUM> does not need to transmit a unique identifier associated with payment card <NUM> to card issuer server <NUM>. The issuer can determine which payment cards should be on the third path according to any suitable rules.

In either case, preferably the database is configured such that it can be queried by server <NUM> to allow server <NUM> to identify which path a specific payment card is on. A look-up server, which may be card issuer server <NUM> or it may be separate from card issuer server <NUM>, may be provided to allow server <NUM> to query the database. Alternatively, card issuer server <NUM> may be configured to synchronise the database with another database that is accessible to server <NUM>. Preferably the synchronisation occurs in real-time. The synchronisation may be provided by API calls, as known in the art. Various other modifications will be apparent to a skilled person having the benefit of the present disclosure.

Referring to <FIG>, the operation of server <NUM> and card issuer server <NUM> according to the second embodiment is described below. In <FIG>, unlike <FIG> and <FIG>, unless otherwise stated below the same suffixes do not indicate similar or identical operations as a corresponding step in <FIG>.

In step <NUM>, server <NUM> receives a request message that has been transmitted by secure data entry device <NUM> (see step <NUM> of <FIG>). The request message is transmitted from secure data entry device <NUM> to server <NUM> via any available private or public network, e.g. the Internet. As discussed above, the request message contains all of the usual content that one skilled in the art would expect to find in a request message as known in the art. The request message preferably also includes an indication that secure data entry device <NUM> is operating in identity verification mode. This indication may be e.g. a flag that indicates that secure data entry device <NUM> is operating in identity verification mode. However, alternative indications known to the skilled person are also within the scope of the present invention.

In optional step <NUM>, server <NUM> detects the indication that secure data entry device <NUM> is operating in identity verification mode by the presence of the indication discussed in the preceding paragraph. It will be appreciated that, if secure data entry device <NUM> is configured to provide the indication but the indication is not present, server <NUM> treats the transaction as a normal prior art transaction. In this case the method of <FIG> is not followed.

In optional step <NUM>, server <NUM> determines whether a unique identifier corresponding to a payment instrument such as payment card <NUM> can be found in a database. The unique identifier can be any of a PAN, a Payment Account Reference ('PAR'), a tokenised PAN, or a sort-code and account number combination, but this is not essential to the invention and any other unique identifier that can be used to uniquely identify a payment instrument may alternatively be used. The database may be maintained by card issuer server <NUM> in the manner discussed earlier in this specification. In the event that a corresponding unique identifier cannot be found, the method moves to step <NUM> and the transaction is thereafter treated as a normal prior art transaction. If the transaction is specifically an "identification transaction" with the mode set as such, the transaction preferably stops at this point if a unique identifier could not be found.

In the event that a corresponding unique identifier can be found in the database, or in the event that optional step <NUM> is omitted, in step <NUM> server <NUM> transmits the request message to card issuer server <NUM> and in step <NUM> card issuer server <NUM> validates the transaction in the manner well known in the art. It is important to note that, from the perspective of card issuer server <NUM>, this part of the transaction is a normal transaction as known in the art.

Following validation, in step <NUM> card issuer server <NUM> transmits a response message to server <NUM>, where the response message indicates whether the transaction has been approved or declined. This is also well known in the art. Server <NUM> processes the response message and in step <NUM> server <NUM> generates a new 'identification' message, the content of which is based on the response message. It is important to recognise that the identification message is separate from the response message in the sense that a prior art transaction will not produce an identification message. The identification message indicates whether the identity validation succeeded or failed; specifically, if the response message indicates that card issuer server <NUM> authorised the transaction then identity validation is taken to have been successful, and if the response message indicates that card issuer server <NUM> did not authorise the transaction then identity validation is taken to have been unsuccessful. In this embodiment the identification message contains a flag, where server <NUM> is configured to set the flag to a first value that indicates success when the response message indicates that card issuer server <NUM> did authorise the transaction and to set the flag to a second, different value that indicates failure when the response message indicates that card issuer server <NUM> did not authorise the transaction. The invention is however not limited in this respect and any other mechanism for indicating success and failure of identity validation that is known to a skilled person can alternatively be used in identification message.

In step <NUM>, server <NUM> transmits the identification message to card issuer server <NUM>. Card issuer server <NUM> is configured to read the identification message and, in step <NUM>, determine whether identity verification was successful. In this embodiment this involves determining the value of a flag contained in the identity verification message, but the invention is not limited in this respect and alternatives known to the skilled person can be used instead.

In the event that identity verification was successful then the method moves to step <NUM> and the provisioning of payment card <NUM> onto electronic device <NUM> is authorised. This authorisation subsequently causes payment card <NUM> to be provisioned onto electronic device <NUM>.

In the event that identity verification was unsuccessful then the method moves to step <NUM> and the provisioning of payment card <NUM> onto electronic device <NUM> is declined. This prevents payment card <NUM> from being provisioned onto electronic device <NUM>.

Regardless of whether provisioning was declined or authorised, in step <NUM> server <NUM> transmits the outcome of the identification process to secure data entry device <NUM>. In this embodiment this comprises forwarding the identification message generated in step <NUM> to secure data entry device <NUM>. Modifications of this are possible; for example, in an alternative embodiment server <NUM> generates another new message and transmits this to secure data entry device <NUM>. The invention is not limited in this respect and further modifications will become apparent to a skilled person having the benefit of the present disclosure. As discussed above in connection with step <NUM> of <FIG>, secure data entry device <NUM> is configured to indicate the success or failure of the identity validation process to the user. In the event that the identity validation process is successful, the method proceeds to step <NUM> in which card issuer server <NUM> transmits an approval of the provisioning of payment instrument <NUM> to electronic device <NUM>. In this way payment instrument <NUM> is provisioned onto electronic device <NUM>.

It will be appreciated that the second embodiment advantageously allows a payment instrument issuing entity to be confident that a provisioning request was initiated by an authorised user. This is because an unauthorised user should not have been able to supply the user's secure data into secure data entry device <NUM>. This results in failure of the identity validation process, and ultimately prevents provisioning of the payment instrument onto electronic device <NUM>.

<FIG> shows a sequence diagram of the overall system in operation according to the first embodiment. Specifically, the sequence diagram shows the information flow under the situation where a user correctly enters their secure data and provisioning is authorised. The numbers present in <FIG> correspond to the respective steps of <FIG> and <FIG>, and hence description of the steps shown in <FIG> is not repeated here. It will be appreciated that arrow <NUM> would be replaced with arrow <NUM> in <FIG> in the situation under which provisioning is declined by card issuer server <NUM>.

<FIG> shows a sequence diagram of the overall system in operation according to the second embodiment, not forming part of the claimed subject matter. Specifically, the sequence diagram shows the information flow under the situation where a user correctly enters their secure data. The numbers present in <FIG> correspond to the respective steps of <FIG> and <FIG>, and hence description of the steps shown in <FIG> is not repeated here.

Claim 1:
A method of authenticating a request to provision a payment instrument (<NUM>) onto an electronic device (<NUM>), comprising:
a) initiating (<NUM>) a provisioning process on an electronic device (<NUM>), the provisioning process involving the payment instrument, and transmitting a provisioning request message from the electronic device (<NUM>) to a server (<NUM>, <NUM>), the provisioning request message including a unique identifier associated with the payment instrument;
b) receiving (<NUM>) secure data at a secure data entry device (<NUM>), the secure data associated with the payment instrument (<NUM>);
c) determining (<NUM>) whether the received secure data matches secure data stored on a record associated with the payment instrument (<NUM>) and, in the affirmative:
d) transmitting (<NUM>) a request message from the secure data entry device (<NUM>) to a server (<NUM>);
e) receiving the request message at the server (<NUM>, <NUM>);
f) validating the request message at the server (<NUM>, <NUM>);
g) transmitting (<NUM>) a response message to the secure data entry device (<NUM>), wherein the response message indicates success or failure of the validation; and wherein, in the event the validation was successful, the response message includes authorisation data and the method further comprises:
h) receiving (<NUM>) data including the authorisation data at the electronic device (<NUM>), wherein the authorisation data is received either by the electronic device receiving a transmission from the secure data entry device or by the electronic device reading a barcode or Quick Response code generated by the secure data entry device;
i) transmitting (<NUM>) the received data including the authorisation data from the electronic device (<NUM>) to the server (<NUM>, <NUM>) without transmission through the secure data entry device (<NUM>);
j) determining (<NUM>), at the server (<NUM>, <NUM>), whether the data transmitted by the electronic device includes the authorisation data that was included in the response message transmitted to the secure data entry device (<NUM>), and determining whether a provisioning request has been made in connection with the payment instrument (<NUM>); and
k) in the affirmative, transmitting (<NUM>) approval for the request to provision the payment instrument to the electronic device and provisioning the payment instrument onto the electronic device.