WO2018141488A1

WO2018141488A1 - User authorization for cards and contactless payment devices

Info

Publication number: WO2018141488A1
Application number: PCT/EP2018/025032
Authority: WO
Inventors: Ossi Kalevo; Tuomas KÄRKKÄINEN; Jouni Laine
Original assignee: Gurulogic Microsystems Oy
Priority date: 2017-02-03
Filing date: 2018-02-05
Publication date: 2018-08-09
Also published as: GB201701818D0; GB2559384A

Abstract

There is provided a method of performing user authorization for a transaction made at a payment terminal using a payment device. Information about the payment device is received from a backend payment authority arrangement or the payment terminal. An authorization-request message is sent to a mobile communication device of a given user for requesting the user authorization. The payment device is being used by a party other than the given user, while the given user administers the usage of the payment device. A response message indicating whether or not the user authorization has been verified successfully is received from the mobile communication device of the given user. The backend payment authority arrangement or the payment terminal is notified to allow the transaction to be completed, if the user authorization has been verified successfully.

Description

USER AUTHORI ZATI ON FOR CARDS AND CONTACTLESS PAYMENT

DEVI CES

TECHNI CAL Fl ELD

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 of a payment device by a malicious party masquerading as an owner of 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 Ά1 ' into a merchant's payment terminal 'B1', and enters his/her corresponding Personal Identification Number (PIN), and, thereafter, in the second step, the merchant's payment terminal 'B1' 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 'A3' (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. In a UK patent document GB 2523358 A ("A System and Method of Processing a Secure Payment Transaction", Inventor: Seamus Dolan, Applicant: Domulas Limited), there is described a system and method of processing a payment transaction. A purchaser selects a payment transaction option on an e-commerce website checkout page, and enters a unique contact identifier specific to his/her mobile computing device (MCD) on a payment transaction page. The purchaser then receives a transaction payment request (TPR) at his/her MCD, and fulfills the TPR. Subsequently, a TPR fulfillment response is sent to an authentication webserver, which then instructs the e-commerce website and a Payment Service Provider (PSP) server to proceed with the payment transaction. The PSP server then transmits a payment transaction action command to the MCD, after which the purchaser fulfills the payment transaction action command on his/her MCD. Consequently, the MCD sends a payment transaction action fulfillment response to the PSP server, which then processes the payment transaction with the e-commerce website. In a UK patent document GB 2533333 A ("Transaction Authorization" , Inventor: Nicolas David Mackie, Applicant: Visa Europe Limited), there is described a system and method for authorizing electronic payment transactions. A server system receives verification information for verifying a user from a computing device associated with the user. A verification status associated with the user is then set in a memory of the server system. When an authorization request for a payment transaction is received from a payment terminal, the server system identifies the verification status associated with the user based on the user's identifier that is included in the authorization request. The server system then determines whether or not to authorize the payment transaction based on the verification status identified for the user.

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 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, the payment device being used by a party other than the given user, wherein the given user administers the usage of the payment device; 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 the user 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 user 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 user 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 card- issuers 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 different kinds of user authorizations, for example, such as a user authorization by a parent for payment transactions (for example, shopping) done by his/her under-aged child, or a user authorization by a person for payment transactions made by his/her spouse when their right to use a certain account is dependent upon an approval of the 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. As yet another example, a user authorization can be given by a person on behalf of an elder under custody of the person.

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: 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;

