GB2559384A

GB2559384A - User authorization for cards and contactless payment devices

Info

Publication number: GB2559384A
Application number: GB1701818.5A
Authority: GB
Inventors: Kalevo Ossi; Karkkainen Tuomas
Original assignee: Gurulogic Microsystems Oy
Current assignee: Gurulogic Microsystems Oy
Priority date: 2017-02-03
Filing date: 2017-02-03
Publication date: 2018-08-08
Also published as: WO2018141488A1; GB201701818D0

Abstract

Method and system for authorising a transaction at a payment terminal B1, B2, B3 using a payment device A1, A2, A3. Information about the payment device is received from a backend payment authority arrangement C or the payment terminal. The authorisation is carried out via a mobile communications device E, the access is authorised through the use of a personal identification code and/or a bio-credential of a customer. An authorisation request message is sent using real-time push signalling for activating the mobile communications device or an application on a user device. A response message indicating the authorisation has been verified successfully is sent by the mobile communications device. The backend payment authority arrangement or the payment terminal is notified of the verification thereby allowing the transaction to be completed. The payment device may be a contactless payment card or a smart card. The bio-credential may be a fingerprint.

Description

(54) Title ofthe Invention: User authorization for cards and contactless payment devices Abstract Title: User authorisation at a payment terminal (57) Method and system for authorising a transaction at a payment terminal B1, B2, B3 using a payment device A1, A2, A3. Information about the payment device is received from a backend payment authority arrangement C or the payment terminal. The authorisation is carried out via a mobile communications device E, the access is authorised through the use of a personal identification code and/or a bio-credential of a customer. An authorisation request message is sent using real-time push signalling for activating the mobile communications device or an application on a user device. A response message indicating the authorisation has been verified successfully is sent by the mobile communications device. The backend payment authority arrangement or the payment terminal is notified of the verification thereby allowing the transaction to be completed. The payment device may be a contactless payment card or a smart card. The bio-credential may be a fingerprint.

1/4

Backend Seller Customer

A1 1	γ	1 ^A2 1
	1	z	1

A3

C

FIG. 1 (Prior Art)

2/4

Service

Provider

FIG. 2A

o

FIG. 2B

FIG. 2C

3/4

Backend Seller I Customer yu ^--------Device

Register

-------D

B3

B1

B2a

Payment

Authority

FIG. 3

4/4

Backend Seller Customer

B3

B1

>

=□

Payment Authority +

Device Register

C+D

FIG. 4

USER AUTHORIZATION FOR CARDS AND CONTACTLESS PAYMENT DEVICES

TECHNICAL FIELD

The present disclosure relates to systems for performing user authorization for transactions made at payment terminals using payment cards, smart cards or other contactless payment devices. Moreover, the present disclosure concerns methods of performing user authorization for transactions made at payment terminals using payment cards, smart cards or other contactless payment devices. Furthermore, the present disclosure also relates to computer program products comprising a non-transitory computer-readable storage medium having computer-readable instructions stored thereon, the computer-readable instructions being executable by a computerized device comprising processing hardware to execute the aforementioned methods.

BACKGROUND

Several vulnerabilities are known within contemporary payment systems based upon physical cards, chip cards or contactless payment devices. In such payment systems, it is difficult to prevent a fraudulent use of a card or a payment device by a given owner of the card or device. However, it is desirable to prevent all fraudulent uses by a user of a card or a payment device, where the user is not the owner of the card or the payment device. Sometimes, use by a non-owner of a card or a payment device may not be fraudulent, though, for example in cases where an under-aged child uses his/her parent's card or payment device for making a payment transaction.

Ever since credit and debit cards have existed, there have been different techniques to verify payment transactions made using such cards, for example via a phone call confirmation, via a modem communication using a dedicated payment confirmation infrastructure to a Card Authority (CA), and more recent techniques such as an automatically executed card payment verification from a given merchant's payment terminal using a data communication network such as the Internet.

In FIG. 1, there is illustrated a contemporary known manner of making payment transactions between a given customer and a given seller, wherein payment terminals and a Card Authority (CA) service infrastructure are used for performing payment transactions using cards or other contactless payment devices; FIG. 1 represents prior art. In operation, customers interact with sellers when purchasing products and/or services offered by the sellers, and the sellers make use of conventional backend card authority services for implementing payment transactions. Such an approach is less secure because the seller is disposed between the customers and the backend services. For example, untrustworthy sellers can potentially obtain customer card details, for example by using modified eavesdropping card readers or by noting transaction card details manually by visual inspection of the customer cards.

With reference to FIG. 1, a contemporary technique of performing a payment transaction will next be described in greater detail. The technique includes two steps. Optionally, in the first step, a given customer enters a payment card ΆΓ into a merchant's payment terminal 'BI', and enters his/her corresponding Personal Identification Number (PIN), and, thereafter, in the second step, the merchant's payment terminal 'BI' sends, to the backend Card Authority (CA) service 'C', a transaction authorization request (namely, a confirmation request) including the payment card details. Alternatively, in the first step, the given customer places his/her smart card Ά2' on a contactless area of the merchant's payment terminal 'B2', and enters his/her corresponding PIN, and, thereafter, in the second step, the merchant's payment terminal 'B2' sends, to the backend service 'C', the transaction authorization request including the smart card details. Yet alternatively, in the first step, the given customer places a Near-Field Communication (NFC)-compliant payment device Ά3' (for example, such as a mobile communication device) in close spatial proximity to a contactless area of the merchant's payment terminal 'B3', and, thereafter, in the step

C2, the merchant's payment terminal 'B3' sends, to the backend service 'C', the transaction authorization request including the payment device details.

The backend card authority service 'C' then verifies validity of the payment card number (or the payment device number), the type of the transaction and the amount with an issuer of that payment card or payment device. Upon successful verification and authorization from the issuer, the backend card authority service 'C' generates an approval code and sends it to the merchant's payment terminal, which then stores the approval code for the payment transaction to complete the payment transaction with the given customer.

