GB2522235A

GB2522235A - Cashless payment system

Info

Publication number: GB2522235A
Application number: GB1400835.3A
Authority: GB
Inventors: David Paul Graham; Kelvin William Linnau Mckay
Original assignee: PHLOK Ltd
Current assignee: PHLOK Ltd
Priority date: 2014-01-17
Filing date: 2014-01-17
Publication date: 2015-07-22
Also published as: GB201400835D0

Abstract

A method of authenticating a customer 3 to a merchant 6, and a system for doing so comprises the customer identifying a merchant on a customer mobile device 2, providing a payment amount, entering a first check value obtained from the merchant and transmitting the first check value to a server 5 via a communication network 4. Then, at the server, the first check value is received and a lookup is performed to retrieve a second check value, the first check value and second check value being associated with one another. The second check value is transmitted to the device via a communication network. The customer receives the second check value and communicates the second check value to the merchant. When the customer confirms that the second check value is successfully associated with the first check value, the customer is authenticated. The transaction may take place in a merchants premises and positioning data may be used to determine payment of for the transaction when the customer leaves the premises.

Description

CASHLESS PAYMENT SYSTEM

The present invention relates to a method of authenticating a payer to a payee, and to a system for carrying out such a method.

So-called cashless transactions are those that take place in the absence of physical cash or money, and utilise some type of electronic funds transfer. For example, using a credit or debit card or pre-paid credits allows the transfer of funds between a payer and a payee without the need to exchange physical notes or coins. Such transactions therefore lend themselves to being simple to carry out remotely.

Traditionally, when such transactions are carried out in person, the identification of the payer needs to be verified by the authentication of the payer to the payee for the funds to be transferred. In person this is typically done using a Personal Identification Number, or PIN, or by a signature or other device. The verification step involves confirming that the PIN or signature matches a stored value, either visually or by interrogating a memory present on the credit or debit card, such as via a chip or magnetic strip. However, where any element of distance between the payer and the payee is involved there are issues with the security of the transaction process, leading to the need to find alternative methods of verification need to be used to ensure that the payer is authenticated.

One common way of doing this is to provide an authentication step requiring a secret passcode known only to the payer) which is verified by the body holding the funds. For example, online credit/debit card transactions involve the payer providing an authentication code to the credit/debit card provider, who then, acting as a trusted third party, verifies that the transaction may be completed and the funds transferred. Therefore the authentication step takes place between the payer and the card provider, and the verification step between the card provider and the payee. Such a system is relatively complex in that to maintain the security of the transaction only random characters from the secret passcode are transmitted at any one time over a secure network link, and data is encrypted.

In some situations, where there is little network infrastructure or where an alternative payment system is used where there is no card or other payment token issuer involved, it is necessary to find a way in which the payee can be authenticated directly to the payer without the need for a trusted third party or the ability to transmit and store encrypted data or complex data streams. It is also necessary to do with whilst overcoming a perceived lack of security in using unencrypted data or a trusted third party.

The present invention aims to address these issues by providing a method of authenticating a payer to a payee, comprising: a] on a device: the payer identifying a payee, providing a payment amount, entering a first check value obtained from the payee and transmitting the first check value to a server via a communication network; b] at a server: receiving the first check value and performing a lookup to retrieve a second check value, the first check value and second check value being associated with one another, and transmitting the second check value to the device via a communication network; and c) on the device: the payer receiving the second check value and communicating the second check value to the payee; wherein when the payee confirms that the second check value is successfully associated with the first check value, the payer is authenticated.

By using a simple check value system to create a direct authentication between the payer and the payee without the need for verification or direct fund transfer via a trusted third party an effective closed system authentication and payment system can be created. Since such a system is closed and does not involve the direct transfer of funds there is also no need to encrypt any data stored at the server or transmitted via the communications network. Such a system is therefore self-policing from a fraud perspective.

Preferably the payer is a customer and the payee is a merchant. More preferably the authentication takes place at the payee premises.

Preferably, the first and second check values are uniquely associated with one another.

Preferably, the first and second check values are stored and transmitted in plaintext.

A payment between the payer and the payee may complete on authentication.

Alternatively, a payment between the payer and the payee may complete on further confirmation provided by the payer on the device. Alternatively again a payment between the payer and the payee may complete when positioning data shows payer has left the payee's premises. The payment may be redeemed immediately or subsequently by the payee.

