WO2014065754A1

WO2014065754A1 - Apparatus and methods for generating and/or validating redemption codes

Info

Publication number: WO2014065754A1
Application number: PCT/SG2012/000401
Authority: WO
Inventors: Eu Khoon ANG; Wai Leng LEONG
Original assignee: Visitor Information Pte Ltd
Priority date: 2012-10-24
Filing date: 2012-10-24
Publication date: 2014-05-01

Abstract

An apparatus for generating a redemption code for a user to redeem an offer comprises a processor and a memory. The apparatus is configured to generate a partial redemption code comprising characters derived from a personal identifier for the user. A code check component is generated using the partial redemption code. And the redemption code is generated using the partial redemption code and the code check component. An apparatus validates a redemption code for a user to redeem an offer by determining whether the redemption code is of a valid form using characters in the redemption code. The apparatus determines whether the redemption code has expired and signals redemption of the offer if the redemption code is of a valid form and the redemption code has not expired.

Description

Apparatus and Methods for Generating and/or Validating Redemption Codes

The invention relates to an apparatus and a method for generating a redemption code for a user to redeem an offer. The invention also relates to a computer-readable medium for storing computer-readable instructions for implementing such a method. The invention also relates to an apparatus and a method for validating a redemption code for a user to redeem an offer.

The invention has particular, but not exclusive, application in paperless ticketing/voucher schemes. Of course, it is well known that tickets and vouchers can be issued where a service provide makes an "offer" to sell, hire or otherwise dispose of one or some of a great many things. For instance, it is known that tickets can be issued for, for example, entry into attractions, clubs, concerts and the like. Tickets can be bought in advance using advance booking schemes over the telephone or using the internet, or in person at the point of entry at or near the time of entry. Tickets/vouchers have also been issued for, for example, a user - the "bearer" of the ticket/voucher - to redeem a service paid for, at least in part, such as a spa treatment. Indeed, they have also been known to be issued for redemption of a food and beverage offer such as a discounted meal at a particular restaurant, encompassing the likes of "2-for-l" offers.

Numerous schemes are available for the issuance and redemption/validation of such tickets and vouchers. For instance, and to give just two examples of known schemes for controlling entry to attractions, clubs or concerts or redeeming services, these include the use of a paper or paper-based ticket or the use of a token -- such as a RFID or magnetic swipe (or strip) card - which is tapped against, or swiped through, an entrance terminal at the entrance of the attraction, concert, club, restaurant or other service provider to start process a process of verifying the token. Value can be added to the token at a prior time according to many different techniques for later redemption at the attraction entrance. The main purpose of such tokens is to present a key which requires an entrant to an attraction to be in possession of the token otherwise entrance is refused. If the offer/value has previously been redeemed, then the redemption mechanism implemented by the service provider (or the provider of the token) recognises this and redemption of the offer is denied. One type of token service developed by the inventors of the present invention is described in co-pending Singapore Patent Application No. 201005359-3.

However, these systems are not without their limitations. For example, the number of sales under the schemes may be limited by the hardware available; if, say, the service provider runs out of stock of RFID cards then that service provider cannot make any further sales until its stock of RFID cards has been replenished. Issuance of paper-based tickets is resource- intensive and wasteful. Further, retailers and resellers are faced with the logistics of the maintenance of retail space and personnel for the issuance of paper-based tickets and RFID cards and their like as it is commonplace for such tickets to be transacted in person.

Furthermore, these existing systems may also suffer from the problem during

redemption/validation in that the purchaser of the ticket/voucher may very well be able to pass his or her ticket/voucher on to another user. For example, if the user who had purchased the ticket/voucher cannot use the ticket/voucher themselves, he or she may give it to a friend or relative interested in availing themselves of the offer for which the ticket/voucher was issued and paid for. The possibility for this happening is less than ideal for the retailer because an opportunity for a second sale may have been lost if both persons would otherwise have bought a ticket. Worse, unless fraud-proof validation schemes are in place the buyer of the ticket may find a way in which both he and his friend/colleague (and, indeed, further users) are able to use the voucher/ticket for the price of a single purchase.

The invention is defined in the independent claims. Some optional features of the invention are defined in the dependent claims.

Provision of an apparatus for generating a redemption code where the redemption code comprises a code component (the partial redemption code) having characters derived from a personal identifier for the user is particularly beneficial for reasons which will become apparent. Such a code lends itself to use in paperless ticketing systems. Once the code has been generated, it can simply be given to the buyer. In its simplest form, the buyer can be informed of the redemption code for the buyer to make his or her own note of it for later redemption at the point of redemption. Transfer of the redemption code details can be done "over the counter" or in a telephone conversation at the time the user/buyer purchases the voucher/ticket. Additionally or alternatively, the code may be sent to the user/buyer and many options are available for this; for example, the redemption code can be sent to the buyer by SMS to the user's mobile device, or by e-mail to the user's e-mail address. Concerning the personal identifier, a code component in the redemption code can also - additionally or alternatively - be derived from the user's driving licence, identity card, credit card or the like. Indeed, the techniques disclosed herein can make use of almost any form of personal identifier for the user/buyer. To validate the code at the point of redemption, the user (the buyer of the redemption code) brings details of the redemption code - whether sent to the user's mobile device or recorded by other means -- and the user him or herself, or a staff member at the point of redemption, enters the redemption code into a terminal for validation/redemption either at the terminal or at a back end server (with details of the code being transmitted from the terminal to the back end server). The person entering the code may be prompted by the terminal. The validation process determines whether the redemption code is of a valid form using characters - such as a check code component/check digit -- in the redemption code and then determines whether the redemption code has expired. Redemption of the offer is signalled if the redemption c'ode is of a valid form and the redemption code has not expired;