Moreover, it is also known that some Payment Service Providers (PSP's) and card-issuers are operable to send Short Message Service (SMS) messages to a given customer's mobile communication device to request a confirmation to transfer money or to implement a payment transaction.

There arises a contemporary need to extend use of contemporary payment cards, smart cards and other contactless payment devices based upon existing devices and interfaces, until new and more innovative payment techniques are anticipated for the future; however, customers are in general reluctant to adopt such payment techniques. There, therefore, arises an opportunity in the near future to offer better payment services in a more cost effective manner to the customers during a transition time prior to the more innovative payment techniques being adopted, which will take a decade or two to be implemented. Furthermore, there are new kinds of backend payment service providers available, which may differ from the conventional card authorities.

SUMMARY

The present disclosure seeks to provide an improved system for performing user authorization for a transaction made at a payment terminal using a payment device that is easy and fast to use and is cost efficient.

Moreover, the present disclosure seeks to provide an improved method of performing user authorization for a transaction made at a payment terminal using a payment device.

A further aim of the present disclosure is to at least partially overcome at 5 least some of the problems of the prior art, as described in the foregoing.

In a first aspect, embodiments of the present disclosure provide a method of performing user authorization for a transaction made at a payment terminal using a payment device, the method being implemented by a server arrangement that is coupled via a data communication network to a backend payment authority arrangement or the payment terminal and to at least one mobile communication device of a given user owning or administering the payment device, characterized in that the method includes:

(i) receiving, from the backend payment authority arrangement or the payment terminal, information about the payment device using which the transaction is being made;

(ii) sending, to the at least one mobile communication device of the given user, an authorization-request message to be presented to the given user for requesting the given user to provide a personal identification code and/or at least one bio-credential of the given user for verifying authorization, wherein the authorization-request message is sent using real-time push signalling for activating the at least one mobile communication device or a trusted software application on the at least one mobile communication device to present the authorization-request message thereat;

(iii) receiving, from the at least one mobile communication device of the given user, a response message indicating whether or not the authorization has been verified successfully; and (iv) notifying the backend payment authority arrangement or the payment terminal to allow the transaction to be completed, if the authorization has been verified successfully.

Embodiments of the present disclosure are of advantage in that the aforementioned method facilitates enhanced security in a cost-efficient manner, using mobile communication devices of users to authorize payment transactions, thereby allowing Payment Service Providers (PSP's) and cardissuers to build new kinds of business models and card payment related service solutions using already existing EMV (see reference [1]) devices and infrastructure, without new investment requirements for merchants.

In addition, embodiments of the present disclosure enable easy implementation of an authorization by a parent for payment transactions, for example shopping, done by his/her under-aged child, or an authorization by a person for payment transactions made by his/her spouse. Optionally, in such a case, the under-aged child or the spouse is a secondary card holder of a bonus card or a bonus payment device.

In a second aspect, embodiments of the present disclosure provide a system for performing user authorization for a transaction made at a payment terminal using a payment device, the system comprising a server arrangement that is coupled via a data communication network to a backend payment authority arrangement or the payment terminal and to at least one mobile communication device of a given user owning or administering the payment device, characterized in that the server arrangement is operable to:

(i) receive, from the backend payment authority arrangement or the payment terminal, information about the payment device using which the transaction is being made;

(ii) send, to the at least one mobile communication device of the given user, an authorization-request message to be presented to the given user for requesting the given user to provide a personal identification code and/or at least one bio-credential of the given user for verifying authorization, wherein the authorization-request message is to be sent using real-time push signalling for activating the at least one mobile communication device or a trusted software application on the at least one mobile communication device to present the authorization-request message thereat;

(iii) receive, from the at least one mobile communication device of the given user, a response message indicating whether or not the authorization has been verified successfully; and (iv) notify the backend payment authority arrangement or the payment terminal to allow the transaction to be completed, if the authorization has been verified successfully.

In a third aspect, embodiments of the present disclosure provide a computer program product comprising a non-transitory computer-readable storage medium having computer-readable instructions stored thereon, the computer-readable instructions being executable by a computerized device comprising processing hardware to execute a method of the aforementioned first aspect.

Additional aspects, advantages, features and objects of the present disclosure would be made apparent from the drawings and the detailed description of the illustrative embodiments construed in conjunction with the appended claims that follow.

It will be appreciated that features of the present disclosure are susceptible to being combined in various combinations without departing from the scope of the present disclosure as defined by the appended claims.

BRIEF DESCRIPTION OF THE DRAWINGS

The summary above, as well as the following detailed description of illustrative embodiments, is better understood when read in conjunction with the appended drawings. For the purpose of illustrating the present disclosure, exemplary constructions of the disclosure are shown in the drawings. However, the present disclosure is not limited to specific methods and apparatus disclosed herein. Moreover, those in the art will understand that the drawings are not to scale. Wherever possible, like elements have been indicated by identical numbers.

Embodiments of the present disclosure will now be described, by way of example only, with reference to the following diagrams wherein:

FIG. 1 (Prior Art) is a schematic illustration of a contemporary technique of performing a payment transaction involving a payment card or a contactless payment device;

FIGs. 2A, 2B and 2C collectively are a schematic illustration of how a mobile communication device is registered with a server arrangement, in accordance with an embodiment of the present disclosure;

FIG. 3 is a schematic illustration of how a system for performing user authorization is implemented pursuant to an embodiment of the present disclosure; and

FIG. 4 is a schematic illustration of how a system for performing user authorization is implemented pursuant to another embodiment of the present disclosure.

DETAILED DESCRIPTION OF EMBODIMENTS

The following detailed description illustrates embodiments of the present disclosure and ways in which they can be implemented. Although some modes of carrying out the present disclosure have been disclosed, those skilled in the art would recognize that other embodiments for carrying out or practising the present disclosure are also possible.

It will be appreciated that the payment terminal can be a merchant's payment terminal or a Point-Of-Sale (POS) terminal at which a user makes a payment to the merchant in exchange for one or more products and/or services offered by the merchant. It will be appreciated that when implementing embodiments of the present disclosure, existing payment terminals and POS terminals (namely, contemporary payment terminals) do not need any technical modifications or configuration changes to be made thereto, but are only required to send online payment confirmation requests for payment transactions to a concerned card authority, namely the backend payment authority arrangement. Optionally, such online payment confirmation requests are sent using contemporary X.25 or Transmission Control Protocol/ Internet Protocol (TCP/IP) networking. Other types of networking are optionally employed, in addition or as an alternative.

Optionally, the payment device includes any one of: a payment card, a smart card, a contactless smart card, or a contactless payment device. Examples of the payment card include, but are not limited to, a credit card, a debit card, a forex card, a gift card, and a bonus card with the features of any of the aforementioned cards. The term smart card generally refers to any pocket-sized card that has embedded integrated circuits. Smart cards are also commonly known as chip cards. Moreover, the contactless payment device could be implemented by way of a key fob or any handheld device that uses Radio-Frequency IDentification (RFID), Near-Field Communication (NFC), or Magnetic Secure Transmission (MST) for making secure payments. Optionally, the contactless payment device is implemented by way of any one of: an ID-tag, a jewellery item, or a sticker on the user's skin. Alternatively, optionally, the contactless payment device is implemented by way of a mobile phone or a smart watch. It will be appreciated that the payment device pursuant to embodiments of the present disclosure could be any device capable of being used for making payment transactions.

Embodiments of the present disclosure concern a security enhancement to payment-related services within a context of payment transactions made using payment cards, smart cards or other contactless payment devices. The method pursuant to embodiments of the present disclosure enables a given user of a payment device to perform payment confirmation within a payment transaction process in a secure manner, using his/her own registered mobile communication device. Notably, the payment confirmation can also be given to other authorized parties, namely another user who is a secondary user of the payment device, for example, such as a bonus card. For example, a child having a particular payment device that is based on his/her parent's account cannot pay with that particular payment device without the respective parent's authorization. In another example, the account with which a particular payment device is associated could be the child's own, but requires an authorization from the parent to use the particular payment device, namely to charge payment transactions from the account. In other words, the given user, namely the parent, administers the usage of the payment device, and therefore, is in charge of the transactions made with the payment device. In such a case, the actual payment is charged from the parent's, namely the administrator's account.

It will be appreciated that existing contemporary payment terminals and infrastructure can be used for implementing the method pursuant to embodiments of the present disclosure, and therefore, it is possible to implement the aforementioned method within the existing payment and communication infrastructure, thereby avoiding a need to make new investments in infrastructure. Pursuant to embodiments of the present disclosure, only a backend from Payment Service Providers (PSP's) or card issuers (or issuer's of other types of payment devices) is required to make certain modifications to a given payment transaction pertaining to online services, for example pertaining to a payment authority and a device register, which may be implemented as a single entity or separate entities, for example as illustrated in conjunction with FIGs. 3 and 4.

According to an embodiment of the present disclosure, the method includes registering, at the server arrangement, the at least one mobile communication device of the given user prior to performing (i) to (iv).

Optionally, the registering the at least one mobile communication device includes:

(a) providing the at least one mobile communication device with the trusted software application (for example, an App), wherein the trusted software application is installed at the at least one mobile communication device;

(b) receiving, from the at least one mobile communication device, details of the payment device and a Personal Identification Number (PIN) associated with the payment device, wherein the details of the payment device and the personal identification number are to be provided by the given user at the trusted software application executing on the at least one mobile communication device; and (c) verifying the details and the personal identification number received at (b).

It will be appreciated that the trusted software application is to be made available for main mobile communication device ecosystems, for example, such as Android® and iOS®.

Optionally, in this regard, the details of the payment device include a unique identifier of the payment device, for example, such as a card number of a payment card or a smart card. Additionally, optionally, the details of the payment device further include the name of the given user owning the payment device, for example, such as the name of the given user as printed on a payment card or a smart card. More optionally, in a case where the payment device is a bonus card that is being administered by the given user, the details of the payment device include the name of a secondary user, who is optionally a party other than the given user administering the use of the payment device. Yet additionally, optionally, the details of the payment device further include a month and a year of expiry of the payment device, and/or a Card Verification Value (CVV) of the payment device.

Notably, usage of the PIN associated with the payment device during the registration process ensures that not just anyone who has found a lost payment device is able to register that payment device with his/her own mobile communication device.

It will be appreciated that in one embodiment, the payment device such as a card is integrated to the given user's mobile communication device after the completion of the aforementioned registration process. Optionally, in such a case, the given user's mobile communication device is capable thereafter of acting as the payment device, and is usable as the payment device when executing transactions later. In such a case, it is possible for the given user to use his/her bio-credential and/or personal identification code, for example such as a common PIN associated with his/her mobile communication device, for authorizing transactions using all his/her registered cards, even if the cards in the first place have been registered using the PIN of those cards.

It will be appreciated that the aforementioned registration process is an easiest and safest way to enable the given user to change his/her registered mobile communication device or to register multiple mobile communication devices for the same payment device.

The method pursuant to embodiments of the present disclosure potentially offers a possibility to prevent all fraud uses, for example in respect of a payment device, where a given user is not authorized to use the payment device. Thus, embodiments of the present disclosure are potentially very valuable to credit card association of card-issuing banks, for example such as Visa®, MasterCard®, American Express® and similar. For example, it is known and demonstrated how to harvest Personal Identification Numbers (PIN's) and clone magnetic stripes. For some cases, a hidden hardware is used to disable PIN checking on stolen cards. Moreover, in the year 2011, it was disclosed that the vulnerability in EMV is that a Cardholder Verification Method (CVM) downgrade allows arbitrary PIN harvest. All of these purposely-taken fraud actions can be prevented using the method pursuant to the present disclosure, namely by using the mobile communication device of the person owning or administrating the payment device to identify and decline such malpractices. The method pursuant to embodiments of the present disclosure further enables implementing easy and user-friendly way of authorizing transactions made by a secondary card holder, for example. Technology associated with embodiments of the present disclosure complies with new requirements of the revised Payment Services Directive (PSD2) by European Banking Authority (EBA).

The method pursuant to embodiments of the present disclosure is capable, in operation, of providing enhanced security to customers and merchants, wherein:

(i) the authorization-request message to be sent to the given customer's mobile communication device is created only by a backend service provided by, for example, the PSP's or the cardissuers; and (ii) there is no reason to deliver any sensitive information to the given customer's mobile communication device.

Moreover, the method pursuant to embodiments of the present disclosure is easy and fast to use, wherein:

(i) a simple transaction takes place in a given customer's own mobile communication device; and (ii) no separate applications or contracts between the given customer and a given merchant are required.

Furthermore, the method pursuant to embodiments of the present disclosure is cost-effective to implement in practice, wherein the technology pursuant to embodiments of the present disclosure enables association services between card-issuing banks and new business models to be provided that also add value to their customers, for example such as realtime credit offerings to the customers, real-time crediting of purchases, real-time insuring of the purchases, and so forth.

Moreover, according to an embodiment of the present disclosure, the at least one mobile communication device of the given user includes a plurality of mobile communication devices of the given user that are registered with the server arrangement. Optionally, in such a case, the authorizationrequest message is sent to each of the plurality of mobile communication devices of the given user at (ii).

Optionally, in such a case, when the response message is received from any one of the plurality of mobile communication devices at (iii), the method includes sending, to rest of the plurality of mobile communication devices, an instruction to ignore the authorization-request message that was previously sent at (ii).

Moreover, optionally, the method includes keeping a track of which mobile communication device has been used to perform the authorization. Optionally, in this regard, the method includes maintaining a log of a given mobile communication device that was used to perform the authorization and its associated timestamp.

Maintaining such a log over a period of time is particularly beneficial for investigating purposes, for example, in a case when the given user did not perform the authorization himself or herself. Optionally, in this regard, the method includes blocking a given mobile communication device of the given user from which an unauthorized party has made an attempt to perform the authorization, so as to avoid any further abuse. Additionally, optionally, in such a case, the method includes blocking the payment device at least on a temporary basis, when it is found that an unauthorized party has made an attempt to perform the authorization.

Furthermore, it will be appreciated that the real-time push signalling is beneficial for sending the authorization-request message at (ii), because such push signalling activates (namely, awakens) the at least one mobile communication device and displays the authorization-request message to the given user even when a display screen of the at least one mobile communication device is locked. Thus, the real-time push signalling potentially improves the given user's experience.

According to an embodiment of the present disclosure, in order to be able to awaken the at least one mobile communication device via such push signalling, a push notification service provided by an ecosystem of the at least one mobile communication device is required to be enabled on the at least one mobile communication device. Examples of such push notification services include, but are not limited to, Apple® Push Notification service (APNs), Google® Cloud Messaging (GCM), and Windows® Notification Service (WNS).

Optionally, in this regard, such push signalling activates (namely, awakens) the trusted software application on the at least one mobile communication device. This allows the given user to provide the personal identification code and/or the at least one bio-credential of the given user without wasting any time (namely, promptly).

According to another embodiment of the present disclosure, the aforementioned push signalling is implemented by way of a trusted software application that is executing in the background at the at least one mobile communication device, wherein the trusted software application is operable to receive a push signal from the server arrangement to awaken the at least one mobile communication device, and to present the authorization-request message at the at least one mobile communication device in real time or near real time.

Regardless of any specific embodiment of the present disclosure, the method optionally includes generating, at the at least one mobile communication device, an event, for example such as an image or a link, acting as an authorization request for the given user to confirm.

Optionally, in the method, the trusted software application is operable to compare the personal identification code and/or the at least one biocredential provided by the given user with a previously-registered personal identification code and/or at least one bio-credential of the given user, namely a personal identification code and/or at least one bio-credential of the given user previously registered with the trusted software application. Alternatively, optionally, the comparison is performed by the ecosystem of the at least one mobile communication device.

Optionally, the trusted software application is then operable to determine whether or not the authorization has been verified successfully, based upon the comparison.

Optionally, in the method, the response message is received in an encrypted form. Optionally, in this regard, the trusted software application is operable to employ at least one key that is stored in a key store of the at least one mobile communication device to encrypt the response message.

Additionally or alternatively, optionally, the response message is digitally signed using a private key or a certificate associated with the given user.

Optionally, in this regard, the trusted software application is operable to employ a private key or a certificate that is stored in the key store of the at least one mobile communication device to sign digitally the response message.

In other words, the response message may be any one of:

(i) encrypted using the at least one key, (ii) digitally signed using the private key or the certificate, or (iii) both encrypted (using the at least one key) and digitally signed (using the private key or the certificate).

Optionally, by providing the personal identification code and/or the at least one bio-credential, the given user authorizes the trusted software application to sign digitally the content of the response message using his/her own private key (for example, for a Public Key Infrastructure (PKI) equivalent usage). This enables the server arrangement to verify the given user as its registered client, using a public key registered for the given user.

Optionally, the content of the response message is the same as the content of the authorization-request message. Optionally, in such a case, when the response message is digitally signed using a private key and/or a certificate of the key store, the server arrangement is operable to verify that the content of the response message that is received is unchanged from the content of the authorization-request message that was previously sent at (Π).

It will be appreciated that when the response message is received in encrypted form, the method includes decrypting the response message.

Moreover, optionally, the response message is received from the at least one mobile communication device, via secured transportation. Such secured transportation can be implemented, for example, via HyperText Transport Protocol Secure (HTTPS) protocol or Secure Sockets Layer (SSL).

Optionally, the method includes providing the at least one mobile communication device with the key store including keys and/or certificates to be used for encryption and/or decryption purposes and/or signing purposes, respectively. The key store may, for example, be provided by the server arrangement or a trusted third party.

Optionally, in the method, the usage of the key store is protected in operation, such that the contents of the key store are accessible to the trusted software application only. Optionally, in the method, the usage of the key store is protected in operation by a kernel layer of the at least one mobile communication device. Optionally, the kernel layer of the at least one mobile communication device is implemented as a mixture of hardware and software, and is proprietary to the at least one mobile communication device, for example is proprietary to a manufacturer of the at least one mobile communication device. However, it will be appreciated that a protected key store is optionally provided by using other security methods, for example by employing heavy data encryption, or by employing a combination of heavy data encryption following by data obfuscation for securing data, and an inverse of such heavy encryption when recovering data. Obfuscation is optionally achieved by inverting and/or swapping specific bits of data bytes. Such encryption and subsequent obfuscation can provide a degree of data security that potentially approaches that of a one time pad, for practical purposes.

Optionally, the aforementioned trusted software application is operable to interface with other software applications executing in other software layers hosted, in operation, in the at least one mobile communication device. In other words, in operation, various data exchanges occur between the trusted software application executing in the kernel layer and the other software applications executing in the software layers. Optionally, in such a case, the aforementioned trusted software application is protected by security provisions of the kernel layer that are typically more secure than the software layers.

Optionally, in this regard, the trusted software application is executed in a secure area of processing hardware of the at least one mobile communication device. More optionally, the secure area of the processing hardware is implemented by way of Trusted Execution Environment (TEE; see reference [2]).

Moreover, optionally, the method includes aborting the transaction, if no response message is received from the at least one mobile communication device of the given user within a predefined time period. In some examples, the predefined time period optionally is in a range of a few seconds to tens of seconds. In other examples, the predefined time period is optionally longer, and is optionally in a range of tens of seconds to a few minutes. In such cases, an additional feature is optionally provided in the authorization-request message that enables the given user to decline the authorization request, for example, when the given user no longer wants to complete the transaction.

It will be appreciated that when the predefined time period is shorter, there is no need for providing the aforementioned feature, as the at least one mobile communication device is useable again within a short time period, without a need to decline the authorization request. On the other hand, when the predefined time period is too short, there potentially arises a situation where the given user is not able to respond to the authorization request within the time period, even when the given user is interested in completing the transaction. However, for security purposes, it is desirable to define the predefined time period to be as short as practically possible.

Optionally, in the method, the personal identification code is a Personal Identification Number (PIN) code associated with the given user. It will be appreciated that the personal identification code can alternatively be a code that includes alphanumeric characters and/or special characters that can be entered using a keypad of the at least one mobile communication device.

Optionally, the at least one bio-credential of the given user includes at least one of: a fingerprint of the given user, facial features of the given user, iris recognition of the given user, DNA genetic information of the given user. As an example, a fingerprint or a facial image of the given user can be captured via an image sensor of the at least one mobile communication device of the given user. It will be appreciated that the given user's biocredential can alternatively correspond to any other type of biometrical verification feasible in future, for example by employing a bio-sensor to provide a DNA analysis of the user's sweat or sputum. Alternatively, optionally, the at least one bio-credential of the given user includes at least one of: a walking manner of the given user, a writing manner of the given user, a heartbeat pattern of the given user.

Examples of the at least one mobile communication device include, but are not limited to, mobile phones, smart telephones, smart watches, Mobile Internet Devices (MIDs), tablet computers, Ultra-Mobile Personal Computers (UMPCs), phablet computers, Personal Digital Assistants (PDAs), web pads, handheld Personal Computers (PCs), and laptop computers. Some specific examples of such devices include, but are not limited to, iPhone®, iPad®, Android® phone, Android® web pad, Windows® phone, and Windows® web pad.

Moreover, the data communication network can be a collection of individual networks, interconnected with each other and functioning as a single large network. Such individual networks may be wired, wireless, or a combination thereof. Examples of such individual networks include, but are not limited to, Local Area Networks (LANs), Wide Area Networks (WANs), Metropolitan Area Networks (MANs), Wireless LANs (WLANs), Wireless WANs (WWANs), Wireless MANs (WMANs), the Internet, second generation (2G) telecommunication networks, third generation (3G) telecommunication networks, fourth generation (4G) telecommunication networks, fifth generation (5G) telecommunication networks, community networks, satellite networks, sensor networks, and Worldwide Interoperability for Microwave Access (WiMAX) networks.

Furthermore, it will be appreciated that in the method, the server arrangement is implemented to provide a background service for registering payment devices and mobile communication devices associated with users of the payment devices.

According to an embodiment of the present disclosure, the server arrangement is implemented separately from the backend payment authority arrangement. One such embodiment has been illustrated in conjunction with FIG. 3.

According to another embodiment of the present disclosure, the server arrangement is implemented together with the backend payment authority arrangement, namely integrated with the backend payment authority arrangement. Optionally, in such a case, the server arrangement interacts with the payment terminal directly. One such embodiment has been illustrated in conjunction with FIG. 4.

Optionally, the payment device includes any one of: a payment card, a 20 smart card, a contactless smart card, or a contactless payment device. As mentioned earlier, the contactless payment device is optionally implemented by way of any one of: a key fob, an ID-tag, a jewellery item, a sticker on the user's skin, a mobile phone, or a smart watch.

According to an embodiment of the present disclosure, the server 25 arrangement is operable to register the at least one mobile communication device of the given user prior to performing (i) to (iv).

Optionally, when registering the at least one mobile communication device, the server arrangement is operable to:

(a) provide the at least one mobile communication device with the trusted software application;

(b) receive, from the at least one mobile communication device, details of the payment device and a Personal Identification Number (PIN) associated with the payment device, wherein the details of the payment device and the personal identification number are to be provided by the given user at the trusted software application executing on the at least one mobile communication device; and (c) verify the details and the personal identification number received at (b).

It will be appreciated that the server arrangement is operable to provide a background service for registering payment devices and mobile communication devices associated with users of the payment devices.

Moreover, according to an embodiment of the present disclosure, the at least one mobile communication device of the given user includes a plurality of mobile communication devices of the given user that are registered with the server arrangement. Optionally, in such a case, the server arrangement is operable to send the authorization-request message to each of the plurality of mobile communication devices of the given user at (ii).

Optionally, in such a case, when the response message is received from any one of the plurality of mobile communication devices at (iii), the server arrangement is operable to send, to rest of the plurality of mobile communication devices, an instruction to ignore the authorization-request message that was previously sent at (ii).

Optionally, the response message is received in an encrypted form. Additionally or alternatively, optionally, the response message is digitally signed using a private key or a certificate associated with the given user.

Moreover, optionally, the server arrangement is operable to keep a track of which mobile communication device has been used to perform the authorization. Optionally, in this regard, the server arrangement is operable to maintain a log of a given mobile communication device that was used to perform the authorization and its associated timestamp, wherein the log is maintained at a database arrangement of the system that is coupled in communication with the server arrangement.

Optionally, the server arrangement and the database arrangement are implemented by way of cloud computing services.

Optionally, the computer-readable instructions are downloadable from a software application store, for example, from an App store to the computerized device.

Next, embodiments of the present disclosure will be described with reference to figures.

FIGs. 2A, 2B and 2C collectively are a schematic illustration of how a mobile communication device is registered with a server arrangement, in accordance with an embodiment of the present disclosure. In this regard, the server arrangement is operable to provide a background service for registering payment devices and mobile communication devices associated with users of the payment devices.

In FIG. 2A, there is shown a schematic illustration of providing an executable trusted software application to the mobile communication device, via a play market or a service provider. In this regard, the executable trusted software application is downloaded and installed at the mobile communication device, but is not ready for use before completing another step illustrated in FIG. 2B.

In FIG. 2B, there is shown a schematic illustration of receiving details of a given payment device and a PIN associated therewith from the mobile communication device. In this regard, a given user of the payment device enters the payment device details and the PIN at the trusted software application executing on the mobile communication device. The server arrangement receives, from the mobile communication device, the payment device details and the PIN, and verifies the payment device details and the PIN.

Upon successful verification, the server arrangement stores, at a database arrangement (depicted as Device Register in FIG. 2B), information about the mobile communication device registered for the given payment device.

In FIG. 2C, there is shown a schematic illustration of registering the mobile communication device for authorizing payment transactions, pursuant to embodiments of the present disclosure.

FIGs. 2A-C are merely an example, which should not unduly limit the scope of the claims herein. A person skilled in the art will recognize many variations, alternatives, and modifications of embodiments of the present disclosure.

Referring next to FIG. 3, there is shown a schematic illustration of how a system for performing user authorization is implemented pursuant to one embodiment of the present disclosure. The system includes a server arrangement providing a payment device register service 'D' at the backend. The server arrangement is coupled in communication with a backend payment authority service 'C' and at least one mobile communication device of a given customer, depicted as a mobile communication device Έ' in FIG. 3. It will be appreciated that in this case, the server arrangement is implemented separately from the backend payment authority service 'C'.

It will be appreciated that the payment device register (for example, such as a Card Register} can be any type of register of payment devices, and embodiments of the present disclosure are not restricted to usage of cards only.

In contradistinction to the contemporary known arrangement depicted in FIG. 1 and its associated manner of operation, the system pursuant to embodiments of the present disclosure is illustrated in FIG. 3. Thus, in FIG. 3, payment terminals ('BI', 'B2' and 'B3') and the backend payment authority service infrastructure 'C' are used for implementing a payment transaction for their respective customers, using payment devices ('Al', Ά2' and Ά3). Moreover, with respect to FIG. 3, it is feasible to employ existing and invested payment terminals at merchants and payment authority infrastructure from payment service providers.

FIG. 3 will next be described in greater detail. In FIG. 3, there is illustrated a method that employs the same steps as described in the foregoing with respect to FIG. 1, but with additional steps involving the server arrangement providing the payment device register service 'D' and the mobile communication device Έ' of the given customer.

Optionally, in the first step, the given customer enters a payment card Ά1' into a merchant's payment terminal 'BI', and enters his/her corresponding PIN, and, thereafter, in the second step, the merchant's payment terminal 'BI' sends, to the backend payment authority service O', a transaction authorization request (namely, a confirmation request) including the payment card details. Alternatively, in the first step, the given customer places his/her smart card Ά2' on a contactless area of the merchant's payment terminal 'B2', and enters his/her corresponding PIN, and, thereafter, in the second step, the merchant's payment terminal 'B2' sends, to the backend payment authority service O', the transaction authorization request including the smart card details. Yet alternatively, in the first step, the given customer places a contactless payment device Ά3' (for example, such as a mobile communication device) in close spatial proximity to a contactless area of the merchant's payment terminal 'B3', and, thereafter, in the step C2, the merchant's payment terminal 'B3' sends, to the backend payment authority service O', the transaction authorization request including the payment device details.

The backend payment authority service Ό' then verifies validity of the payment card number (or the payment device number), the type of the transaction and the amount with an issuer of that payment card or payment device. Before generating an approval code, the backend payment authority service Ό' delivers an authorization request to the payment device register service 'D', which then sends to, the given customer's registered mobile communication device Έ', an authorization-request message using real-time push signaling. Based upon a response message received from the mobile communication device Έ', the payment device register service 'D' notifies the backend payment authority service Ό' to either approve or decline the transaction. If the payment device register service 'D' notifies the backend payment authority service O' to approve the transaction, the backend payment authority service Ό' generates an approval code and sends it to the merchant's payment terminal, which then stores the approval code for the payment transaction to complete the payment transaction with the given customer.

FIG. 3 is merely an example, which should not unduly limit the scope of the claims herein. A person skilled in the art will recognize many variations, alternatives, and modifications of embodiments of the present disclosure. It will be appreciated that completion of a transaction can also include additional steps such as the backend payment authority service Ό' checking that there is a sufficient amount of liquid funds or credit in the bank account of the user or the person whose account is being charged. Optionally, such checking, namely funds confirmation, is performed after the authorization. Alternatively, optionally, such checking is performed prior to the authorization; in such a case, if there is no authorization (namely, approval) of the transaction, then the funds confirmation is not performed, namely is cancelled. However, typically it is beneficial to perform the funds confirmation prior to the authorization, in order to avoid sending unnecessary authorization-request messages to the given user in cases where the funds confirmations are likely to result into cancellations. It should be appreciated that embodiments of the present disclosure concern enabling authorization by a person who is in charge of the payment device, irrespective of such background activities.

It will be appreciated that completion of the transaction can take place, via card (or other payment device) payment, as an account transfer or by utilizing blockchain, for example a blockchain transaction using bit coins.

Referring next to FIG. 4, there is shown a schematic illustration of how a system for performing user authorization is implemented pursuant to another embodiment of the present disclosure. The system includes a server arrangement providing a payment device register service at the backend.

The server arrangement is coupled in communication with payment terminals ('BI', 'B2' and 'B3') and at least one mobile communication device of a given customer, depicted as a mobile communication device Έ' in FIG.

4.

It will be appreciated that in this case, the server arrangement is implemented together with a backend payment authority service, namely is integrated with the backend payment authority service, and is depicted as 'C+D' in FIG. 4.

When a transaction is initiated at the payment terminal ('BI', 'B2' or Έ3'), the payment terminal ('BI', 'B2' or 'B3') sends, to the server arrangement 'C+D', a transaction authorization request including details of a payment device using which the transaction is initiated. The backend payment authority service then verifies validity of the payment device number, the type of the transaction and the amount with an issuer of that payment device.

Before generating an approval code, the server arrangement 'C+D' sends to, the given customer's registered mobile communication device Έ', an authorization-request message using real-time push signaling. Based upon a response message received from the mobile communication device Έ', the server arrangement 'C+D' notifies the payment terminal ('BI', 'B2' or 'B3') to either approve or decline the transaction. When the server arrangement 'C+D' notifies the payment terminal ('BI', 'B2' or 'B3') to approve the transaction, the server arrangement 'C+D' generates an approval code and sends it to the merchant's payment terminal, which then stores the approval code for the payment transaction to complete the payment transaction with the given customer.

FIG. 4 is merely an example, which should not unduly limit the scope of the claims herein. A person skilled in the art will recognize many variations, alternatives, and modifications of embodiments of the present disclosure.

Modifications to embodiments of the present disclosure described in the foregoing are possible without departing from the scope of the present disclosure as defined by the accompanying claims. Expressions such as including, comprising, incorporating, consisting of, have, is used to describe and claim the present invention are intended to be construed in a non-exclusive manner, namely allowing for items, components or elements not explicitly described also to be present. Reference to the singular is also to be construed to relate to the plural; as an example, at least one of' indicates one of' in an example, and a plurality of in another example; moreover, two of, and similarly one or more are to be construed in a likewise manner.

The phrases in an embodiment, according to an embodiment and the like generally mean the particular feature, structure, or characteristic following the phrase is included in at least one embodiment of the present disclosure, and may be included in more than one embodiment of the present disclosure. Importantly, such phrases do not necessarily refer to the same embodiment.

REFERENCES [1] EMV - Wikipedia, the free encyclopedia (accessed January 27, 2017); URL: .httgs.://en.,wjkLpedia,org/wjki/EMV [2] Trusted execution environment - Wikipedia, the free encyclopedia (accessed January 27, 2017); URL:

https://en.wikipedia.org/wiki/Trusted execution environment

Claims

CLAIMS We claim:

1. A method of performing user authorization for a transaction made

5 at a payment terminal using a payment device, the method being implemented by a server arrangement that is coupled via a data communication network to a backend payment authority arrangement or the payment terminal and to at least one mobile communication device of a given user owning or administering the payment device, characterized in

10 that the method includes:

(ii) sending, to the at least one mobile communication device of the

15 given user, an authorization-request message to be presented to the given user for requesting the given user to provide a personal identification code and/or at least one bio-credential of the given user for verifying authorization, wherein the authorization-request message is sent using real-time push signalling for activating the

20 at least one mobile communication device or a trusted software application on the at least one mobile communication device to present the authorization-request message thereat;

(iii) receiving, from the at least one mobile communication device of the given user, a response message indicating whether or not the

25 authorization has been verified successfully; and (iv) notifying the backend payment authority arrangement or the payment terminal to allow the transaction to be completed, if the authorization has been verified successfully.

2. A method of claim 1, characterized in that the method includes registering, at the server arrangement, the at least one mobile communication device of the given user prior to performing (i) to (iv).

3. A method of claim 2, characterized in that the registering the at

5 least one mobile communication device includes:

(a) providing the at least one mobile communication device with the trusted software application;

(b) receiving, from the at least one mobile communication device, details of the payment device and a personal identification number

10 associated with the payment device, wherein the details of the payment device and the personal identification number are to be provided by the given user at the trusted software application executing on the at least one mobile communication device; and (c) verifying the details and the personal identification number

15 received at (b).

4. A method of claim 1, 2 or 3, characterized in that the at least one mobile communication device of the given user includes a plurality of mobile communication devices of the given user that are registered with the server arrangement, wherein when the response message is received from any

20 one of the plurality of mobile communication devices at (iii), the method includes sending, to rest of the plurality of mobile communication devices, an instruction to ignore the authorization-request message sent at (ii).

5. A method of any one of claims 1 to 4, characterized in that the method includes maintaining a log of a given mobile communication device

25 that was used to perform the authorization and its associated timestamp.

6. A method of any one of claims 1 to 5, characterized in that the payment device includes any one of: a payment card, a smart card, a contactless smart card, or a contactless payment device.

7. A method of any one of claims 1 to 6, characterized in that the response message is received in an encrypted form.

8. A method of any one of claims 1 to 7, characterized in that the response message is digitally signed using a private key or a certificate associated with the given user.

9. A system for performing user authorization for a transaction made at a payment terminal using a payment device, the system comprising a server arrangement that is coupled via a data communication network to a backend payment authority arrangement or the payment terminal and to at least one mobile communication device of a given user owning or administering the payment device, characterized in that the server arrangement is operable to:

10. A system of claim 9, characterized in that the server arrangement is operable to register the at least one mobile communication device of the given user prior to performing (i) to (iv).

11. A system of claim 10, characterized in that when registering the at least one mobile communication device, the server arrangement is operable to:

(b) receive, from the at least one mobile communication device, details of the payment device and a personal identification number associated with the payment device, wherein the details of the payment device and the personal identification number are to be provided by the given user at the trusted software application executing on the at least one mobile communication device; and (c) verify the details and the personal identification number received at (b).

12. A system of claim9, 10 or 11, characterized in that the at least one mobile communication device of the given user includes a plurality of mobile communication devices of the given user that are registered with the server arrangement, wherein when the response message is received from any one of the plurality of mobile communication devices at (iii), the server arrangement is operable to send, to rest of the plurality of mobile communication devices, an instruction to ignore the authorization-request message sent at (ii).

13. A system of any one of claims 9 to 12, characterized in that the server arrangement is operable to maintain a log of a given mobile communication device that was used to perform the authorization and its associated timestamp, wherein the log is maintained at a database arrangement of the system that is coupled in communication with the server arrangement.

14. A system of any one of claims9 to 13, characterized in that the payment device includes any one of: a payment card, a smart card, a contactless smart card, or a contactless payment device.

15. A system of any one of claims9 to 14, characterized in that the 5 response message is received in an encrypted form.

16. A system of any one of claims 9 to 15, characterized in that the response message is digitally signed using a private key or a certificate associated with the given user.

17. A computer program product comprising a non-transitory computerreadable storage medium having computer-readable instructions stored thereon, the computer-readable instructions being executable by a computerized device comprising processing hardware to execute a method of any one of claims 1 to 8.

Intellectual

Property

Office

Application No: GB1701818.5 Examiner: Ms Becky Lander

17. A computer program product comprising a non-transitory 10 computer-readable storage medium having computer-readable instructions stored thereon, the computer-readable instructions being executable by a computerized device comprising processing hardware to execute a method of any one of claims 1 to 8.

Amendments to the claims have been filed as follows :We claim:

1. A method of performing user authorization for a transaction made at a payment terminal using a payment device, the method being implemented by a server arrangement that is coupled via a data communication network to a backend payment authority arrangement or the payment terminal and to at least one mobile communication device of a given user owning or administering the payment device, characterized in that the method includes:

(i) receiving, from the backend payment authority arrangement or the payment terminal, information about the payment device using which the transaction is being made, the payment device being used by a party other than the given user, wherein the given user administers the usage of the payment device;

(iii) receiving, from the at least one mobile communication device of the given user, a response message indicating whether or not the authorization has been verified successfully; and t authority arrangement or the payment n to be completed, if the authorization has

Uttl I V^IIII^M OUOOtOOl W I i y .

3. A method of claim 2, characterized in that the registering the at least one mobile communication device includes:

(b) receiving, from the at least one mobile communication device, details of the payment device and a personal identification number associated with the payment device, wherein the details of the payment device and the personal identification number are to be provided by the given user at the trusted software application executing on the at least one mobile communication device; and (c) verifying the details and the personal identification number received at (b).

4. A method of claim 1, 2 or 3, characterized in that the at least one mobile communication device of the given user includes a plurality of mobile communication devices of the given user that are registered with the server arrangement, wherein when the response message is received from any one of the plurality of mobile communication devices at (iii), the method includes sending, to rest of the plurality of mobile communication devices, an instruction to ignore the authorization-request message sent at (ii).

5. A method of any one of claims 1 to 4, characterized in that the method includes maintaining a log of a given mobile communication device that was used to perform the authorization and its associated timestamp.

1 to 5, characterized in that the payment )rd, a smart card, a contactless smart card,

V/l CJ ΌΌΊ HUOlltOO [JUyilltlll

(i) receive, from the backend payment authority arrangement or the payment terminal, information about the payment device using which the transaction is being made, the payment device being used by a party other than the given user, wherein the given user administers the usage of the payment device;

mobile communication device of the given ating whether or not the authorization has

Uttl I V Ά I I I I Ά VI OUOOtOOl W I I y f Ul Id (iv) notify the backend payment authority arrangement or the payment terminal to allow the transaction to be completed, if the authorization has been verified successfully.

9 to 12, characterized in that the server >g of a given mobile communication device

LI I LI L VV LI O U JLU LU [JUI IUI I I I LI IL- LI LI L I IUI I Z_LI L ion and its associated timestamp, wherein the log is maintained at a database arrangement of the system that is coupled in communication with the server arrangement.

15. A system of any one of claims9 to 14, characterized in that the response message is received in an encrypted form.