The positioning data may also be transmitted with the first check value.

Preferably, the communication network used to transmit the first check value to the server is the same as the communication network used to transmit the second check value to the device.

Preferably, the device is a smartphone.

In another aspect, the present invention provides a system for authenticating a payer to a payee, comprising: a device adapted to enable the payer to identify a payee, provide a payment amount, enter a first check value obtained from the payee, transmit the first check value to a server, receive a second check value and communicate the second check value to the payee; and a server adapted to receive the first check value, perform lookup to retrieve a second check value, the first check value and second check value being associated with one another, and transmit the second check value to the device; wherein the device and the server are in communication with one another via a communication network, and wherein when the payee confirms that the second check value is successfully associated with the first check value, the payer is authenticated.

The present invention will now be described by way of example only, and with reference to the accompanying drawings, in which: Figure 1 is a schematic representation of an authentication system in accordance with a first embodiment of the present invention; Figure 2 is a flow chart showing an authentication method in accordance with a first embodiment of the present invention; Figure 3 is a first schematic screen view showing a step in the authentication method in accordance with a first embodiment of the present invention; Figure 4 is a second schematic screen view showing a further step in the authentication method in accordance with the present invention; Figure 5 is a third schematic screen view showing a yet further step in the authentication method in accordance with the present invention; and Figure 6 is a fourth schematic screen view showing an error step in the authentication method in accordance with the present invention.

In the present invention it has been appreciated that it is possible to set up a simple yet effective method for authenticating a payer to a payee using a system involving a mobile communication device, such as a smartphone, and a server, linked together via a communications network, such as 2G. 2.SG (GPRS), 2.75G (EDGE)) 3G or 4G. In particular, such a method utilises steps on the device of the payer identifiing a payee, providing a payment amount, entering a first check value obtained from the payee and transmitting the first check value to a server. At the server, the first check value is received and a lookup is performed to retrieve a second check value) the first check value and second check value being associated with one another) and transmitting the second check value to the device. Finally, on the device) the payer receives the second check value and communicates the second check value to the payee. When the payee confirms that the second check value is successfully associated with the first check value, the payer is authenticated. The check values are simple combinations of numeric and/or alphabetic characters, easily transferred over a communications network with no encryption. The method is carried out via an application (or App) installed on a device such as a smartphone and downloadable from an online store or via a service provider. To use the method the application is opened and the available options selected and used as desired.

Figure 1 is a schematic representation of an authentication system in accordance with a first embodiment of the present invention. The authentication system 1 comprises a device 2, such as a mobile communication device, in the possession of a payer 3, and in communication via a communications network 4 with a server 5.

The payer 3 is located at a merchant who acts as the payee 6, whereas the server S is located remotely from both the payer 3 and the payee 6, at a trusted third party 7.

The payee 6 is in possession of a database 8 containing a list of first check values and second check values, where each first check value is associated with a second check value. Preferably each first check value is uniquely associated with a second check value, although) as described further below, this is not necessary. The server stores a iookup table 9 containing the same first check values and second check values as the database B located with the payee 6, and associated with each other in the same manner. The server 5 is also used to store details of individual payer 3 and payee 6 accounts. Each payer 3 account contains a number of credits, each credit corresponding to a particular financial denomination, for example £1. Credits are purchased by the payer 3 in advance, via credit card, debit card or other bank transfer method to the trusted third party 7, and may be purchased online, via telephone or other means. This enables goods and services having a particular financial cost to have that cost translated into an appropriate number of credits easily by the payee 6 for use by the payer 3. Afternatively, rather than purchasing credits, the payer 3 can obtain credits as part of a reward or other incentive scheme, as described below. When a transaction is authenticated, using the method described below, the credits are transferred between the payer 3 account and the payee 6 account, with the payee 6 then able to redeem the transferred credits either immediately or subsequently, for the equivalent financial denomination as purchased originally by the payer 3. In this respect the trusted third party 7 therefore acts as a broker, and no actual financial transaction takes place between the payer 3 and the payee 6.