The validation process may also check as to whether the redemption code has previously been redeemed. If the redemption code has not previously been redeemed, entry to the attraction may be permitted to the bearer of the redemption code. If the partial redemption code component is derived from, say, the user's passport number then an identity check can be performed at the point of redemption. For example, if the last four digits of the passport number is inserted into, say, the first four digits of the redemption code this facilitates identity checking at the point of redemption and obviates the problem arising from the original purchaser of the ticket/voucher passing that on to another party for them to use at the point of redemption. The identity check can be manual where the staff member checks the user's ID against the redemption code for validation. The staff member will typically have been apprised of the manner in which the redemption code is made up, and how that relates to the user's identification that is, the staff member will know that, for example, the first four digits of the redemption code relates to the last four digits of the user's identification. Additionally or alternatively, the identification check can be automated (or at least semi-automated) where the user/buyer or the staff member passes the means of identification through, say, a scanner terminal which automatically cross-checks the ID with the redemption code, or transmits details of both to a back-end server for validation there.

When these techniques are implemented in a paperless ticketing system, it simply is not possible for the buyer to make copies of the ticket; indeed, there is no ticket per se to copy. When the redemption/validation process checks for whether the code has previously been redeemed, duplication of the code is pointless as it will lead only to refusal of entry when the code is presented a second (or further) time, the system having already flagged the first use of the redemption code. Additionally, forwarding of the code to another party for that party to use it instead of the user who made the payment for the service the redemption code is issued for would serve no purpose as the other party would not be able to redeem the code without having personal identification tied to the partial redemption code, as discussed above.

Such a system is particularly beneficial is that a particular offer provider, such as the tour operator, may offer some packages which a calibrated on a certain level of usage. For , instance, a Parks Authority may tome up with a package for a one-day pass to, say, all four parks, calculating that a customer may physically only be able to go to a maximum of three of those parks. Without the inclusion of the identification component in the redemption code, the user can pass the same redemption code to others to go to any park that the user is incapable of going to. This would create a loss situation for the Parks Authority.

Implementation of the techniques disclosed herein may obviate such a loss.

Further, when the redemption code (or the partial redemption code) comprises a code component relating to a validity period for the offer, this too can be checked for

automatically. Once details of the redemption code are entered into the terminal at the point of redemption, the terminal (and/or the back end server) can extract the relevant code component relating to the validity period and, if the validity of the offer has expired, this, too, can be flagged and if appropriate redemption of the offer may be denied. Further, implementation of the techniques disclosed herein obviates the requirement for having face-to-face contact between the seller of the service/paperless ticket and the user as there is no real need for there to be a physical handover of a paper ticket or token (e.g. FID card, magnetic strip card) to the user.

Thus, implementation of the techniques disclosed herein may provide a paperless solution to venture in and discover a city, region or country and its attractions. The techniques disclosed herein facilitate simple entry to attractions and facilitates administration of the ticketing system therefor, but it also is sufficiently flexible to allow customisation of the specific implementation for receipt of the redemption code and, indeed, the nature and number of attractions the customer wishes to partake in or of. For instance, it is envisaged that the redemption code may be valid for multiple attractions. Alternatively, it is possible for a separate, e.g. unique, redemption code to be issued for each attraction the user wishes to partake in or of.

And, of course, implementation of a paperless ticketing system is environmentally friendly, leading to less wastage.

The invention will now be described, by way of example only, and with reference to the accompanying drawings in which:

Figure 1 is a block diagram illustrating an architecture for an apparatus for generation of a redemption code;

Figure 2 is a process flow diagram illustrating a process flow for the generation of a redemption code as implemented in the apparatus of Figure 1;

Figure 3 is a schematic diagram illustrating the generation of first and second redemption code by the apparatus of Figure 1;

Figure 4 is a block diagram illustrating an architecture for an apparatus for validation of a redemption code; and

Figure 5 is a process for diagram illustrating a process flow for the validation of a redemption code as implemented in the apparatus of Figure 4. Turning first to Figure 1 an apparatus for generating a redemption code for a user to redeem an offer is illustrated. Apparatus 100 comprises a processor (such as a microprocessor of a computing device) 102 and a memory 104. In the example of Figure 1, memory 104 is a volatile memory such as a random access memory (RAM) configured for computer code 106 to be loaded therein for the apparatus to perform certain functionality as will be described below. Alternatively, memory 104 may be a type of non-volatile memory such as an EEPROM having code 106 loaded thereon. Apparatus 100 may also comprise a storage type memory 108 and a redemption code generation module 110. It will be appreciated that the redemption code generation module 110 is illustrated schematically and may, of course, be implemented in software loaded into memory 104 and/or memory 108.

