Patent Description:
The development of plastic payment cards necessitated the presence of specialized hardware to accept payments. The electronic POS devices are used in retail for performing such electronic payments. These devices are typically hardware devices provided by the payment processing entities. Some of the POS devices require a wired connection to banks and are used for processing payments only. Even the advanced POS devices, which may have additional functionalities, still require additional hardware.

The recent tendencies aim at allowing merchants to accept payments from contactless cards through mobile smart phones or other personal mobile communication devices without the need for additional or modification of the existing hardware. Payments can be accepted on any mobile smart phone or another personal mobile communication device (tablet, computer, etc) if it has the necessary characteristics. For example, different communication interfaces, such as NFC®, FeliCa® could be utilized for the communication with the contactless cards. There is no need for additional or modification of the existing hardware in the personal mobile communication devices. However, the use of a personal mobile communication device presumes much higher security measures compared to the stand-alone POS devices.

Related work in the area is provided as follows. Ian LO (<CIT>) describes "Systems and methods for implementing a Point-of-Sale device using a smartphone or tablets without hardware add-ons. The smartphone-based system accepts card payments through the mobile device by either tapping a Near Field Communication (NFC) enabled payment card to the device or by using the device's other features such as its camera to read a card's number or a keyboard to manually input a card's information. <CIT> relates to methods and systems for securely processing remote payment transactions using mobile devices. It describes techniques that use secure elements, encrypted communications, dynamic authentication data, and remote key management to protect sensitive payment credentials during transmission.

There is a need to provide a secure environment for such payments performed through personal mobile communication devices. The problem is solved by the subject matter of the independent claims.

According to one aspect, a client comprising an application for secure payment transactions, the application run on a personal mobile communication device is provided. The client is defined in claim <NUM>.

A client is a piece of computer hardware or software that may access a service made available by another piece of computer hardware of software called server. A client may be or comprise a software application or application in short, which is a set of operations for a computer to perform and designed to fulfil a specific function directly for the user or another application.

The client performs secure payment transactions by means of its own instructions and the functionalities of the personal mobile communication device (PMCD), on which it is run. A PMCD may be any kind of mobile communication device, such as a smart phone a tablet, etc. The term "personal" is intended to distinguish a PMCD from an ordinary POS terminal. The communication interfaces of the PMCD are utilized to substitute the known in the art POS terminals. A secure storage of the PMCD may be used to store any sensitive data.

Upon initial sign-up in the application for secure payment transactions, the client generates a public and a private key pair. These keys are a part of asymmetric encryption that encodes information. A message sender encrypts the message with the public key and the receiver decrypts it with the private key. Public and private key pair helps to encrypt information that ensures data is protected during transmission. The generated private key is stored in a secure storage on the PMCD. The secure storage may be a hardware secure storage according to one embodiment or a software secure storage, according to another embodiment.

An attestation request that follows the initial sign-up allows a trusted device (e.g. here the PMCD) to present reliable evidence to remote parties (e.g. here the terminal management server) about the application. In one embodiment, the attestation request includes the public key generated previously, wherein the public key is signed with an application certificate thus providing evidence about the origin of the application on the PMCD. Ensuring that the provided public key is signed with the trusted certificate, this public key is used to encrypt a device key, which is sent back encrypted from the terminal management server (TMS) to the client. The received device key is stored encrypted in a secure storage on the PMCD.

In one embodiment, the attestation request may also include a mobile communication device ID and login credentials. Login credentials are used for identification. They usually consist of a user ID and password. A mobile communication device ID is a unique ID for a particular PMCD and together with the application certificate provide reliable evidence that the login credentials are coming from a trusted PMCD and client respectively.

When there is an intent on user's end to perform a payment through the client, then log-in is performed and an authorization session token from the terminal management server is received.

Then a request for payment transaction is received at the application for secure transactions. In order to initiate the payment, a contactless card is read by the application for secure payment transactions using a communication interface of the PMCD. In one embodiment, the communication interface is Near Field Communication, adopted to get the card data upon tapping the contactless card on the PMCD when requested to.

Further, the client sends payment information to a payment gateway of the terminal management server for processing, wherein the payment information comprises payment data, contactless card data, the authorization session token and last transaction token, and wherein the payment information is encrypted with the device key, and wherein the device key is decrypted using the private key prior to being used for encrypting the payment information. A payment gateway is a merchant service provided by an e-commerce application service provider that authorizes card payments. The payment data includes amount of the transaction and information for the involved parties in the transaction. The contactless card data includes data for identification of the card being used for paying the transaction.

