GB2529229A

GB2529229A - Method and apparatus for operating a loyalty scheme

Info

Publication number: GB2529229A
Application number: GB1414450.5A
Authority: GB
Inventors: Massimo Sirolla
Original assignee: LOYAL ZOO Ltd
Current assignee: LOYAL ZOO Ltd
Priority date: 2014-08-14
Filing date: 2014-08-14
Publication date: 2016-02-17
Also published as: WO2016024086A1; GB201414450D0

Abstract

The method allows a customer having a customer device 14, such as a mobile telephone, to add a value token to a customer account held on a ledger server 10. The ledger server maintains status information of tokens, which includes at least a unique token index for each token, and the ledger server is adapted to perform the following steps: (a) encrypting the token index using a secret key and outputting an encrypted token index for communication to the customer (b) receiving a token banking request from a customer device, the token banking request including at least an encrypted token index and a user account identifier (c) decrypting the received encrypted token index using the secret key to derive a token index; and (d) allocating the value of the token to a customer account.

Description

METHOD AND APPARATUS FOR OPERATING A LOYALTY SCHEME

The present invention relates primarily to an electronic loyalty system, hut more generally to an electronic ledger system for value balances.

BACKGROUND TO THE INVENTION

Awarding loyalty points' in an attempt to attract and retain customers is very common across a wide range of business sectors. There are numerous different known variants in tcrms of how points arc carncd, how thcy arc accumulated and how they are redeemed, but there are currently oniy two main ways in which such schemes currently operate at a technical leveL The first type of known scheme is generally implemented electronically. It is typically operated by large supermarkets, chain stores, and airlines, and there are also some "umbrella" schemes, for example Nectar (RIM) and Air Miles (RIM), which allow customers to collect and redeem points at multiple participating merchants. In this first type of scheme, a customer must first enrol as a member, and upon doing so receives some form of account identifier. The customer is usually given a physical card or other token on which the account identifier is encoded, hut where the loyalty scheme is run by an undertaking which has a limited physical presence (e.g. an online shop) a physical token may not be provided. To receive loyalty points, or whatever type of reward is being offered, the customer presents his account identifier (whether or not it is encoded on a physical card) at the time when he performs a qualifying transaction. For example, a loyalty card may be swiped at a supermarket checkout or an airline check-in desk. An appropriate number of points are then added to the customer's account based on the value of the transaction, or whatever other criteria apply to the specific scheme. All information relating to the customer's account balance in this type of system is held on servers controlled by the company which operates the loyalty scheme.

The second type of known system is more typical of small independent stores, although it is also operated by larger chains selling mainly low-value products (e.g. coffee shops). This type of system is generally paper-based -when the customer performs a qualilying transaction he is given a stamp on a card, a sticker, or some similar form of token. These tokens can be collected and later redeemed for a reward.

The first (generally electronic) system is advantageous from the operator's point of view because it allows valuable intelligence to be collected on the customer's purchasing habits. This intelligence can he used to target marketing materials, and identify how to maximise sales and profit from individual customers. From the customer's point of view the centralised ledger provides some safety and convenience -if the physical loyalty card is lost then a new one can he issued and the points are safe. Also, multiple copies of a loyalty card relating to the same account can be issued so that the customer can keep one handy in. for example, multiple different handbags, wallets, cars, or on keyrings.

The disadvantage of the system is in the necessary enrolment process required to set up an account identifier before points can be issued. Because points are allocated to the customer account at the time when the qualifying transaction is made, it is vital that the customer has been issued with a valid customer identifier at that time, and this can be a significant barrier to participation in the scheme. Some schemes attempt to mitigate this problem by setting up numerous "number-only" accounts and inviting customers to take an "unregistered" loyalty card at the checkout and immediately credit loyalty points to the account. Often there is some incentive (for example, bonus points) for the customer to register' the card by providing his or her contact details.

However, this solution is expensive in practice because a large number of accounts have to be created and the numbers have to he encoded onto a correspondingly large number of cards. In any scheme operated by a company with a large physical presence (e.g. a supermarket or High Street shop), physical cards are a necessity to operate the system efficiently at a busy checkout, but even the action of having to take and then carry a card can be off-putting to a customer.