Apparatus 100 may also comprise an input/output module 112 and a user interface 114.

The apparatus 100 is configured to generate a redemption code 116 comprising a partial redemption code 118 and a code check component 120, both of which will be described in more detail below.

Figure 1 illustrates an apparatus 100 for generating a redemption code for a user to redeem an offer, the apparatus comprising a processor 102 and a memory 104. Apparatus 100 is configured, under control of processor 102, to execute instructions 106 stored in memory 104 to generate a partial redemption code 118 comprising characters derived from a personal identifier for the user. Apparatus 100 also generates a code check component 120 using the partial redemption code as will be described below and generates the redemption code 116 using the partial redemption code 118 and the code check component 120.

The characters in the partial redemption code derived from a personal identifier from the user may be, for example, digits from the user's photographic identification, such as passport, identity card or driver's license. Of course, materials sufficient to identify a person, such as a credit or debit card may also be used and characters relating to those cards - for example, extracted from the credit card number - can be used in the generation of the partial redemption code. Details relating to these characters can be entered into apparatus 100 by a system operator using input/output module 112 which may comprise, amongst other things a computer keyboard, computer mouse, touchscreen device etc or a combination thereof. Additionally or alternatively, apparatus 100 may be configured to receive this information via input/output module 112 from a user/buyer purchasing entry to attractions using, say, an online payment engine. After apparatus 100 generates the redemption code 116, it may be sent to the user from input/output module 112 which may be configured to send an e-mail to the user/buyer with details of the redemption code 116 for the user to take to the point of redemption.

Additionally or alternatively, input/output module 112 may be configured to send, for example, an SMS to the mobile device (not shown) of the user for the user to take to the point of redemption, or to interface with an SMS engine (also not shown) for that to send the SMS to the user's device. Use of an SMS engine for this purpose will typically be less expensive than use of a paper- or token-based ticketing system, thereby leading to reduced operating costs for the retailer. In one implementation, the redemption code is generated in barcode form, such as a traditional "linear" (or "one-dimensional") barcode or a "matrix" (or two dimensional) barcode, such as a Q code (TM). Barcodes can be easily displayed on, say, a user's mobile communication device for presentation at the point of redemption. Additionally or alternatively, details of the redemption code may be displayed on a user interface 114. Upon display on user interface 114 of apparatus 100, details of the code may then be conveyed to the user for the user to take note thereof.

Turning now to Figure 2, a process for generation of a redemption code in the apparatus 100 of Figure 1 is illustrated. Process 200 starts at step 202 followed by a partial redemption code 118 being generated at 204. At 206, code check component 120 is generated and the redemption code 116 is generated at step 208 prior to the generation process ending at 210. Of course, after completion of the redemption code generation process 200, the redemption code 116 may be communicated to the user.

In essence, Figure 2 illustrates a method 200, implemented in an apparatus 100, for generating a redemption code 116 for a user (not shown) to redeem an offer. Method 200 starts at 202 and comprises, under control of a processor 102 of apparatus 100, generating 204 a partial redemption code 118 comprising characters derived from a personal identifier for the user. The method further comprises generating 206 a code check component 120 using the partial redemption code 118 and then generating 208 the redemption code 116 using the partial redemption code 118 and the code check component 120. The generation process 200 of Figure 2 ends at 210.

Figure 3 is a schematic diagram illustrating two examples of the generation of redemption codes in more detail. Turning first to Figure 3a, a table representing components of the redemption code 116 are illustrated. Table 300 comprises column 302 with exemplary components of the redemption code. The next column of table 300 is column 304 which illustrates the number of characters used in this example within each code component of the redemption code. Character representations for the characters in the code components are detailed in column 306.

In the example of Figure 3, the redemption code comprises at least four code components: a user identifier code component 308; a validity code component 310; a transaction code component 312; and a code check component 314. Generation of redemption codes using these code components are now described with reference to Figure 3b and Figure 3c.

As illustrated first in Figure 3b, a redemption code 116 comprises a partial redemption code 118 and a code check component 120. In this example, partial redemption code 118 comprises at least a user identifier code component 308, a validity code component 310 and a transaction code component 312.

The individual characters of redemption code 116 are denoted by character series 316 Nl, N2, N3,..., N12. The first group 308 of four characters Nl, N2, N3, IM4 are the characters Al, A2, A3, A4 derived from a personal identifier from the user. In the example of Figure 3, these four characters Al, A2, A3, A4 are taken from the last four digits of the user's passport, identity card or driving licence number which may be conveyed by the user to the redemption code service provider during the transaction of purchasing the service for which the redemption code is being generated. Of course, it will be appreciated that other characters from the user's identification may also be used and these characters may be inserted at a different place in the character string 316 of the redemption code 116.

The user may be prompted in the booking system -- discussed in more detail below -- for his identification number, or at least a part thereof. For instance, some users may be sensitive to being asked for their full identification number and the techniques disclosed herein may be adapted to account for that. So, for example, a user may be prompted to enter the last six digits of his or her identification number and the last four digits are extracted by apparatus 100 to form the user identifier code component 308.