Obtaining credits via a reward or other incentive scheme may be done in a variety of ways. For example, the payer 3 may scan a barcode, QOR code or other device located at a point of sale (PUS) position at the payee's 6 premises. This is done by opening the application on the device 2, and using a camera integral to the device 2 to scan the code. The code equates to a certain number of credits being provided as an incentive to buy goods or services at the payee 6 or as a reward for purchasing goods or services. Alternatively, a "Check-In" button within the application can be used to indicate the payer's 3 presence at a payee's 6 premises on a selected social networking site. This results in an award of credits for enabling advertisement of the payee's 6 premises on a social-networking site. Alternatively again the payer 3 may follow a social network profile of the trusted third party 7 and gain further credits as a reward or incentive for doing so. As yet a further alternative, credits may be awarded as a direct result of a purchase or other transaction, with the number of credits being directly proportional to the financial value of the purchase or transaction, either by having a fixed allocation of credits for set values or by means of an exchange rate principle.

Figure 2 is a flow chart showing an authentication method in accordance with a first embodiment of the present invention. At step 100, a payer 3 initiates a transaction with a payee 6, with the payer 3 being in possession of a device 2, such as a smartphone. In this example, the payer 3 is a customer and the payee 6 is a merchant. The payer 3 initiates the transaction by requesting goods or services from the payee 6. Each good or service has a fiscal value equating to a certain number of pre-paid credits, the value of which is entered into the payer's 3 device 2.

This is illustrated in Figure 3, which is a first schematic screen view showing a step in the authentication method in accordance with a first embodiment of the present invention. A numeric keypad 9 is displayed on the screen 10 of the device, with the number of credits required to make the transaction viewable in the window 11 displayed adjacent the keypad 9. The total number of credits 12 is also displayed adjacent the numeric keypad 9. This value is then transmitted to the server 5, where a check takes place that the number of credits entered by the payer 3 matches the number allocated for the goods or services chosen from the payee 6.

At step 102, the payer 3 is prompted for a first check value. In this example, the first check value is a 4-digit PIN (personal identification number) code, entered using the numeric keypad 9 displayed on the device 2 in a window 11. In this example, the PIN code is 1234. This is illustrated in Figure 4, which is a second schematic screen view showing a step in the authentication method in accordance with a first embodiment of the present invention. The PIN code is obtained from the payee 6, who is provided with a database B containing a plurality of first check values, each of which is associated with a second check value, also stored in the database 8. The database B can be in any suitable format, electronic or otherwise, but in the present example is a booklet of vouchers. Each voucher is pre-printed with both the first and second check values. In this example, each second check value isa collection of alphabetic characters, preferably forming a readable word of limited number of characters, hence each voucher is pre-printed with both a 4-digit PIN code and a 6-character word. The 6-character word is a secret, which is used to authenticate the payer 3 to the payee 6.

At step 104, the PIN code is transmitted to the server S via the communications network 4. Tn this example the same communications network 4 is used for communications from the device 2 to the server 5 and from the server 5 to the device 2. However, it maybe desiraffle to use different communication networks for each transmission, for example) where one transmission is via a cellular communications network and one transmission is via a WiFi or other communications network.

At step 106, the server interrogates a lookup table using a lookup function containing a plurality of first check values, each of which is associated with a second check value. In this example, the PIN code received by the server 5 is associated with an alphabetic word or secret. In order for the payer 3 to be authenticated, the PIN code at the server 5 must be associated with the same alphabetic word as at the payee 6, in other words the first check value at the serverS must be associated with the same second check value as the first check value at the payee 6. An incorrect PIN code may indicate either an error in inputting the code by the payer 3, or that the payer 3 is not buying goods and services at the payee 6 selected. Each payee 6 is provided with a set of first and second check values that are uniquely associated with that payee 6, such that if the first check value received by the server 5 does not match a first check value stored in the lookup table relevant to the payee 6 selected, the authentication does not take place. However) in situations where the payee 6 gives a first check value in error, the server 5 is able to adapt to allow authentication. For example, for a payee 6 having a book of vouchers on which the first and second check values are printed as PIN codes and words, it is possible that vouchers may be used in the wrong order, for example, pages may be stuck together or turned over together in error. If the server 5 receives a first check value that it recognises as emanating from the correct payee 6 but not in the order expected from previous first check values received) then re-entering the first check value will cause the server 5 to reset and accept the first check value and lookup the appropriate second check value.