The last transaction token is a token generated during a previous successful transaction from the application for secure payment transactions run on PMCD.

The number of tokens and encryptions ensure a secure environment for the initiated payment regarding all the involved sensitive data in the payment information.

In one embodiment, the client is further configured to receive one or more PIN certificates from the terminal management server upon attestation and store the one or more PIN certificates in the secure storage. The PIN certificates are used for additional security measure in case a transaction amount is beyond a predefined limit. In such case the payment information further includes a PIN block data and the PIN block data comprises a PIN associated with the contactless card, the PIN encrypted with a certificate from the one or more PIN certificates respective to an issuer of the contactless card.

After the payment information is sent to the payment gateway, the payment information is deleted from the application for secure payment transaction, which is run on the PMCD.

If the transaction is approved, then a response is received at the client with a notification from the payment gateway for execution of the payment transaction. Then a renewed last transaction token generated by the payment gateway is received and substitutes the previous last transaction token.

If the payment transaction is rejected, then a response from the payment gateway with a notification for the rejection is received at the client.

According to another aspect of the invention, a terminal management server for secure payment transactions is provided as defined in claim <NUM>.

The terminal management server (TMS) provides secure payment transactions for a client. The client may comprise an application for secure payment transactions run on a PMCD. In order to provide initially access to the client, the TMS registers a mobile communication device ID respective to a PMCD, and also login credentials to be associated with the mobile communication device ID. The TMS also receives an attestation request from the client, which includes a public key for encryption, generated by the client. The public key is signed by an application certificate. TMS processes the request by performing attestation of the mobile communication device ID and the application certificate and upon attestation, TMS generates a device key for the client, which is sent to the client encrypted with the public key.

When client performs log-in, TMS sends an authorisation session token to the client to be used for the session. Then TMS receives payment information from the client for processing, the information being received at a payment gateway of the TMS. The payment information includes payment data, contactless card data, the authorization session token and a last transaction token and the payment information is encrypted with the device key. TMS decrypts the received payment information and checks the authorization session token and the last transaction token by comparing if they are the valid ones and upon match of the tokens, TMS sends the payment information for processing to a card processor.

The card processor either approves the payment transactions or rejects it. An approval triggers the payment gateway to send a response to the client for execution of the payment transaction, following generation of a renewed last transaction token, sending the renewed last transaction token to the client and substituting the last transaction token with the renewed one for subsequent transactions.

A rejection of the payment transaction by the card processor triggers the payment gateway to send a response with a notification for a rejection to the client.

In one embodiment the attestation request includes also the mobile communication ID and the login credentials.

In one embodiment, the TMS is configured to send one or more PIN certificates to the client upon attestation.

In one embodiment, the payment information further includes a PIN block data, when a transaction amount is beyond a predefined limit, and wherein the PIN block data comprises a PIN associated with a contactless card used by the client for the payment transaction, the PIN encrypted with a certificate from the one or more PIN certificates respective to an issuer of the contactless card.

According to another aspect of the invention, a computer implemented method for secure payment transactions is provided as defined in claim <NUM>.

In one embodiment, the attestation request may also include a mobile communication device ID and login credentials.

In one embodiment, one or more PIN certificates are received by the client from the terminal management server upon attestation and the one or more PIN certificates are stored in the secure storage. The PIN certificates are used for additional security measure in case a transaction amount is beyond a predefined limit. In such case the payment information further includes a PIN block data and the PIN block data comprises a PIN associated with the contactless card, the PIN encrypted with a certificate from the one or more PIN certificates respective to an issuer of the contactless card.

In one embodiment, the communication interface is Near Field Communication.

Details of exemplary embodiments are set forth below with reference to the exemplary drawings. Other features will be apparent from the description, the drawings, and from the claims. It should be understood, however, that even though embodiments are separately described, single features of different embodiments may be combined to further embodiments.

A detailed description of examples will be provided with reference to the drawings. It should be understood, however, that various modifications to the examples may be made. Unless explicitly indicated otherwise, elements of one example may be combined and used in other examples to form new examples.

<FIG> depicts a system for secure payment transactions. The system includes a client <NUM>, a terminal management server (TMS) <NUM>, and a card processor <NUM>. The client <NUM> may include an application for secure payment transactions (ASPT) <NUM>, which runs on a personal mobile communication device (PMCD) <NUM>.

A client, such as client <NUM>, is a piece of computer hardware or software that may access a service made available by another piece of computer hardware of software called server (e.g. TMS <NUM>). A client may be or comprise a software application or application in short, which is a set of operations for a computer to perform and designed to fulfil a specific function directly for the user or another application.