The second group 310 of four characters Bl, B2, B3, B4 comprise characters relating to a validity period for the offer for which the redemption code is being generated. For instance, if the offer is valid in the month of June 2011, the four characters may comprise 0611 using the MYY format for month and year. It will be appreciated that other date formats may also be implemented, such as YYM (the year and month) or even DD M (day and month). Thus, apparatus 100 is configured to generate the partial redemption code to comprise characters representing a validity period for the offer.

' The third group 312, this time comprising three characters, CI, C2, C3, relate to a transaction code component generated for the transaction. This is, effectively, a serial number which is unique for a validity period of the offer and may be a randomly or quasi-randomly generated number. In this example, this number comprises of three numeric characters meaning that a total of 1000 -- i.e. 0, 1, 2,..., 999 -- unique codes for a particular offer in a particular validity period may be issued. It will be appreciated that the techniques disclosed herein are not limited to the use of numeric characters and other types of characters -- including, for example, alphabetic, alphanumeric and hexadecimal characters -- may also be used.

The transaction code component is generated as a unique code component for a validity period of the offer. This is beneficial because it is possible that two users may have the same four digits in the identification (e.g. passport etc) purchasing a redemption code for a particular offer in the same validity period. Admittedly, the possibility of this happening is rather slim, but the generation of a unique transaction code component for that validity period obviates the possibility of the same redemption code being generated twice for two different users (having the same digits from the identification inserted into their redemption code) seeking to avail themselves of the same offer in the same validity period.

When it is said that the numbers may be quasi-randomly generated, one example of this is that the same number cannot be generated twice for the same offer. That is, apparatus 100 maintains a record of the transaction code components generated for a particular offer and ensures that duplication of that transaction code component does not take place, at least for that offer and that validity period. Thus, apparatus 100 may be configured to generate a transaction code component randomly or quasi-randomly and to generate the partial redemption code 118 using the transaction code component. In the alternative, a simple set of sequential numbers may be generated for this purpose; that is, the numbers are not generated randomly or quasi-randomly and a count is incremented in, for example, steps of 1 or 2, for each generated redemption code. It will also be appreciated that fewer or greater numbers may also be used for the transaction code component to cater for the volume of transactions anticipated for the offer.

The final character N12 in the redemption code 116 of Figure 3b is the character for the code check component which is appended to the partial redemption code 118. In this exahiple, the code check component comprises a single check digit generated by apparatus 100 in a modulus 10 process which will be described in greater detail below. However, other types of code check components may also be used, including code check components having more than one character, or using non-numeric characters such as alphanumeric, alphabetic or hexadecimal characters.

In the example of Figure 3, redemption code 111 comprises a character string having a total of 12 numbers therein. However, other lengths of character strings are contemplated. It has been found by the inventors that a character string length of 12 may be optimal and a fine point of balance between offering reasonable security with ease of use. For instance, 16- or 20-character strings may be too cumbersome to use and enter into a redemption terminal, whereas, say, an 8-character string may be too short to provide the requisite amount of security and flexibility in being able to issue redemption codes for high-volume offers. Figure 3c illustrates a second exemplary redemption code 116' comprising a partial redemption code 118' and a code check component 120'. In the example of Figure 3c, partial redemption code 118' is split into two parts. In the first part -- that part comprising characters Nl... N7 -- this includes a user identifier code component 308' (which may be derived as described above with reference to Figure 3b), at least part of validity code component 310' (which may also be derived as described above with reference to Figure 3b) and at least part of transaction code component 312' (which may also be derived as described above with reference to Figure 3b). In this example, first character CI of transaction code component 312' is positioned at character number N5 in the character string, but the other two characters, characters C2 and C3, are positioned, respectively, at characters Nil and N12 in the character string. Similarly, the validity code component 312 has first and second characters Bl, B2 positioned at characters N6 and N7 respectively, the third and fourth characters of B3 and B4, being positioned at characters N9 and N10 respectively. Code check component 120 character E is positioned at character N8.

Therefore, in the redemption code 116' of Figure 3c, the code check component 120' is not appended to the partial redemption code 118' as such, but inserted therein.

Therefore, in the example of Figure 3c, apparatus 100 is configured to insert the code check component 120' in the redemption code character string 316' between characters from one or more other components of the redemption code. Thus, in this example, the code check component 120' is inserted into the character string 316' of redemption code 116' between characters B2 and B3 from the validity component 310' of redemption code 116'.

It will be appreciated that the code check component 120' of Figure 3c has been inserted into the character string of the redemption code 116' in a different place when compared to the code check component 120 of redemption code 116 in Figure 3b. That is, apparatus 100 is configured to generate the redemption code 116, 116' comprising a string 316, 316' of characters and to generate the redemption code 116, 116' with the code check component 120, 120' inserted into the string of characters at one or more predetermined locations. The position for the code check component to be inserted into the string of characters can be varied, say, periodically depending on several variables such as the offer in question, or, say, the requirements and specifications of the redemption service provider. Of course, the number of character strings in the redemption code also plays a part in this and where, precisely, the code check component is to be inserted. Yet further, this will also be dependent upon the number of characters in the code check component.