At step 108 the server 5 transmits the second check value determined during the lookup back to the payer 3 via the communication network 4. The second check value, in the form of an alphabetic word or secret, is then displayed to the payer 3 on the screen 10 of the device 2 in the window 11.

At step 110, the secret is revealed to the payee 6 by showing them the alphabetical word displayed on the screen 9, and the payer 6 confirms or denies that the second check value is correct with that in the database 8, in other words, if the alphabetic word displayed on the screen 10 of the device 2 matches the pre-printed alphabetic word on the voucher used to provide the 4-digit PIN code. This is illustrated in Figure 5, which is a third schematic screen view showing a step in the authentication method in accordance with a first embodiment of the present invention.

At step 112, the payer 3 confirms the authentication and the transaction is completed by clicking a "Pay" button 13 displayed on the screen 9 of the device 2. If the first and second check values are incorrect, the payer 3 is unable to do confirm the authentication) and the process times out with the transaction being denied. If the authentication is confirmed, the appropriate number of credits is transferred from the payer's 3 account at the trusted third party to the payee's 6 account at the trusted third party to be redeemed either immediately or subsequently as desired.

However, it is possible that the PIN code is entered incorrectly, which generates an error at the server 5 as there is no matching alphabetic word in the lookup table.

This also means that it is not possible to complete the authentication process. If this is the case, an error screen is generated, as illustrated in Figure 6, which is a first schematic screen view showing an error step in the authentication method in accordance with a first embodiment of the present invention. On receiving an incorrect PIN code, the server 5 transmits an error message to the device 2 that is displayed as an alert 14 on the screen 10 of the device 2. An action is required to remove this alert 14, and the payer 3 is given the option to re-enter the PIN code. In this manner, should there be an error in the first check value, or should the first check value provided not match any of the possible second check values at the server 5, the payer 3 is notified.

Unlike traditional authentication processes for remote transactions, the present invention does not utilise any form of encryption for either communication via the communications network 4, or storing data at either the server 5 or in the database 8. This is to reduce the likelihood of interruptions in data transfer either during fluctuations in the quality of the communication network 4 (for example, signal changing between 2G, 3G and 4G) or in regions where signal strength and network conditions are poor in generaL With this in mind it has been determined that the optimum length for the fist check value to ensure ease of use for the payer 3 and ease of transmission is four characters, and for the second check value six characters. However) other character chains may be preferable or desirable depending on the general availability of 2 G, 3G or 4G networks. Furthermore, since the authentication method is direct between the payer 3 and the payee 6, and not via the trusted third party there is no need to encrypt data or provide any further verification. The first and second check values are stored and transmitted in plaintext since this reduces the amount of data requiring transmission over the communications network significantly. Quite simply) should the data be interrupted at any point the first and second check values at the server Swill not match those in the database 8, and should the payer 3 select an incorrect PIN code or confirm the authentication if the first and second check values are incorrect, credits are transferred at the payer's 3 request to the wrong account. Unlike with other remote transactions where funds are transferred directly using the authentication by the trusted third party 7 the credits are useless to any other party who does not have an account with the trusted third party. In effect a member's only closed payment system such as the present invention functions as its own security.

In the above example, the payer 3 is a customer and the payee 6 is a merchant.

Typically such a closed system is intended for use by shops, restaurants and other service providers (hairdressers, tattooists, spas, for example). Authentication takes place at the payee's 6 premises, since the payer 3 is present in person. However it is possible for the authentication to take place remotely, with the first and second check values being confirmed in a telephone call.

In step 112 above the payment is completed on authentication. However the payment may be completed following a further confirmation by the payer 3 on the device 2. Alternatively, in communication network areas and/or on devices 2 that support such functionality, the payment may complete when positioning data indicates that the payer 3 has left the payee's 6 premises. Positioning data can be derived from the communication network 4 or from systems generating GPS (Global Positioning System) or other position co-ordinates. In order to use such functionality it may be desirable to transmit positional data at the same time as the first check value to minimise data transfer and to indicate that the payer 3 has entered the payee's premises. This can also be used as a further guarantee of security for transactions. For example, the server S maybe set up to recognise that certain transactions can only take place in person, and therefore recognise positioning data indicating the geographical whereabouts of the payer 3 and map this to a known geographical location for the payee 6. Preferably the device 2 is a smartphone, but other devices capable of communication via a communication network may be used, such as tablet devices capable of cellular communication.