The client <NUM> performs secure payment transactions by means of its own instructions and the functionalities of the PMCD <NUM>, on which it is run. A PMCD may be any kind of mobile communication device, such as a smart phone a tablet, etc. The term "personal" is intended to distinguish a PMCD from an ordinary POS terminal. The communication interfaces of the PMCD may be utilized to substitute the known in the art POS terminals. A secure storage (SS) <NUM> of the PMCD <NUM> may be used to store any sensitive data.

The terminal management server (TMS) <NUM> provides secure payment transactions for the client <NUM>. In order to provide initially access to the client <NUM>, the TMS registers a mobile communication device ID respective to a PMCD <NUM>, and also login credentials to be associated with the mobile communication device ID.

Upon initial sign-up in the ASPT <NUM>, the client <NUM> generates a public and a private key pair. These keys are a part of asymmetric encryption that encodes information. A message sender encrypts the message with the public key and the receiver decrypts it with the private key. Public and private key pair helps to encrypt information that ensures data is protected during transmission.

The generated private key is stored in a SS <NUM> on the PMCD <NUM>. The secure storage <NUM> may be a hardware secure storage according to one embodiment or a software secure storage, according to another embodiment.

An attestation request that follows the initial sign-up allows a trusted device (e.g. here the PMCD <NUM>) to present reliable evidence to remote parties (e.g. here the TMS <NUM>) about the ASPT <NUM>. In one embodiment, the attestation request includes the public key generated previously, wherein the public key is signed with an application certificate thus providing evidence about the origin of the APST <NUM> on the PMCD <NUM>. Ensuring that the provided public key is signed with the trusted certificate, this public key is used to encrypt a device key, which is sent back encrypted from the TMS <NUM> to the client <NUM>. The received device key is stored encrypted in a secure storage <NUM> on the PMCD <NUM>.

When there is an intent on user's end to perform a payment through the client <NUM>, then log-in is performed and an authorization session token from the terminal management server <NUM> is received.

Then, a request for payment transaction is received at the APST <NUM>. In order to initiate the payment, a contactless card <NUM> is read by the application for secure payment transactions <NUM> using a communication interface of the PMCD <NUM>. In one embodiment, the communication interface is Near Field Communication, adopted to get the card data upon tapping the contactless card <NUM> on the PMCD <NUM> when requested to.

Further, the client <NUM> sends payment information to a payment gateway <NUM> of the terminal management server <NUM> for processing, wherein the payment information comprises payment data, contactless card data, the authorization session token and last transaction token, and wherein the payment information is encrypted with the device key, and wherein the device key is decrypted using the private key prior to being used for encrypting the payment information. A payment gateway, such as payment gateway <NUM>, is a merchant service provided by an e-commerce application service provider that authorizes card payments. The payment data includes amount of the transaction and information for the involved parties in the transaction. The contactless card data includes data for identification of the card being used for paying the transaction.

The last transaction token is a token generated during a previous successful transaction from the application for secure payment transactions <NUM> run on PMCD <NUM>.

In one embodiment, the client <NUM> is further configured to receive one or more PIN certificates from the terminal management server <NUM> upon attestation and store the one or more PIN certificates in the secure storage <NUM>. The PIN certificates are used for additional security measure in case a transaction amount is beyond a predefined limit. In such case the payment information further includes a PIN block data and the PIN block data comprises a PIN associated with the contactless card <NUM>, the PIN encrypted with a certificate from the one or more PIN certificates respective to an issuer of the contactless card <NUM>.

After the payment information is sent to the payment gateway <NUM>, the payment information is deleted from the application for secure payment transaction <NUM>, which is run on the PMCD <NUM>.

TMS <NUM> decrypts the received payment information through its payment gateway <NUM> and checks the authorization session token and the last transaction token by comparing if they are the valid ones and upon match of the tokens, TMS <NUM> (through its payment gateway <NUM>) sends the payment information for processing to a card processor <NUM>.

The card processor <NUM> either approves the payment transaction or rejects it. An approval triggers the payment gateway <NUM> to send a response to the client <NUM> for execution of the payment transaction, following generation of a renewed last transaction token, sending the renewed last transaction token to the client <NUM> and substituting the last transaction token with the renewed one for subsequent transactions.

A rejection of the payment transaction by the card processor <NUM> triggers the payment gateway <NUM> to send a response with a notification for a rejection to the client <NUM>.