The arrangement of Figure 3c is particularly beneficial in splitting up components of the redemption code which contributes further to making the redemption code difficult to duplicate. Indeed, generation of the redemption code in this fashion may make it difficult even for a potential copier to be able to understand the structure and make up of the redemption code. As also noted above, characters from the transaction code component 312' may be split up. Thus, apparatus 100 is configured to generate the redemption code 116' comprising a string 316' of characters and to generate the redemption code 116 with characters from the transaction code component 312' inserted into the string 316' of characters interspersed with other characters in the redemption code. Again, this may contribute to making the system of the redemption code generation more difficult for a potential copier to copy.

As noted above, one technique for generating the code check component comprises use of a modulus 10 process to generate a check digit. A method for executing this is now described. The process verifies a number against its included check digit, which is usually appended to a partial redeem code to generate the full redemption code, as discussed above. Once the individual redemption code components -- the user identifier code component 308, the validity code component 310 and the transaction code component 312 - have been generated by apparatus 100, the check digit (code check component) 120, 314 is derived.

Assume, for example, that the code components 308, 310, 312 comprise the following 11- character string (partial redemption code): 9422001E0605, where "E" comprises the check code component, the exact value of which is to be determined. Note that the redemption code is of the form of the redemption code 116' of Figure 3c above where the code check component 120 is inserted into the character string. That is, numeric characters 9422 are taken from the user's piece of identity, the characters 0106 represent the expiry of the validity of the offer (1 June) and the characters 005 comprise the transaction code component generated as discussed above. To determine the check digit, the modulus 10 process dictates that the apparatus 100 operates as follows to generate the check digit:

1. Counting from the right-most digit of the partial redemption code, 4, and moving left, double the value of every second digit.

2. Sum the digits of the products together with the undoubled digits from the original number.

3. A check digit is then generated and added to the end result so that the total modulo 10 of the resulting number is equal to 0 (if the total ends in zero). Therefore, and following the exemplary partial redemption code noted above of

"9422001E0605" (where the character "E" is included for the sake of completeness, but does not form part of the "partial redemption code") apparatus 100 doubles every second digit, starting from the right-hand side of the code: 0, 0, 1, 0, 2 and 9. Once doubled apparatus 100 arrives at 18+4+2+4+0+0+2+0+6+0+5 = 41. In order for the modulus 10 of the redemption code result to be satisfied - i.e., the result is an integer multiple of 10 - the code check component is set to 9 and the resulting redemption code is 942200190605.

In one implementation, at step 2 above, if the sum of the doubling of a particular digit results in a number of 10 or greater (that is, a two-digit result), then the individual digits may be some together as part of the summing at step 2. A reverse process may also be applied as the validation stage, described in more detail below.

Thus, a partial redemption code 118 is generated comprising characters derived from a personal identifier of the user. (The partial redemption code is also, in this example, generated comprising characters representing a validity period for the offer and using a transaction code component randomly or quasi-randomly generated.) A code check component 120 is generated using the partial redemption code 118. The redemption code 116 is generated using the partial redemption code 118 and the code check component 120. A reverse process, as will be described in more detail below, can be conducted for validation of the redemption code. Turning now to Figure 4 an apparatus for validating a redemption code for a user to redeem an offer is illustrated. Apparatus 400 comprises a processor (such as a microprocessor of a computing device) 402 and a memory 404. In the example of Figure 4, memory 404 is a volatile memory such as a random access memory (RAM) configured for computer code 406 to be loaded therein for the apparatus to perform certain functionality as will be described below. Alternatively, memory 404 may be a type of non-volatile memory such as an EEPROM having code 406 loaded thereon. Apparatus 400 may also comprise a storage type memory 408 and a redemption code validation module 410. The redemption code validation module 410 may, of course, be implemented in software loaded into memory 404 and/or memory 408 to control the apparatus 400 to validate the redemption code.

Apparatus 400 may also comprise an input/output module 412 and a user interface 414. The apparatus 400 is configured to validate a redemption code -- such as redemption code

116 generated by apparatus 100 of Figure 1 -- comprising a partial redemption code 118 and a code check component 120, generated as described above.

Thus Figure 4 illustrates an apparatus 400 for validating a redemption code for a user to redeem an offer, the apparatus comprising a processor 402 and a memory 404. Apparatus 400 is configured, under control of processor 402, to execute instructions 406 stored in memory 104 to determine whether the redemption code 116 is of a valid form using characters in the redemption code. Apparatus 100 also determines whether the redemption code has expired. If the redemption code 116 is of a valid form and has not expired, apparatus 100 signals redemption of the offer. Figure 5 illustrates a method 500, implemented in apparatus 400, for validating a redemption code for a user to redeem an offer. Method 500 starts at 502 and comprises, under control of a processor 402 of apparatus 400, determining 504 whether the redemption code 116 is of valid form using characters in the redemption code, as will be described in more detail below. Method 500 further comprises determining 506 whether the redemption code 116 has expired, which will also be described in greater detail below. At 508, apparatus 400 signals redemption of the offer if the redemption code 116 is of a valid form and the redemption code has not expired. The validation process 500 or Figure 5 ends at 510. However, it will be appreciate that other checks may also be carried out in the validation process.