Alternatively it may be desirable to utilise other forms of network connection, such as WiFi, BluetoothTM or variants thereof, such as BluetoothTM 4.0 or LE, Near Field Communication (NFC] or similar protocols. Although in the above example the first check value is a 4-digit number and the second check value is a 6-character word, it is possible to use other combinations and amounts of characters or symbols in the check values. Ideally the second check value contains between 4 and 8 characters, since this allows the generation of enough unique recognisable words to match the available number of 4-digit PIN codes used as the first check value. Alternatively, at least the second check value, and on occasion preferably also the first check value, may be a randomly generated collection of symbols, including alphanumeric characters and other symbols such as £$%&t etc. The use of simple PIN codes and easily recognisable words is desirable as this increases the overall simplicity of the system to the user. In the above example, the first and second check values are uniquely associated with one another. This is not necessary if the server S determines the order in which first check values are received and associated with a specific payee 6, since certain first check values can be reused, nor if unique first check values are associated with non-unique second check values, since the first check value is also associated with a payee 6. Furthermore, it may be preferable to ensure that there is no duplication of first check values within the database 8 at the payee 6, but that first and or second check values are duplicated between databases 8 at different payees 6. This means that each merchant can have a voucher book in which all the PIN codes are unique, but that the same PIN code in a different order and/or associated with a different word is present in another merchant's voucher book.

A further advantage is that no additiona' hardware or associated infrastructure is required for either the payer 3 or the payee 6 to be able to use the authentication method and system of the present invention. In the example above the payment for the goods and services is made in full using credits. However, it may be desirable for only part of the payment for the goods and services to be made using credits, and the options within steps 100 -112 adjusted accordingly.

Other embodiments of the present invention will be apparent from the appended claims.

Claims

CLAIMS1. Method of authenticating a payer to a payee, comprising: a) On a device: the payer identil'ing a payee, providing a payment amount, entering a first check value obtained from the payee and transmitting the first check value to a server via a communication network; b) Ata server: receiving the first check value and performing a lookup to retrieve a second check value, the first check value and second check value being associated with one another, and transmitting the second check value to the device via a communication network; and c) On the device: the payer receiving the second check value and communicating the second check vathe to the payee; wherein when the payee confirms that the second check value is successthlly associated with the first check value, the payer is authenticated.
2. Method as claimed in claim 1, wherein the payer is a customer and the payee is a merchant.
3. Method as daimed in claim 1 or 2, wherein the authentication takes place at the payee premises.
4. Method as claimed in claim 1, 2 or 3, wherein the first and second check values are uniquely associated with one another.
5. Method as claimed in any preceding claim, wherein the first and second check values are stored and transmitted in plaintext.
6. Method as claimed in any preceding claim, wherein a payment between the payer and the payee completes on authentication.
7. Method as claimed in any of claims 1 to 5, wherein a payment between the payer and the payee completes on further confirmation provided by the payer on the device.
8. Method as claimed in any of claims 1 to 5, wherein a payment between the payer and the payee completes when positioning data shows payer has left the payee's premises.
9. Method as claimed in any of claims 6 to 8, wherein the payment is redeemed immediately or subsequently by the payee.
10. Method as claimed in claim 8, wherein the positioning data is also transmitted with the first check value.
11. Method as daimed in any preceding claim, wherein the communication network used to transmit the first check value to the server is the same as the communication network used to transmit the second check value to the device.
12. Method as claimed in any preceding claim, wherein the device is a smartphone.
13. A system for authenticating a payer to a payee, comprising: a device adapted to enable the payer to identilr a payee, provide a payment amount, enter a first check value obtained from the payee) transmit the first check value to a server, receive a second check value and communicate the second check value to the payee; a server adapted to receive the first check value, perform lookup to retrieve a second check value, the first check value and second check value being associated with one another, and transmit the second check value to the device; wherein the device and the server are in communication with one another via a communication network, and wherein when the payee confirms that the second check value is successfully associated with the first check value, the payer is authenticated.
14. System as claimed in claim 13, wherein the communication network used to transmit the first check value to the server is the same as the communication network used to transmit the second check value to the device.