<FIG> and <FIG> show a flow diagram <NUM> of a method for secure payment transactions. The method comprises running by a client <NUM>, an application for secure payment transactions <NUM> on a personal mobile communication device <NUM>. At <NUM>, upon initial sign-up, a public and a private key pair are generated, and the private key is stored in a secure storage <NUM> on the PMCD <NUM>. At <NUM>, an attestation request is sent to a TMS <NUM>. The attestation request comprises the public key signed with an application certificate. At <NUM>, upon attestation, a device key is received from the TMS <NUM>. The device key is encrypted with the public key. At <NUM>, the device key is stored in the secure storage <NUM>. At <NUM>, upon log-in, an authorization session token is received from the TMS <NUM>. At <NUM>, a request for payment transaction is received at the application for secure payment transactions <NUM>. At <NUM>, a contactless card <NUM> is read by the ASPT <NUM> using a communication interface of the PMCD <NUM>. At <NUM>, payment information is sent to a payment gateway <NUM> of the TMS <NUM> for processing. The payment information includes payment data, contactless card data, the authorization session token and last transaction token. The payment information is encrypted with the device key, which is decrypted using the private key prior to being used for encrypting the payment information. At <NUM>, the sent payment information is deleted from the ASPT <NUM> run on the PMCD <NUM>. At <NUM>, a check is performed, whether a card processor (CP) <NUM>, approves the payment transaction. If card processor <NUM> approves the payment transaction at <NUM>, then at <NUM>, a response is received with a notification from the payment gateway <NUM> for execution of the payment transaction. The approved transaction also triggers receiving, at <NUM>, a renewed last transaction token from the payment gateway <NUM> and, at <NUM>, the last transaction token is substituted with the renewed last transaction token. If card processor <NUM> rejects the payment transaction at <NUM>, then, at <NUM>, a response from the payment gateway <NUM> is received with a notification for the rejection.

<FIG> depicts an example sequence diagram regarding the communication between the entities in <FIG> performing secure payment transactions. The entities comprise the client <NUM>, the terminal management server (TMS) <NUM> and the card processor <NUM>. The payment gateway <NUM> within the TMS <NUM> is not depicted for simplicity, being part of the TMS <NUM> and thus the activities of the payment gateway <NUM> regarding transmitted massages related to the payment transaction will be referred to as performed by the TMS <NUM>.

Upon initial sign-up <NUM> by the client <NUM> to the TMS <NUM>, TMS <NUM> returns login credentials <NUM> for the client <NUM>. In one embodiment, the login credentials are provided to the client <NUM> by means of an SMS message to the mobile communication device, on which the client runs,.

The attestation request <NUM> from the client <NUM> to the TMS <NUM> comprises a public key part of a public private key pair generated by the client <NUM>, the public key signed with an application certificate. In one embodiment, the attestation request may also include the login credentials and a mobile communication device ID, unique for the mobile communication device on which the client <NUM> runs. In response to the attestation request <NUM>, TMS sends a device key <NUM> encrypted with the public key.

Upon each log-in <NUM> of the client <NUM> to the TMS <NUM>, TMS returns an authorization session token <NUM> to be used for the session.

When payment information <NUM> is sent from the client <NUM> to the TMS <NUM>, TMS checks the validity of the included tokens and other verifiers of the information and its origin, such as valid encryption/decryption, and forwards the payment information <NUM> to the card processor <NUM>. The card processor <NUM> either approves or rejects the payment, which is notified via the response <NUM> from the card processor <NUM> to the TMS <NUM>. Then a forwarded response <NUM> is sent from the TMS to the client, informing the client <NUM> for the approval/rejection of the payment. Upon approval of the payment, this also triggers updating the last transaction token to be used for a subsequent payment transaction by the client <NUM>. The renewed last transaction token <NUM> is sent from the TMS to the client <NUM>.

Some embodiments of the invention may include the above-described methods being written as one or more software components. These components, and the functionality associated with each, may be used by client, server, distributed, or peer computer systems. These components may be written in a computer language corresponding to one or more programming languages such as, functional, declarative, procedural, object-oriented, lower level languages and the like. They may be linked to other components via various application programming interfaces and then compiled into one complete application for a server or a client. Alternatively, the components maybe implemented in server and client applications. Further, these components may be linked together via various distributed programming protocols. Some example embodiments of the invention may include remote procedure calls being used to implement one or more of these components across a distributed programming environment. For example, a logic level may reside on a first computer system that is remotely located from a second computer system containing an interface level (e.g., a graphical user interface). These first and second computer systems can be configured in a server-client, peer-to-peer, or some other configuration. The clients can vary in complexity from mobile and handheld devices, to thin clients and on to thick clients or even other servers.