(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 the user 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 user 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 user 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.

BRI EF DESCRI PTI ON OF THE DRAW I NGS 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.

DETAI LED DESCRI PTI ON OF EM BODI M ENTS

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 said party 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 I Dentification (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 and efficient means to administer usage of 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 administering 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 is given to an authorized party other than the given user, for example, such as another user who is a secondary user of the payment device (for example, such as a bonus card). As an example, the party other than the given user could be an under-aged child or an elder under custody of the given user, namely an ignorant party who is incapable of making a decision regarding the payment transaction on his/her own. It will be appreciated that the method pursuant to embodiments of the present disclosure is particularly beneficial in a case where an under-aged child or an elder under custody does not understand the consequences of his/her actions, in which case a parental or custodial control is required. As another example, the party other than the given user could be a spouse of the given user, for example, in a case when the spouse is not entitled to execute transactions from a certain account alone, namely without a parallel approval given by the other spouse. It will be appreciated that many more use scenarios can be identified as will be now introduced.

In one example implementation, an under-aged child having a particular payment device that is based on his/her parent's account is not allowed to pay with that particular payment device without the respective parent's authorization. Notably, the actual payment is charged from the parent's, namely the administrator's account. In such a case, the aforementioned method enables the parent (namely, the given user) to administer the usage of that particular payment device by their under-aged child. In another example implementation, an account with which a particular payment device is associated could be the child's own, but requires a user 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.

Optionally, the user authorization is required only when said party's payment transaction (for example, shopping) exceeds a predefined limit. In such a case, the method pursuant to embodiments of the present disclosure is used when the predefined limit is exceeded by said party.

As aforementioned, the method can be implemented also for monitoring elderly people. It is often needed to administer their usage of funds, when they become incapable of understanding the impact of their actions and the value of the money. Typically, in such a case, the elder is declared under custody, and thereafter, the custodian (namely, the given user) is in charge of the user authorization.

Yet another example of the use scenarios of the aforementioned method is administering usage of a payment device associated with a common bank account of two joint account holders (for example, a common bank account of spouses), who are entitled to execute payment transactions therefrom with acceptance from both the account holders (namely, both the spouses). In other words, both the account holders are in charge of the payment transactions, but only together; therefore, an attempt of one account holder to make a payment transaction from the common account needs a user authorization from the other account holder, in order for the transaction to be finalized. It will be appreciated that the user authorization from the other account holder may be required only when the payment transaction exceeds the predefined limit. In other words, in such a case, only transactions exceeding the predefined limit require the user authorization from the other account holder, whereas transactions under the predefined limit (namely, transactions considered as normal) are allowed to be made without any user authorization. It will be appreciated that the practical implementation, namely when the user authorization is required and when the user authorization is not required, boils down always to terms of use related to the account in question. Furthermore, it will be appreciated that many more exemplary implementations are feasible. Still another example of the use scenarios of the aforementioned method is administering usage of a payment device (for example, a corporate card) associated with a corporate account, in which case the user authorization is to be given by a Chief Executive Officer (CEO) or some other person capable of authorizing payments. Yet another example of the use scenarios of the aforementioned method is administering usage of a card (namely, the payment device) given by a social welfare office, for example, for purchasing items for which a commitment of expenditure has been given to a customer of the social welfare office.

In still another example use scenario, the aforementioned method could be optionally implemented to, for example, get a so-called "quickie loan", wherein an attempt to pay with a specific quick loan card (namely, the payment device) requires a user authorization by a certain company offering such quick loans. Optionally, in such a case, a competitive tendering is employed in the process, so that the user authorization is received from the most competitive company, from whose account the loan amount is to be charged instantaneously, wherein said party is to be charged afterwards. It will be appreciated that several use scenarios are feasible where a common aspect is that a payment transaction is to be authorized by a given user, when the payment transaction is made by an authorized party other than the given user. It is not relevant whether the payment transaction is debited or credited from a given account, as long as the payment transaction has been duly authorized. 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) are required to make certain modifications to a given payment transaction procedure 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 party other than the given user, for example, 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, for example, such as an under-aged child or an elder under custody of the given user, or a spouse of the given user. 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 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 a fraudulent usage of a payment device by a malicious party masquerading as an owner of the payment device or an improper usage of the payment device by a person under custody or requiring a parallel approval of the given user, for example, such as an under-aged child or an elder, or a spouse in a position of a co-owner of a common account. The aforementioned method enables the given user to administer the usage of the payment device by the party other than the given user (for example, such as an under-aged child or an elder under custody, or a spouse of the given user). In other words, the method provides an option to the given user to either accept or decline the user authorization for the payment transaction made by the party other than the given user.

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, and thus add value also to various services provided by banks, 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 card- issuers; 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 real- time 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 authorization- request 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).