Apparatus 400 determines whether the redemption code is of a valid form using a check code component 120 in the redemption code.

Taking, as an example, the redemption code 116 generated above of 942200190605 this can be validated using a modulus 10 process. Indeed, the process can almost be considered the reverse of the modulus 10 process used to generate the code described above. Apparatus 400 determines whether the redemption code is of a valid form by doubling every second digit reading from the right-hand side of the redemption code: 0,0,1,0,2 and 9 resulting in 18+4+2+4+0+0+2+9+0+6+0+5 =50.

50 is an integer multiple of 10. That is, when divided by 10, will have reminder 0, so apparatus 400 determines that the code is probably a valid code and, at least, is of a valid form in that the modulus 10 process described above results in a zero remainder. In this example, it determines the code is of a valid form using the check code component from the redemption code. If the check digit was wrong, e.g. any digit other than 9, the product divided by 10 will leave a remainder that is NOT 0, and hence apparatus 400 will determine that the redemption code is not of a valid form; that is, it is invalid.

As noted above, redemption code 116 comprises characters representing a validity period for the offer. For instance, the redemption code may comprise characters representing the day and month that the offer expires; for instance, the characters "0106" represent the offer expiring on the first day of the sixth month, 1 June. Apparatus 400 extracts characters representing the validity period for the offer from the redemption code and, using these, determines at step 506 whether the code has expired. If the code has not expired, and the code is of a valid form, then apparatus 400 signals redemption of the offer. An optional step may also include checking as to whether that particular redemption code has previously been redeemed. If the code has been redeemed already, then the code is not redeemed and the user may not redeem the offer (a second time).

When it is said that apparatus 100 may signal redemption of the redemption code, this may be implemented in one or more ways, and the selection of which may also depend on the location of the apparatus 400. In one implementation, apparatus 400 is located at the point of redemption; that is, apparatus 400 is located at the location where the offer is being offered. Therefore, it may be installed in, for example, a restaurant, club or other attraction - - for example, a zoo or an amusement park -- premises. In one implementation, apparatus 400 is configured for a staff member to enter the redemption code into apparatus 400 for validation using, for example, input/output module 412 and/or user interface 414.

Apparatus 400 may be configured to annunciate to a staff member at the point of redemption or to the user when the code is a valid code via, again, the input/output module 412 and/or user interface 414. In one implementation, apparatus 400 is associated with a barrier entry, and signalling redemption of the code comprises allowing entry through the barrier when the code is redeemed, perhaps under direct control of apparatus 400.

Alternatively, apparatus 400 may comprise part of a back-end of the validation system, located at, say, a server room remote from the point of redemption. In one such

implementation, apparatus 400 is configured to receive the redemption code via

input/output module 412 for validation at the apparatus. Upon determining the redemption code is of a valid form and has not expired, apparatus 400 signals to a terminal at the point of redemption and/or a user at the terminal that the offer is redeemed and that the user may avail him or herself of the offer such as by entering into the attraction.

In one implementation where the apparatus 400 is located remote from the point of redemption and configured to interface with a terminal (not shown) at the point of redemption (the terminal into which the user or the staff member at the point of redemption enters the redemption code) communication between the apparatus 400 and the terminal at the point of redemption is encrypted and/or requires a "handshake" between the two devices prior to communication.

Thus, when a user wishes to redeem an offer, a redemption code is entered into the terminal at the point of redemption using, for example, a keypad such as a computer-style keyboard or a telephone-style keypad. Additionally or alternatively a barcode scanner - configured to scan, say, one- and/or two-dimensional barcodes - may be provided for receipt of the redemption code at the point of redemption terminal. The terminal communicates with apparatus 400 initiating communication for the redemption code to be validated. In this initial communication, it is preferable that the terminal also communicates to apparatus 400 an identifier for the terminal which provides an indication to apparatus 400 that the communication is from a trusted source. For instance, implementing the step may obviate a situation whereby an unauthorised user transmits a redemption code which has somehow or other been copied from a valid redemption code from an unauthorised terminal. Apparatus 400 may also identify the offer from the terminal ID. For instance, that may be known that a particular terminal is at, say, the zoo and this knowledge can be used as another level of validation for cross-checking with stored records generated when the redemption code is generate (e.g. details of the offer the code is generated for may also be stored). Apparatus 400 communicates back to. the terminal that it is ready to receive the incoming communication with the redemption code for validation. In the implementation where the terminal has transmitted a terminal identifier for apparatus 400 to validate its identity, this step takes place only when apparatus 400 identifies the terminal as a valid point of redemption terminal. If the terminal is not validated, the redemption process is immediately terminated and, in fact, this occurrence may be communicated to a system log or operator for further investigation. After the terminal has received the go-ahead from apparatus 400 that it is ready to receive the redemption code, the terminal then communicates the redemption code to apparatus 400 for validation thereat. If validation is successful, and the offer is redeemed, this is preferably stored in a server so that the redemption code cannot be redeemed a second time.