The above-illustrated software components are tangibly stored on a computer readable storage medium as instructions. The term "computer readable storage medium" should be taken to include a single medium or multiple media that stores one or more sets of instructions. The term "computer readable storage medium" should be taken to include any physical article that is capable of undergoing a set of physical changes to physically store, encode, or otherwise carry a set of instructions for execution by a computer system which causes the computer system to perform any of the methods or process steps described, represented, or illustrated herein. Examples of computer readable storage media include, but are not limited to: magnetic media, such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROMs, DVDs and holographic devices; magneto-optical media; and hardware devices that are specially configured to store and execute, such as application-specific integrated circuits ("ASICs"), programmable logic devices ("PLDs") and ROM and RAM devices. Examples of computer readable instructions include machine code, such as produced by a compiler, and files containing higher-level code that are executed by a computer using an interpreter. For example, an embodiment of the invention may be implemented using Java, C++, or other object-oriented programming language and development tools. Another embodiment of the invention may be implemented in hard-wired circuitry in place of, or in combination with machine readable software instructions.

<FIG> is a block diagram of an exemplary computer system <NUM>. The computer system <NUM> includes a processor <NUM> that executes software instructions or code stored on a computer readable storage medium <NUM> to perform the above-illustrated methods of the invention. The computer system <NUM> includes a media reader <NUM> to read the instructions from the computer readable storage medium <NUM> and store the instructions in storage <NUM> or in random access memory (RAM) <NUM>. The storage <NUM> provides a large space for keeping static data where at least some instructions could be stored for later execution. The stored instructions may be further compiled to generate other representations of the instructions and dynamically stored in the RAM <NUM>. The processor <NUM> reads instructions from the RAM <NUM> and performs actions as instructed. According to one embodiment of the invention, the computer system <NUM> further includes an output device <NUM> to provide at least some of the results of the execution as output including, but not limited to, visual information to users and an input device <NUM> to provide a user or another device with means for entering data and/or otherwise interact with the computer system <NUM>. Each of these output devices <NUM> and input devices <NUM> could be joined by one or more additional peripherals to further expand the capabilities of the computer system <NUM>. A network communicator <NUM> may be provided to connect the computer system <NUM> to a network <NUM> and in turn to other devices connected to the network <NUM> including other clients, servers, data stores, and interfaces, for instance. The modules of the computer system <NUM> are interconnected via a bus <NUM>. Computer system <NUM> includes a data source interface <NUM> to access data source <NUM>. The data source <NUM> can be accessed via one or more abstraction layers implemented in hardware or software. For example, the data source <NUM> may be accessed by network <NUM>.

Claim 1:
A client (<NUM>) comprising an application for secure payment transactions (<NUM>), the application (<NUM>) run on a personal mobile communication device (<NUM>), wherein the client (<NUM>) is configured to:
upon initial sign-up, generate a public and a private key pair and store the private key in a secure storage (<NUM>) on the personal mobile communication device (<NUM>);
send an attestation request to a terminal management server (<NUM>), wherein the attestation request comprises the public key signed with an application certificate;
upon attestation, receive a device key from the terminal management server, wherein the device key is encrypted with the public key;
store the device key in the secure storage (<NUM>);
upon log-in, receive an authorization session token from the terminal management server (<NUM>);
receive a request for payment transaction at the application for secure payment transactions (<NUM>);
read a contactless card (<NUM>) by the application for secure payment transactions (<NUM>) using a communication interface of the personal mobile communication device (<NUM>);
send payment information to a payment gateway (<NUM>) of the terminal management server (<NUM>) for processing, wherein the payment information comprises payment data, contactless card data, the authorization session token and a last transaction token, wherein the last transaction token is a token generated during a previous successful transaction from the application for secure payment transactions (<NUM>), and wherein the payment information is encrypted with the device key, and wherein the device key is decrypted using the private key prior to being used for encrypting the payment information;
delete the sent payment information from the application for secure payment transactions (<NUM>) run on the personal mobile communication device (<NUM>);
upon approval of the payment transaction:
receive a response with a notification from the payment gateway (<NUM>) for execution of the payment transaction;
receive a renewed last transaction token from the payment gateway (<NUM>); and
substitute the last transaction token with the renewed last
transaction token;
or
upon rejection of the payment transaction, receive a response from the payment gateway (<NUM>) with a notification for the rejection.