As an example, a parent could have two or more mobile communication devices, for example, such as a work phone and a private phone, wherein the work phone is to be used during office hours, which may be the time when their child is going to make a payment transaction at a shop. Therefore, the user authorization may be needed to be given from the phone in use at the time of the payment transaction.

Moreover, optionally, the method includes keeping a track of which mobile communication device has been used to perform the user authorization. Optionally, in this regard, the method includes maintaining a log of a given mobile communication device that was used to perform the user 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 user 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 user 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 user 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 or the trusted software application 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 t e 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 bio- credential 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 user 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 (ii). 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 t e 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.

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 willing to accept the user authorization. Such a situation may take place, for example, when a parent or a spouse is busy attending a meeting or the like. 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 bio- credential 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 administering 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.

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, the payment device being used by a party other than the given user, wherein the given user administers the usage of the payment device; (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 the user 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;

Optionally, the payment device includes any one of: a payment card, a 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 I D-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 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 t e 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 administering 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 user 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 t e user 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 administering 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 administering 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 user, 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 ('Β1', 'B2' and 'B3') and the backend payment authority service infrastructure 'C are used for implementing a payment transaction for their respective customers (namely, a party other than the given user), using payment devices (Ά1', Ά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 user.

Optionally, in the first step, the customer (namely, the party other than the given user) enters a payment card Ά1 ' into a merchant's payment terminal 'B1', and enters his/her corresponding PIN, and, thereafter, in the second step, the merchant's payment terminal 'B1' sends, to the backend payment authority service 'C, a transaction authorization request (namely, a confirmation request) including the payment card details. Alternatively, in the first step, the customer (namely, the party other than the given user) 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 'C, the transaction authorization request including the smart card details. Yet alternatively, in the first step, the customer (namely, the party other than the given user) places a contactless payment device 'A3' (for example, such as a mobile phone or a smart watch) 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 'C, the transaction authorization request including the payment device details.

The backend payment 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. Before generating an approval code, the backend payment authority service 'C delivers an authorization request to the payment device register service Ό', which then sends, to the registered mobile communication device Έ' of the given user, 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 'C to either approve or decline the transaction. If the payment device register service 'D' notifies the backend payment authority service 'C to approve the transaction, the backend payment 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 customer (namely, the party other than the given user).

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 'C checking that there is a sufficient amount of liquid funds or credit in the bank account of the person whose account is being charged. Optionally, such checking, namely "funds confirmation" , is performed after the user authorization. Alternatively, optionally, such checking is performed prior to the user 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 user 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 user authorization by a person who administers the usage 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 ('Β1', 'B2' and 'B3') and at least one mobile communication device of a given user, 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 + D' in FIG.4.

When a transaction is initiated by a customer (namely, a party other than the given user) at the payment terminal ('Β1', 'B2' or 'B3'), the payment terminal ('Β1', '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, t e server arrangement 'C+ D' sends, to the given user'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 ('Β1', 'B2' or 'Β3') to either approve or decline the transaction. When the server arrangement 'C+D' notifies the payment terminal ('Β1', '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, t e free encyclopedia (accessed January 27,

2017); URL: https://en.wikipedia.org/wiki/EIVIV

[2] Trusted execution environment - Wikipedia, the free encyclopedia

(accessed January 27, 2017); URL: https://en.wikipedia.org/wiki/Trusted execution environment

Claims

CLAI MS 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;

(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 the user 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 user authorization has been verified successfully; and (iv) notifying t e backend payment authority arrangement or the payment terminal to allow the transaction to be completed, if the user 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 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 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 user 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:

(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;

(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 the user 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 t e at least one mobile communication device of the given user, a response message indicating whether or not the user authorization has been verified successfully; and

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:

(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 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 claim 9, 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 t e 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 user 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 claims 9 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 claims 9 to 14, characterized in that the 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 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.