Communication may be via any one of a number of means such as through the Internet or over a telecommunications network. The handshake and/or the code transfer may be secure in that communication is encrypted. For instance, the communication may make use of a public/private key pair.

One variant of the techniques disclosed above is to allow a stored "countdown" for a product package. For instance, the "offer" may be 10 sessions at a spa to be used before a particular expiry date. As long as the verification requirements are met, the redemption terminal sends a request to the server - e.g. apparatus 400 -- to verify that there are sessions left over in the package. If any sessions are left over, the server accepts the transaction. If no sessions are left in the package, the server rejects the transaction.

In terms of the booking process, this can be carried out by a system operator interacting, say, over the telephone with a buyer. In one implementation, the buyer can make payment for and receive details of the redemption code using an online booking and payment engine. For a B2C (business to customer) application, when booking, discounts may be applied. For package booking the first product booked there will typically be no discount. For each subsequent booking, a discount may be given to Guest according to the number of packages selected.

Packages booked as follows:

1st Package (no discount)

2nd Package (N discount)

3rd Package (N discount)

4th Package and above (N discount)

For discount, a table will be provided for the discount scheme. (N amount will be absolute value).

In a B2B (business-to-business) context, login may be required

Packages booked will be based on the special rate for the agents. For example, for an Inventory Controlled tour there will be a control in booking, wherein there will be a cut-off time and number of seats availability (10 slots as default availability) according to date and tour time. Product Availability - there are some packages wherein agents cannot view or select for booking. After a booking has made, the system will proceed to a Shopping Cart List Page. This page will display all the packages selected and the amount.

B2C, Payment mode may be by, for example, PayPal™. B2B Payment mode may be for:

Internal Agents to use PayPal

External Agents to use PayPal, Cash Payment (counter), Cash Payment (on-site).

Note: for inventory controlled packages with cut-off time, system will verify current time against the pickup time. If payment process selected has been made past cut-off time, system will prompt guest/Agent that their transaction is not successfully processed.

Otherwise, system will proceed to PayPay / Payment Module.

All the Guest Information is keyed-in. It may be that the following information is considered the minimum necessary:

Last Name

First Name

Identity Number

Contact Number

Hotel (perhaps selected from a drop down list)

Email Address

Terms and Conditions will be shown to Agent/Guest and they have to acknowledge it, to proceed with the transaction.

For payment, the Guest will proceed on the payment type selected. For instance, if Paypal is being implemented, he can be prompted to pay by Visa™, Mastercard™ or American Express™. After payment has been successful, emails are sent to any or all of the following: reservations@providercompany.com

- Guest email address

Guest will receive payment confirmation directly from PayPal and will be advised to wait for confirmation email from Provider Company.

For an agent to pay, the Agent will proceed on the payment type selected.

PayPal site

Cash Payment

Counter

On-site

After payment has been successful, email sent to: reservations© providercompany.com

agent's email address

Agent will have to enter the receipt number to generate the confirmation voucher.

If mode of payment is cash, agent to enter amount collected and confirmation voucher will be issued.

For a staff log in screen, staff will be able to view all the transaction made through , for example, PayPal and Cash Transactions:

Confirmed booking will auto send a confirmation letter to Guest. All confirmed booking will be stored on a different table at a server.

Tour booked with redemption (single or multiple) will generate each redemption code as described above and to be sent out as a separate notification (email, SMS etc) to guest and Provider Company reservation. Declined booking will generate as an exception report and will be stored on a different table/database for record purposes.

A file, such as a CSV file, will be generated prior to purging the data.

Declined records will be purged, say, 7 days after the date declined.

The system can search for records using the following criteria:

Name

Passport

Booking / Reference #

Tour Administrator and User may be provided with a RFID login as part of the security; for creating or modify the Tours, Agent Accounts, etc.

For Tour Management:

- Each Tour can group according to its category.

Each Tour can assign up to 5 redemption items.

For Inventory Controlled Tour - there will be a cut-off time of 60 minutes before the tour starts and its quantity.

For multiple time cut-off (e.g. Captain Explorer DUKW Tour) - there will be a least 1 hour and 15 mins. allowable cut-off time and seat availability (10 as default availability).

Administrator or User with access on the Product file can assign individual product whether it is inventory controlled or not.

New items can be key-in in advance in the system and will be tagged as active. Otherwise, it will not show on the booking module as one of the available tour.

- No deletion on the product if there are existing transactions made.

Templates for confirmation letter for Cash Payment (Counter), Cash Payment (On-site) and PayPal, provided there are changes on the contents to be sent via email. For Redemption Management:

Create a redemption item, where it can be included as part of the Tour (as promotional or other purposes).

Will have 5 redemption items. For Category Management can:

classify each tour.

Will have 7 categories.

Agent Information

Each Agent can have up to 3 sub-accounts, however the Administrator can assign up to 30 sub-account agent for a particular agent.

Credit Limit will be allocated per Agent, agent with sub-account/s can assign a credit amount for each sub-agent (not exceeding the overall total credit limit).

Provider Company Login can view all the transactions made by the agents and their sub-agents.

Agent with Master Log can able to view all the transactions created by their subaccount agents.