In some schemes, customers who did not have theft card with them at the time the qualifying transaction was made, or who were not yet enrolled for the scheme at that time, are sometimes allowed to present till receipts to have points added to their account. However, this either requires retrieval of transaction details for the qualifying transaction from what is inevitably an extremely large database, or it requires some kind ol manual verification step by an employee of the company which operates the scheme. It is not a procedure which can really be used as the normal way in which points are credited to customer accounts -it is only suitable for exceptional cases and even then, a majority of customers will simply give up the points rather than go through this sort of procedure.

The second (paper-based) system is simpler to operate, and in many cases is more attractive to the customer because he does not have to undergo any enrolment process.

The stamps or stickers can simply he handed over to the customer when a qualifying purchase is made, so there is almost no barrier to participation in the scheme. On the other hand. (his type of scheme has some disadvantages. Firstly, the scheme relies on the physical security of the stamps, stickers or tokens, and is therefore often not a suitable way to run a scheme in which customers might he expected to accumulate large and valuable balances. A customer who loses the stamps or stickers issued to him generally has no way to recover the points balance, and if stocks of stamps or stickers are stolen then they may be used to fraudulently obtain expensive rewards. in addition, the paper-based scheme generally provides the merchant with no feedback or data which is useful in marketing. since it does not associate transactions with a customer identifier.

It is an object of the present invention to provide a system for operating a loyalty scheme, or any other kind of value ledger, which solves the above mentioned problems.

STATEMENT OF II'WENTION

According to the present invention, there is provided a method of allowing a customer having a customer device to add a value token to a customer account held on a ledger server, the ledger server being accessible to the customer device and the ledger server being arranged to maintain status information of tokens including for each token at least a unique token index and a value of the token, the ledger server further being arranged to maintain status information of customer accounts, the method comprising the following steps performed on the ledger server: a. encrypting the token index using a secret key and outputting an encrypted token index for communication to the customer; h. receiving a token banking request from a customer device, the token banking request including at least an encrypted token index and a user account identifier; c. decrypting the received encrypted token index using the secret key to derive a token index; d. retrieving token status information using the decrypted token index and allocating the value of the token to a customer account.

The ledger server may be taken to mean a single physical or virtual machine, or a group of physical or virtual machines.

When a customer performs a qualifying transaction, a value token can be generated by storing new token status information, and then issued to the customer by outputting the encrypted token index as described above. The value token is a virtual token which contains value of some kind, for example, a particular number of loyalty points.

It is envisaged that the ledger server may provide some foirn of interface to point of sale equipment to allow token generation to be initiated automatically in response to a qualifying transaction, or aliernatively in smaller stores the generation of the value token may be initiated manually by a shop assistant, possibly by means of a web interface to the ledger server. In other words, there are authorised users (which may be specific authorised people or machines) who are allowed to initiate generation and issue ol a token.

Token generation may simply involve creating a row in a database of unredeemed tokens on the ledger server, the row including the token index and the token value.

Additional data may he included in the row depending on the application, for example. information relating to the goods or services purchased in the qualifying transaction, the branch of a chain of stores where the qualifying transaction took place, the shop assistant who was serving the customer, etc. Some implementations may support various different loyalty schemes and types of points run by a variety of different businesses, and in such cases the data may also include the points "currency" and the identity of the issuer. Different. businesses using the same platform may choose to run their own "points currency" or alternatively may choose to share a "currency" so that points can be earned and redeemed across participating merchants.

After token generation is initiated, an encrypted token index is output for communication to the customer. One useful way of providing this output is by printing the encrypted token index on a till receipt. To be issued with the token, the customer does not have to be emolled in the loyalty scheme and does not have to even provide any identifying information. Indeed, it is envisaged that in many implementations loyalty tokens will be generated for every single transaction.

regardless of whethcr or not thc customer requests them.

Once the user has been issued with an encrypted token index (for example, in the form of a code printed on the bottom of a till receipt) he may choose to allocate the value in thc token to his account, if hc wants to participate in the scheme. To do so the customer makes a token banking request using a customer device, which is preferably a mobile telephone but in most embodiments can be any internet-connected device with a web browser. The token banking request includes the encrypted token index and a user account identifier. The user account identifier does not necessarily imply that the user has to be pre-enrolled in the scheme, as long as it can be guaranteed to he globally unique. Preferahly, the user account identifier is the customer's email address. A password or other authentication means is not generally required to make a token banking request.

The token banking request is received by the edger server, and the encrypted token index is decrypted using the secret key which is held on the ledger server. The secret key never has to be transfelTed or used outside the ledger server, and the customer never sees unencrypted indexes, reducing the possibility of a successful cryptologic attack to deduce the secret key.

The step of allocating the value in a token to the customer account may simply take the form of removing the token from the status information which is held about "unredeemed" tokens, and incrementing a customer account balance th the value of that token. However. most embodiments will retain details of the or ginal token, and associate those details with the identity of the user or users who have banked that token. In particular. at least two types of token are envisaged -"limited" tokens which can be banked once, by one user, and "unlimited" tokens which can be banked multiple times, hut not more than once by a single user. Typically, "limited" tokens will be used to reward customers who make qualifying transactions (e.g. a purchase) and "unlimited" tokens can be used to award "bonus" points to users who, for example, read the participating merchant's page on a social networking website.

Unlimited tokens could also be printed on advertising.

The value in each token may he a certain number of loyalty points, or alternatively might bc a promise to pay a certain amount of a real currency, or anything cisc.

Each customer device may he adapted to perform the steps of: a. accepting input ol an encrypted token index; b. accepting input of a user identifier; c. transmitting a token banking request including the encrypted token index and the user identifier to the ledger server.

The token banking request may be in the form of an HTTP request. In particular the encrypted token index may be transmitted as the URI in an HTTP GET or POST request. In such a system, the user may bank a token having an encrypted token index of (for example) aH83b by typing (for example) phbudnecoIaH83h into the web browser on his or her mobile telephone.

It will he appreciated that the token banking request may in fact he transmitted as several HTTP messages, or other kinds of messages, and in many embodiments there will be some form of acknowledgement from the ledger server to the customer device between messages. The important point is that the token banking request in totality involves transmitting a user identifier and an encrypted token index, in some order.

After a user makes a token banking request, the user identifier may be stored on the customer device. In most embodiments this will be in the form of a browser cookie.

This negates the requirement for the user to input the user identifier in the future when making token banking requests. From that point onwards, the customer can bank a token just by providing the encrypted token index, br example as part of a URL as described above.

hi some embodiments, the ledger server may send an alternative customer identifier to the customer device in response to a token banking request. The customer device may then store this alternative customer identifier for future use. The alternative customer identifier may be derived by applying some form of transformation, possibly a cryptographic transformation, to the user identifier, or alternatively the alternative customer identifier may he an essentially random value which is stored in a lookup table to associate it with the colTesponding customer identifier.

Using an alternative customer identifier for storage on the customer device (as opposed to input by the user) allows the ledger server to distinguish first-time banking requests from repeat banking requests made from a device which has already been used to bank tokens once. The ledger server may apply some form of enhanced authentication mechanism to first-time banking requests, for example requiring input of a validation code to confirm that. the customer can receive email at the email address which he had provided. If a banking request is made subject to enhanced authentication, then the token banking request will only be allowed to proceed (i.e. the token value is only allocated to the customer account) if the enhanced authentication is successful.

This provides for a level of security whilst avoiding the need for the user to provide a password. If a customer uses an email address belonging to someone else, then the system may allow him to proceed if that email address has not been previously registered. However, when the legitimate owner of that email address starts to use the system. he will be able to validate ownership and take over the points accumulated by the first person. In the same way, somebody trying to use the email address of another user who is already registered for the system will not be able to do so, because a validation code will be required.

In most cases of course, the user will use his own email address from the beginning, which will not previously have been registered by anyone else. In this case, the user may never have to supply a validation code, providing for an excellent frictionless' user experience. The first time that the user is likely to have to provide a validation code is when he starts using a new device (e.g. he buys a new mobile phone).

This authentication system is highly advantageous, because it usually requires no validation at all when a user first signs up for the system. It is this enrolment stage which is usually a harrier in existing loyalty systems. Although most users at some point will acquire a new device and have to validate their account, this is likely to happen some time after the customer has signed up and has hopefully become committed to the system, at which point the validation process is more likJy to he tolerated.

Although the method of the invention is described primarfly in terms of a thyalty scheme, it can also be used to facilitate "micro payments", where the value tokens represent value in a real currency. In such a system. tokens may be generated in response to "paying in" to the system by means of a credit card or other external payment system. When a customer wants to send money to another customer, they may make a request for the amount to be debited from their account and a token to be issued, which can then be communicated to another customer.

Tokens may he pre-allocated to particular users by recording a list of users who are allowed to redeem each token at the time when the token is generated. This feature is particularly useful for enhanced security when sending payments between users in a micro-payments system. It is possible that it could also be used in a loyalty system if customers are allowed to send each other points, although it is not considered advantageous when generating tokens in response to an initial qualifying transaction.

DESCRIPTION OF THE DRAWINGS

For a better understanding of the present invention, and to show more clearly how it may be carried into effect, reference will now be made by way of example only to the accompanying drawings, in which: Figure 1 shows a schematic of the various components of a loyalty system; Figure 2 shows example data which may he held on a ledger server forming part of the loyalty system of Figure 1;

DESCRIPTION OF PREFERRED EMBODIMENT

Referring to Figure 1, a ledger server is indicated at 10. The ledger server 10 is accessible via an interface to a remote point-of-sale teirninal 12. The point-of-sale terminal 12 can communicate with the ledger server via the internet. Each customer has a customer device 14. typically a mobile telephone, which can also communicate with the ledger server 10 via the internet.

The operator of the point-of-sale terminal 12 eom munieates direefly with the customer via some communications channel 16 which is in addition to ihe internet communications channels between the point-of-sale terminal 12. ledger server 10 and customer device 14. This extra communications channel 16 may take the form of verbal communication, printed paper, or anything else. It may take place over the internet by for example email or a third-party social network website.

The ledger server 10 includes a database, and an example of data which may be stored in that database is shown in Figure 2. The ledger server 10 maintains records of loyalty tokens, including for each token a token index, a value, a currency, and an expiry date. The skilled person will appreciate that more complex data structures may be used to hold data to support more complex loyalty schemes.

The ledger server 10 also maintains records of customer accounts. In this example this is simply a database table which associates an account identifier to a culTent balance. Allocating a token to an account simply involves removing the token from the tokens table and adding the value of the token to the relevant row of the accounts table. However, in more complex systems it will be appreciated that it is advantageous to record which tokens were allocated to which accounts, and this would allow further functionality -for example allowing a single token to be "redeemed" by multiple customers, as long as each customer can only redeem the token once. Such a "multiple use" token might be printed on an advertisement or posted on a website, for example, to give "bonus" points to customers.

A token may be generated in response to a customer performing some qualifying transaction, for example. buying a product. Token generation is initiated by a point-of-sale machine 12 which can connect to the ledger server 10 and simply cause a row to be added to the tokens table. After that, the ledger server will encrypt the token index of the new token and send the encrypted value back to the point-of-sale machine 12 so that it can be communicated to the customer via the extra communication channel 16, for example, by printing the encrypted value on a till receipt. The customer then uses his customer device 14 to send a token banking request to the ledger server 10, which includes a customer identifier and the encrypted token index. The ledger server decrypts the encrypted token index to quickly find the correct token in the Tokens table, and then allocates the token to the correct customer account as described above.

Using an encrypted token index in the banking request allows the banking operation to work very quickly at scale, whilst making it extremely difficult to correctly guess an encrypted token index to fraudulently obtain value. Once the token index has been decrypted, the token details can be retrieved very quickly without a scan of the whole

database table.

The algorithm used to encrypt token indexes is based on "hashids". Essentially this is a reversible encryption function using a secret key. which produces ciphertext output in a particular alphabet. The alphabet is chosen to exclude characters which can be easily confused with each other (e.g. I and 1. 0 and 0). and also constraints are imposed to prevent the encrypted token indexes from unintentionally calling to nund profane words. Specifically, the algorithm ensures that none of the following characters are placed next to each other: ethistuCFHISTU'.

If a customer wants to redeem points, they can be deducted from the Accounts table on the ledger server 10 by means of a request made from the point-of-sale machine 12. or another terminal, connected to the ledger server and operated by the business which is providing the rewards on redemption.

The method and apparatus disclosed allows a loyalty scheme to he operated which allows for all the advantages of a fully-electronic system. without the associated customer friction' involved in enrolling for the scheme and having to present a loyalty card or other customer identifier at the point of sale for each transaction.

The embodiments described above are provided by way of example only, and various changes aM modifications will be apparent to persons skilled in the art without departing from the scope of the present invcntion as defined by the appended claims.

Claims

CLAIMSI. A method of allowing a customer having a customer device to add a value token to a customer account held on a ledger server, the ledger server being accessible to the customer device and the ledger server being arranged to maintain status information of tokens including for each token at least a unique token index, the ledger server further being arranged to maintain status information of customer accounts, the method comprising the foUowing steps performed on the ledger sener: a. encrypting the token index using a secrct key and outputting an encrypted token index for communication to the customer; h. receiving a token banking request from a customer device, the token banking request including at least an encrypted token index and a user account identifier; c. decrypting the received encrypted token index using the secret key to derive a token value; d. allocating the value of the token to a customer account.
2. A method as claimed in claim 1, in which the token status information maintained by the ledger server includes the value of each token.
3. A method as claimed in claim 1, in which the ledger server is adapted to generate a new token and then perform steps (a) to (d) in response to a token generation request made by an authorised user.
4. A method as claimed in claim 3, in which generation of a new token involves adding a row to a database table which contains status information of tokens.
5. A method as claimed in claim 3 or claim 4, in which the token generation request is made by point-of-sale equipment acting as an authorised user of the ledger server.
6. A method as claimed in any of the preceding claims, in which the status information of tokens includes an identifier for the authorised user which initiated the token generation request.
7. A method as claimed in any of the preceding claims, in which the encrypted token index is output to a printer.
8. A method as claimed in any of the preceding claims, in which the customer device is any internet-connected device with a web browser.
9. A method as claimed in any of the preceding claims, in which the customer device is a mobile telephone.
10. A method as claimed in any of the preceding claims, in which the user account identifier is an email address.
11. A method as claimed in any preceding claim, in which the customer device is adapted to perfoim the steps of: a. accepting input of an encrypted token index and a user identifier; h. transmitting a token banking request including the encrypted token index and the user identifier to the ledger server.
12. A method as claimed in any of the preceding claims, in which the token banking request is an HTTP request.
13. A method as claimed in claim 12, in which the encrypted token index is transmitted as the URI in an HTTP GET or POST request.
14. A method as claimed in claim 11, in which the customer device is further adapted to perform the step of storing the user identifier.
15. A method as claimed in daim 14, in which the user identifier is stored in a browser cookie on the customer device.
16. A method as claimed in any of the preceding claims, in which the ledger server is further adapted to send an alternative customer identifier to the customer device in response to a token banking request.
17. A method as claimed in claim 16. in which the customer device is adapted to store the alternative user identifier once it is received.
18. A method as claimed in claim 17, in which the alternative user identifier is stored in a browser cookie on the customer device.
19. A method as claimed in any of claims 16 to 18, in which the alternative user identifier is derived by applying a transformation to the customer identifier.
20. A method as claimed in claim 19. in which the transformation is a cryptographic transformation.
21. A method as claimed in any of claims 14 to 20. in which the ledger server is further adapted to perform the following steps to allow or disallow a token banking request: a. determine whether or not the user identifier is a new user in the system.and if the user identifier does represent a new user, allow the banking request; b. if the user identifier is an already existing user, determine whether the user identifier transmitted had been stored on the customer device. and if the user identifier had been stored on the customer device, allow the banking request; c. if the user identifier is an already existing user and the user identifier had not been stored on the customer device, require an additional authentication step and allow the banking request only if the additional authentication step is successful.
22. A method as claimed in claim 21, when dependent on any of claims 16 to 20, in which the ledger server assumes that the transmitted user identifier was stored on the customer device, if the transmitted user identifier is an alternative user identifier previously generated by the ledger server in response to a token banking request.
23. A method as claimed in claim 21 or claim 22, in which the additional authentication step includes the ledger server sending a message to a communications address associated with the user identifier, the message containing a validation code, and requiring input of the same validation code in order to successfully authenticate.
24. An apparatus comprising means adapted to perform the method of any preceding claim.
25. A program!èr controlling an apparatus to perlorm a method as daimed in any one of claims 1 to 23, carried on a carrier medium such as a storage medium or a transmission medium.
26. A method substantially as described herein with reference to and as illustrated in the accompanying drawings.