Sub-account agent can only view his/her transaction.

Agent can categorize as Tier 1 or Tier 2 (for tour rates).

Although a booking system has been described using the exemplary payment agent of PayPal, other payment engines are also contemplated. For instance, use of payment engine facilities provided by banks (including, for example, internet banking facilities) may also be used. Another useful payment engine is the Alipay™ system.

Many models are envisaged. For instance, in one implementation, passengers of a vehicle, for instance an aeroplane, can make booking for attractions in the airplane. Once landing at their destination, they can receive details of the booking code by, say, SMS, IM (instant message) MMS and/or email.

Another benefit of the system is that it minimises the billing requirement for merchants (i.e., the vendors at the attractions) such as a zoo, a bird park, etc. As long as the transaction is verified, the seller may be automatically billed for the transaction as verification is carried out by the system. In terms of paper verification, the merchant may compile the invoice, while the seller verifies that the transaction before payment. Thus, it will be appreciated that an apparatus and method for generating a redemption code for a user to redeem an offer has been described. Yet further, the invention also extends to a computer-readable medium such as memory 108 of apparatus 100, having stored therein computer-readable instructions for executing under control of the processing device 102 the method for generating the redemption code. Of course, other types of computer-readable media are also embraced, such as portable devices, including flash storage devices.

The techniques disclosed above may be implemented for the generation and redemption of a redemption code for a user to redeem an offer. The "offer" can take one of many formats. As a first example, it may be an offer for admission to an attraction -- such as a museum, an art gallery or a leisure ride - at full or discounted price, or to a club or a concert.

Additionally, the techniques disclosed herein are also applicable to allow redemption of offers relating to, for example, meal deals at a restaurant or a fast-food outlet. Yet further, the techniques disclosed herein may also be utilised at, say, a convention for controlling access of the convention delegates who have paid the conference fee. Indeed, controlled access to different parts of, or events at, say, a convention, may also be implemented utilising the techniques disclosed herein.

It will be appreciated that the invention has been described by way of example only. Various modifications may be made to the techniques described herein without departing from the spirit and scope of the appended claims. The disclosed techniques comprise techniques which may be provided in a stand-alone manner, or in combination with one another.

Therefore, features described with respect to one technique may also be presented in combination with another technique.

Claims

1. Apparatus for generating a redemption code for a user to redeem an offer, the apparatus comprising:

a processor; and

a memory; wherein

the apparatus is configured, under control of the processor, to execute instructions stored in the memory:

to generate a partial redemption code comprising characters derived from a personal identifier for the user;

to generate a code check component using the partial redemption code; and to generate the redemption code using the partial redemption code and the code check component.

2. The apparatus of claim 1 configured to generate the redemption code comprising a string of characters and to generate the redemption code with the code check component inserted in the string of characters at one or more predetermined locations.

3. The^" apparatus of claim 2 configured to insert the code check component in the redemption code character string between characters from one or more other components of the redemption code.

4. The apparatus of any preceding claim, wherein the code check component comprises a check digit generated by the apparatus in a modulus 10 process.

5. The apparatus of any preceding claim configured to generate a transaction code component which is unique for a validity period of the offer and to generate the partial redemption code using the transaction code component.

6. The apparatus of claim 5 configured to generate the transaction code component randomly or quasi-randomly.

7. The apparatus of any preceding claim configured to generate the redemption code comprising a string of characters and to generate the redemption code with characters from the transaction code component inserted into the string of characters interspersed with other characters in the redemption code.

8. The apparatus of any preceding claim configured to generate the partial redemption code to comprise characters representing a validity period for the offer.

9. An apparatus for validating a redemption code for a user to redeem an offer, the apparatus comprising:

a processor; and

memory; wherein

to determine whether the redemption code is of a valid form using characters in the redemption code;

to determine whether the redemption code has expired; and

to signal redemption of the offer if the redemption code is of a valid form and the redemption co'de has not expired.

10. The apparatus of claim 9 configured to determine whether the redemption code has expired by extracting characters representing a validity period for the offer from the redemption code.

11. The apparatus of claim 9 or claim 10 configured to determine whether the redemption code is of a valid form using a check code component in the redemption code.

12. The apparatus of any of claims 9 to 11 configured to determine whether the redemption code is of a valid form in a modulus 10 process.

13. A method, implemented in an apparatus, for generating a redemption code for a user to redeem an offer, the method comprising, under control of a processor of the apparatus: generating a partial redemption code comprising characters derived from a personal identifier for the user;

generating a code check component using the partial redemption code; and generating the redemption code using the partial redemption code and the code check component.

14. A method, implemented in an apparatus, for validating a redemption code for a user to redeem an offer, the method comprising, under control of the processor of the apparatus:

determining whether the redemption code is of a valid form using characters in the redemption code;

determining whether the redemption code has expired; and

signalling redemption of the offer if the redemption code is of a valid form and the redemption code has not expired.

15. A computer-readable medium having stored thereon computer-readable instructions for executing, under control of a processing device, the method of claim 13.

16. A computer-readable medium having stored thereon computer-readable instructions for executing, under control of a processing device, the method of claim 14.