GB2412210A

GB2412210A - Redemption apparatus for a transaction

Info

Publication number: GB2412210A
Application number: GB0405992A
Authority: GB
Inventors: Ariya Priyasantha
Original assignee: ACTIVEMEDIA TECHNOLOGIES Ltd
Current assignee: ACTIVEMEDIA TECHNOLOGIES Ltd
Priority date: 2004-03-17
Filing date: 2004-03-17
Publication date: 2005-09-21
Anticipated expiration: 2024-03-17
Also published as: GB0405992D0; GB2412210B

Abstract

Voucher or ticket redemption apparatus for a transaction, in which authentication of the code embedded in e.g. a PIN or barcode (e.g. stored in a mobile phone 34) can be executed locally at the redemption device 10. The redemption device 10 decrypts and validates the code and stores data relating to the validated code. This data may be transmitted to server 50 as part of a batch process or on an ad-hoc or dynamic basis, which may be tried again later or using a different communication protocol in the event of a failed transmission (a "failover strategy"). The server 50 then transmits details of the validated code to other redemption devices. The codes are single-use codes so that a code is invalid if the voucher has previously been validated at the same or a different validation terminal.

Description

Voucher Redemption Device and Server The present invention relates to

voucher or ticket redemption schemes.

There are several known schemes for the implementation of voucher or ticket redemption. These schemes typically allow a user to purchase a mobile ticket or voucher by any of a number of means. For example, the customer may purchase a voucher/ticket or coupon on a website or in a telephone call with a service provider. The voucher/ticket is then transmitted to the customer by, for example, e-mail, or as a link to a web page or in an SMS-format message to the customer's mobile telephone. The voucher/ticket can be in the form of a PIN number (personal identification number), a barcode or other suitable means offering an appropriate level of security and reliability for both customer and service provider. Within the PIN or barcode there is often an encrypted code which holds details of the redemption value of the voucher/ticket. The customer can redeem the voucher/ticket for goods or services. At a point of redemption, which may be a retail outlet, such as a cinema, fast food restaurant, bookshop, bookmakers etc., the details of the voucher/ticket are fed into a redemption processing device with a keypad/screen/wireless connection interface that enables the PIN/barcode to be received and authenticated.

However, it is necessary for the redemption device to communicate with a central server in order to conduct the authentication process. Thus, customer transactions can involve long and inconvenient delays.

Further, connectivity problems are problematic in that, if no connection with the server is available, it is not possible to process a customer's voucher/ticket at that time.

Also, the redemption processing device generally requires a processing system with a substantial amount of processing power for controlling the transitions between states of operation of the redemption processing device. This device needs to perform a number of complex operations which include reading the voucher/ticket details, extracting the relevant code, decrypting the code, transmitting to the server details of the code, receiving from the server authorisation/validation of the code and transmitting the message conveying the validity of the voucher/ticket or an error message to the retail outlet employee.

Aspects of the invention are set out in the independent claims. Some preferred features are included in the dependent claims.

The present invention offers a number of advantages over known systems in l S that authentication of the code embedded in the PIN/barcode can be executed without any of the delay inherent in server-side communication and validation, whilst maintaining the required level of security for the customer and the service provider.

Embodiments of the invention provide two particular alternative authentication methods, both of which employ the same authentication algorithm. The first such method allows validation of the encrypted code at the redemption processing device. This avoids the need for immediate server communication and server-side validation. Thus, the method is more reliable and the processing time for each customer transaction can be reduced.

This authentication method lends itself to low-value, high-volume transactions such as the purchase of cinema tickets, redemption of promotions at fast-food outlets, etc., in which, although a central recording of validated codes is still required this can be delayed a short while until a connection with the server is available or more convenient and the codes can be transmitted in batches.

Periods between batch transmissions can then be set according to batch processing principles and/or depending on the preference of the user (e.g. the retail outlet chain).

The second method of authentication may still allow the validation of codes locally at the redemption processing device, and in methods of operation, the codes are additionally validated at the server. These are then transmitted ad hoc to the server (that is, substantially as they are received at the redemption processing device or shortly afterwards) for validation/authentication and central storage of the details related to the validated codes. This method of authentication lends itself more to low-volume, high-value transactions where security is more important and customer transaction processing time is secondary to this.

Even in situations where the second method of authentication is the preferred mode of authentication, it may be that connectivity with the server is unreliable. In the event that no connection can be made, the redemption processing device can revert to a variant of the first method of operation, thus offering authentication at the redemption device, so that it is possible to wait until a connection becomes available before transmitting data relating to the code to the server.

Embodiments of the invention will now be discussed, by way of example only, and with reference to the accompanying drawings in which: Fig. 1 is a block diagram of a device and a server according to the present invention; Fig. 2 is a block diagram illustrating the system architecture of the present invention; Fig. 3 is a flow diagram illustrating the process steps of an authentication procedure employed by the present invention; S Fig. 4 is a flow diagram illustrating the process steps of a synchronization procedure employed by the present invention; Fig. 5 is a flow diagram illustrating the process steps that a connection handler of the present invention executes; Fig. 6 is a block diagram illustrating a group of redemption devices according to the present invention; Fig. 7 is a block diagram illustrating an example of groupings of redemption devices according to the present invention; Fig. 8 is a flow diagram illustrating the process steps of a back-propagation thread employed by the present invention; IS Fig. 9 is a block diagram illustrating the architecture of the server-side processes of the present invention; and Fig. 10 is a state transition diagram illustrating an example of a code validation procedure at a redemption device of the present invention.

Figure 1 illustrates a redemption device 10 and a server 50 according to an embodiment of the present invention. The redemption device 10 comprises a memory 12, a receiver 14, a microprocessor 16, a read/write facility for reading from and writing to the memory, a transmitter 20, a connection handler 22, a resident thin state handler 30 and an optical reader 32 for receiving code details which, in the embodiment of Fig 1, comprises a PIN/barcode reader for reading a PIN/barcode 38 from a display 36 of a mobile phone 34. Other non-optical readers could be used according to the nature of the code being read. Examples of alternatives are magnetically stored data and acoustic tone each requiring a suitable reader or sensor.

The memory 12 also comprises an intent log 26, which is a temporary memory for storing details of recently-validated codes, and a PIN/record store 28 in which a permanent or semi-permanent record of all code numbers which have been validated/processed/redeemed is maintained.

The server 50 of the embodiment of Figure 1 comprises a code generation and encryption device 52, a server receiver 54, a server transmitter 56 and a server state handler 58.

The receiver 14 and transmitter 20 pair of the redemption device 10, and the receiver 54 and transmitter 56 pair of the server may each be in the form of transceivers.

In use, a customer purchases the voucher by a method such as those mentioned above. The server is loaded with the customer's personal details, which include: name, address, telephone number, mobile telephone type, a uset profile made up of his preferences, shopping habits etc. In embodiments of the invention, a bespoke voucher is generated for the type of mobile phone which is specified by the user or known from his userprofile.

When the customer wishes to redeem a voucher he/she presents a mobile phone 34 with the PIN/barcode 38 on the display 36 to the retail outlet assistant at a subscriber retail outlet of choice. The retail outlet assistant then either presents the PIN/barcode to the optical reader 32 of the redemption device 10 or this is done by the customer himself. The data on the voucher can be entered in other ways, for example manually via a keyboard if a reader or sensor is not used.

Within the PIN/barcode 38, is an encrypted code indicating the value of the voucher and, optionally, other details of the voucher, such as the types of goods/services against which it may be redeemed, and details of the customer.

There are embedded in the encrypted code by the server prior to transmission in SMS format to the customer's mobile phone. This code requires decryption and validation at the redemption device 10 and can be validated according to either of the preferred modes of operation.

The optical reader 32 in the redemption device 10 reads the details of the PIN/barcode 38 and extracts the encrypted code. The code is validated by the redemption device 10 applying a key-based decryption algorithm to the encrypted code. The key algorithm is either transmitted to the redemption device 10 over the communication channel 24 from the server 50 or factory installed in the redemption device 10. Furthermore, updates or changes to the key-based algorithm can be installed on the redemption device 10, by downloading them from the server 50. More details on the authentication process are given below with reference to Figure 3.

If it is determined that the PIN/barcode 38 is valid an appropriate acceptance message is conveyed to the retail outlet assistant with this information. The means for generating the message to the retail outlet assistant are not shown in Figure 1 for the sake of clarity. This may be visual, aural or by means of a generated ticket, voucher or receipt. If an invalid code has been detected - that is, the voucher has been previously validated at another retail outlet (which will be discussed below) or is otherwise unacceptable - another appropriate message is conveyed to the retail outlet assistant who then suspends the redemption process. Alternatively, an error may have occurred in reading the PIN/barcode 38 and yet another message is conveyed to the retail outlet assistant advising him of this, prompting him to re-present the PIN/barcode 38 for reading once more. To detect a mix-read code any of a number of known techniques can be used. For example, an error checking algorithm using a parity digit in the code.

Once a valid code has been established, the retail outlet assistant then redeems the voucher for the retail product of the user's choice, for example, a cinema ticket.

In the first mode of authentication, hereinafter referred to as "Immediate Authentication", the details of the code are input as described above. In this mode of operation, a real-time connection with the server is not required because authentication of the code is carried out by the redemption device 10.

In Immediate Authentication mode, the redemption device 10 is operable to transmit the data relating to one or more validated codes as part of a batch process. The data relating to the valid code may include the code itself, details of the redemption (e.g., time and place of redemption, nature of goods etc), the customer's name and address, mobile phone details, and/or any other details which the retail outlet chain deem appropriate and of interest. The frequency of data transmission can be set by the retailer or predetermined to take place at a time of low data traffic. Additionally, in the event of a failed transmission, the batch can be re-transmitted later. The server 50 then calls the backpropagation thread, as discussed below with relation to Figure 8, to transmit details of the validated code to other redemption devices which are grouped with the redemption device 10.

If the system and the redemption device 10 are operating in the second mode of authentication, hereinafter referred to as "Stored Authentication", data relating to the code are transmitted by the transmitter 14 of the redemption device 10 to the receiver 54 of the server 50 via the communication channel 24 on an ad hoc or dynamic basis. The data relating to the valid code may include the code itself (whether or not it has been validated by the redemption device 10 or needs validation by the server 50), or other details of the redemption as in Immediate Authentication mode. Once received at the server 50, the code is either validated for the first time or the data relating to the valid code is further processed, the exact arrangement being determined according to the security required for the particular application by the retail outlet chain.

A preferred method of Stored Authentication is that the validation is carried out at the server 50. In this way, a connection with the server is attempted at the time of the transaction. The data relating to the valid code is transmitted to the server, where a version of the authentication algorithm is run in order to validate the code. The data is not encrypted prior to transmission.

Once the server 50 has received the data relating to valid codes, either in Immediate or Stored Authentication modes, the server is then operable to process this data depending upon the particular application the retail outlet chain calls for. For example, in one application the server 50 is operable to communicate with a server or database of the retail outlet to provide dynamic inventory control; that is, dynamic pricing information and stock checking.

This provides an advantage in that, the retail outlet receives real-time feedback on transactions which may affect stock levels and/or pricing.

Figure 2 illustrates the system architecture used for the authentication techniques of the present invention. The architecture comprises an authentication thread 60, a state handler 62, a synchronization thread 64, a back-propagation thread 66 and a connection manager 68. Referring also to Figure 3, the process steps of the authentication procedure employed by the present invention uses an Authentication Thread to validate the codes.

The process begins at step 80. At process step 82 the redemption device 10 determines whether or not the code has been entered. A code to be validated is received at the redemption device 10 by presenting the encrypted PIN/barcode 38 on the display 36 of the mobile phone 34 to the PIN/barcode reader 32 in the redemption device 10. Once a code has been received by the redemption device 10, at process step 84 the code is passed through the key algorithm in order to determine whether or not the encrypted code is valid (discussed further below), a decision on which is taken at process step 86.

An encrypted code is generated at the server 50 for transmission to the customer's mobile telephone as described above. For each campaign for a particular retailer, it may be decided that, for example, 50,000 sequential PIN numbers are to be generated and generation, encryption and authentication of the encrypted PIN number utilises a variety of arithmetic-reversible functions.

When a customer purchases a voucher/ticket, he is allocated one of the sequential PIN numbers which is encoded with a seed of a key-based encryption algorithm to provide an encrypted code. This encrypted code is then transmitted to the customer. For each campaign for a particular retailer, a pre determined number of seeds are used. When the PIN/barcode 38 is read at the redemption device 10, the authentication thread applies the reverse function of the key-based encryption algorithm to extract two numbers from the encrypted code: the seed and the PIN. In the first step of validation of the code, the extracted seed is matched to a store of the seeds (which are factory installed in the redemption device 10 or received from the server 50 via communications channel 24) in the redemption device 10, a match being indicative that the PIN is a genuine PIN generated by the server 50. For the second step in the validation of the code the thread runs a look up of the PIN/Record Store 28 containing details of previously validated codes.

In the case of an invalid code, the redemption device 10 displays an appropriate error message at process step 88 if the code is invalid or has previously been processed and reverts to an idle state awaiting another code to be entered or re entry of the first code at process step 82. Once a valid code has been entered the code details are stored in the intent log 26 of the redemption device 10 at process step 90, for transmission to the server 50 under the control of the Synchronisation and Connection Handler Threads which are discussed below with reference to Figures 4 and 5 respectively. At process step 92, the code details are also stored in the record store 28 which is a non-volatile memory for retaining records of codes that have been validated. Once a code has been validated and stored the redemption device 10 presents to the retail outlet assistant or the customer application-specific information at process step 94.

This information may comprise further promotional information under the control of a state handler which is discussed in more detail with reference to Figure 10. At process step 96, the authentication thread ends and the Synchronisation Thread is started. Initiation of the timing of the Synchronisation Thread is dependent upon the method of authentication employed; if the system is in Immediate Authentication mode, the Synchronisation Thread will be delayed until expiry of the period set for the transmission of data relating to one or more valid codes stored in the intent log 26. If in the Stored Authentication mode, initiation of the Synchronisation Thread takes place at the time of transaction and is initiated, for example, by the storage of a valid code in the intent log 26.

Figure 4 illustrates the process steps of the Synchronisation Thread which operates in Immediate Authentication and Stored Authentication modes. Once the Authentication Thread is complete for the code being validated at process step 96, the Synchronisation Thread waits for notification that data relating to one or more valid codes is to be transmitted to the server. If the system is operating in Immediate Authentication mode, this notification will comprise a flag that the period for batch transmission has expired. If the system is operating in Server Authentication mode, this notification will comprise notification that the intent log 26 has been updated with data relating to a valid code. This notification is configurable depending upon the application called for and the desired mode of operation of the retail outlet chain.

At process step 104 the redemption device retrieves the latest entries from the intent log 26 and, using the Transmit Handler 23 converts the data from the intent log into packet data at process step 106 which is then sent on to the Connection Handler 24 at process step 108 for transmission to the server 50.

At process step 110, the intent log 26 is cleared pending storage of newly received valid codes. At process step 112 the Synchronisation Thread ends and the Connection Handler thread is called at process step 114.

As illustrated in Figure 5, packet data is received by the connection handler 22 from the Synchronisation Thread in process step 120. The connection handler 22 manages the connection between the redemption device 10 and the server 50 and operates a "failover strategy"; that is, if a connection in a first of a plurality of protocols is not available, the connection handler 22 will attempt to establish a connection with the server 50 in another protocol. The set of rules which the connection handler 22 applies to the failover strategy is fully configurable to suit the needs of the retail outlet and chain so that alternative failover strategies may be implemented as desired.

Typical connection protocols that can be used are GPRS (General Packet Radio Services), CSD (Circuit Switched Data), SMS (Short Messaging Service) and other wireless protocols. Alternatively, the system can communicate over a network (either wired or wireless) utilising, typically Ethernet or TCP/IP protocols. In this embodiment the preferred protocol is GPRS.

One of the main problems associated with maintaining GPRS connectivity is that the network infrastructure is not necessarily stable enough to guarantee a reliable network connection. Very often GPRS connections are down, or are very congested, leading to delays in network traffic. The connection handler provides a means of establishing communication in any of a number of protocols and implementing the failover strategy if communication with the server 50 is not available in the first (GPRS) protocol. Thus, in the event of GPRS congestion or failure, this embodiment of the invention will automatically switch to an alternative transmission protocol.

At process step 122, the connection handler 22 runs a check on GPRS availability via communications channel 24. If such a connection is available, the data relating to the one or more valid codes are transmitted to the server 50 by the transmitter 20 at process step 132. If a GPRS connection is not available the connection handler checks whether a CSD connection is available at process step 124. If this type of connection is available, the data is transmitted at process step 132. If neither GPRS nor CSD are available, the connection handler 22 runs a check for SMS availability with the server 50. If the connection handler determines that SMS messaging is possible, the Transmit Handler converts the packet data to SMS form at process step 130 and the Connection Handler transmits the data via the transmitter 20 at process step 132.

However, if no connection is available, i.e., communication with the server is temporarily unavailable, Connection Handler 24 waits at process step 128 until a connection is available or the appointed transmission time is reached. The Connection Handler Thread terminates at process step 134. Embodiments of the invention also allow data relating to a valid code to be converted directly to SMS format for transmission without first converting to packet data.

With reference to Figure 6, a group of redemption devices 10, lea, lOb and lOc communicate with the server 50 via the communication channel 24 each in the same manner that the single redemption device 10 communicates via communication channel 24.

The redemption devices 10, lea, 10b and lOc may be grouped according to various criteria. For example, they may be located in the same geographical region. Alternatively, they may be grouped as they are installed on separate premises of a retail outlet chain, or on different locations in the same outlet.

The redemption devices themselves may be part of a group or of a subgroup depending on the application called for. In Figure 7 an illustration of possible groupings is shown. Group 40b, which comprises redemption devices led and lee, is a sub-group of group 40a which also comprises redemption devices lea, lOb and lOc. A particularly advantageous feature of the present invention is its group flexibility. When the redemption devices are grouped according to Figure 6 or Figure 7 and operating in Immediate Authentication mode, once a code has been validated at a particular redemption device elsewhere within the group, the system of the present invention then communicates this fact to the other redemption devices in the group through the Back-Propagation Thread as illustrated in Figure 8.

Once a code has been validated, the server is made aware of this fact through the running of the Synchronisation Thread as described above. Then the back propagation thread is called for each redemption device within the group 40.

The thread starts at process step 140. At process steps 142 and 144, the redemption device 10 waits to see whether notification of the fact that a code has been validated at another redemption device within the group is received from the server 50. Once this notification is received at process step 146, encrypted data relating to the code which has been validated elsewhere is sent to the connection handler 22 at process step 148. The key algorithm of the redemption device 10 extracts and decrypts the data relating to the valid code which has been validated elsewhere within the group and, at process step 142, the record store 28 is updated and receipt of the data relating to the code validated elsewhere is transmitted back to the server at process step 154. The back-propagation thread ends at process step 156.

A significant benefit offered by implementation of the back-propagation thread is that all redemption devices in a group are kept fully up to date with details of vouchers which have been validated at other devices within the group. This feature can enhance the security of the system.

When the preferred mode of operation is Server Authentication and a connection with the server is not available, the redemption device 10 reverts to a variation of Immediate Authentication, called Local Authentication so that validation at the redemption device 10 may still take place. However, there arises a chance that, once a code has been validated, the customer may attempt to redeem the code at another redemption device in the group 40. Therefore, a decision as to whether the code should be validated in Local Authentication mode should be taken dependent upon the value of the voucher. When a connection with the server 50 has once again been established, the Synchronisation Thread of Figure 4 is run so that details of any codes which have been validated whilst the connection was unavailable are transmitted to the server 50. Once the fact of a second successful redemption has been communicated to the server 50, it is possible for a system administrator to take the appropriate action in respect of the customer, whose details are retained by the server 50.

It is also possible to configure the redemption device 10 and the server 50 so that, in Stored Authentication mode, when a periodic connection with the server 50 is established, the back-propagation thread is run so that all redemption devices within the group 40 are updated with other transactions within the group. However, in embodiments of the invention, the back propagation thread is not run in the Stored Authentication mode of operation as it may not be required. In normal operation in Stored Authentication mode, if a second attempt is made to validate the code once it has already been validated, the server 50 immediately notifies the redemption device 10 that the code is not valid, that it has already been validated and provides an appropriate error or security message.

The server-side architecture is illustrated in Figure 9. This comprises the group and client logical representations pertaining to the states of operation of the redemption device which are controlled by the server 50 (as discussed below), the scheduler 72, the synchronization handler 74 which interfaces with the redemption device 10 during the running of the synchronization thread, the back-propagation handler 76 and the connection manager 78.

An advantageous feature of the present invention is that the redemption device executes transitions between states of operation under control of a state handler which, in embodiments of the invention, is the state handler 58, resident in the server 50. This arrangement avoids the need for a fully functional state handler in the redemption device 10 and thereby reduces the required processing power of the redemption device. A reduced-functionality or "thin" microprocessor 16 is resident in the redemption device 10, thereby allowing the redemption device 10 to be less complex than would otherwise be required. In addition, the technology architecture can be applied to other hardware and software where remote management is required.

During operation, the redemption device 10 is always in exactly one state and is commanded in its transitions from one state of operation to anotherby virtue of communication to the server and the server state handler 58. A state of operation defines the functional stage of the application. One particular example of this operation is illustrated in Figure 10 where, at step 160, the client states are downloaded from the server. This is known as the Initialisation State 160. It is also possible to download the client states from the server 50 to the redemption device 10 in a continuous stream or as and when updates are required. The redemption device 10 sits in an idle state 162 until a PIN code is entered. In this example, a server response that a PIN code is valid is received at state 164 where personal details are entered. In this example the customer is female (which can be determined either from data embedded in the PlN/barcode 38 or as input information from the retail outlet assistant) and details of a promotion on handbags are given to the customer at step 166. If the customer is male, men's shirts may be offered at step 168. The decision as to which promotions to offer can be made from the user's personal details which are embedded within the PIN/barcode 38 and can be derived in a number of ways. For example, the user's profile or salient details of the profile may be embedded within the PIN/barcode 38 and, from communication with the server if required, sufficient data is available to make a decision based upon the customer's preferences and shopping habits, as to which promotional material should be presented to the customer. The decision may also be made by the retail outlet or the retail outlet assistant.

Referring again to Figure 10, it will be noted that, if the server response is that an invalid PIN code has been entered, an error message is displayed at step 170 and the redemption device reverts to the idle state 162.

The redemption device 10 also contains a thin state handler 30 for use when a connection with the server is not available (i.e., connectivity when the server is down) or when Immediate Authentication is the preferred mode of operation of the redemption device. The thin state handler 30 has a reduced functionality when compared with the server state handler 58 and provides reduced functionality which is required to operate the redemption device where connection to the server is not available.

It will be understood that the present invention has been described purely by way of example and that modifications of detail can be made within the scope of the invention. For example, while the invention is described in relation to a single redemption transaction, it is equally the same that a set number of multiple redemption transactions could be enabled for certain codes. Likewise, redemption offers may be time limited. Thus, a redemption out of a set period or beyond a predetermined date may be treated as invalid. While mobile phones are described as means of carrying the coupon data, it is equally possible to use other loadable data carriers with a display, or other means of detecting the code for redemption by a suitable reader or sensor at the point of redemption. Each feature disclosed in the description, claims and drawings may be provided independently of in any appropriate combination.

Claims

Claims 1. Redemption apparatus for a transaction comprising: means for

storing data for validating transaction codes; means for receiving a code; means local to the transaction for validating the code as a transaction code; and means for updating the data for validating transaction codes according to the validated code.
2. Redemption apparatus according to claim 1, wherein the means for updating the data for validating transaction codes comprises means for storing data relating to the transaction code.
3. Redemption apparatus according to claim 2, wherein the means for validating the code as a transaction code comprises means for comparing data relating to the transaction code with data relating to transaction codes which have been stored previously.
4. Redemption apparatus according to any preceding claim, further comprising means for receiving a key algorithm and wherein the means for validating the code as a transaction code further comprises means for applying the key algorithm to the code.
5. Redemption apparatus according to any preceding claim, further comprising means for transmitting to a server data relating to a transaction code.
6. Redemption apparatus according to any preceding claim, further comprising means for determining whether a connection with the server is available and means for delaying transmission of the data relating to the transaction code pending a connection becoming available. s
7. Redemption apparatus according to claim 5 or claim 6, wherein the device is operable to transmit the data relating to a transaction code in a batch process.
8. Redemption apparatus according to any of claims 5 to 7, wherein the device is operable to transmit the data related to a transaction code dynamically.
9. Redemption apparatus according to any of claims 5 to 8, further comprising means for receiving, from the server, data relating to transaction code which has been validated elsewhere.
10. A device for validating an encrypted code, the device comprising: a memory; means for receiving a code to be validated; means for determining whether the code is valid; means for storing data relating to a valid code in the memory; and means for transmitting data relating to the valid code to a server.
11. A device according to claim 10, wherein the device further comprises means for determining whether a connection with the server is available and means for delaying transmission of the data relating to the valid code pending a connection becoming available.
12. A device according to claim 11, wherein the device is operable to transmit the data relating to the valid code in a batch process.
13. A device according to claim 10 or claim 1 1, wherein the device is operable to transmit the data relating to the valid code dynamically.
14. A device according to any of claims 10 to 13, further comprising means for receiving, from the server, data relating to a valid code which has been validated elsewhere, the device being operable to store in the memory the data related to the valid code which has been validated elsewhere.
15. A device according to claim 14, further comprising means for acknowledging to the server receipt of the data relating to the validated code which has been validated elsewhere.
16. A device according to any of claims 10 to 15, wherein the device is operable to communicate with the server in any of a plurality of protocols.
17. A device according to claim 16, further comprising means for implementing a failover strategy wherein, if communication with the server in a first of the plurality of protocols fails, the device is operable to attempt to communicate with the server in another of the plurality of protocols.
18. A device for validating an encrypted code, the device comprising means for communicating with a server in any of a plurality of protocols and means for implementing a failover strategy wherein, if communication with the server in a first of the plurality of protocols fails, the device is operable to attempt to communicate with the server in another of the plurality of protocols.
19. A device according to claim 17 or claim 18, further comprising means for configuring the failover strategy.
20. A device according to any of claims 10 to 19, further comprising means for converting the data relating to the valid code into packet data, the device being operable to transmit the data in packet form to the server.
21. A device according to claim 20, further comprising means to convert the packet data to SMS format.
22. A device according to any of claims 10 to 21, further comprising means to convert the data relating to the valid code into SMS format.
23. A device according to any of claims 10 to 22, wherein the device is operable to communicate with the server in the GPRS protocol.
24. A device according to any of claims 10 to 23, wherein the device is operable to communicate with the server over a CSD connection.
25. A device according to any of claims 10 to 24, wherein the device is operable to communicate with the server in SMS format.
26. A device according to any of claims 10 to 25, wherein the device is operable to communicate with the server over a network utilising, for example, ethernet technology.
27. A device according to any of claims 10 to 26, further comprising means to, once a code has been validated, provide information deemed to be relevant to a user.
28. A device according to any of claims 10 to 27, wherein the device is operable to execute a transition between states of operation under the control of a state handler resident in the server.
29. A device for validating an encrypted code, the device being operable to execute a transition between states of operation under the control of a state handler resident in a server.
30. A device according to claim 28 or claim 29, wherein the device further comprises a thin state handler, operable to control execution of a transition between states of operation of the device when no connection with the state handler is available.
31. A device according to any of claims 10 to 30, further comprising means to read details of the encrypted code optically.
32. A device according to claim 31, operable to read a two-dimensional encrypted code such as a bar code.
33. A device according to claim 31 or claim 32, operable to read the encrypted code from a display of a mobile communication device.
34. A device according to any or claims 10 to 33, further comprising means to receive details of the encrypted code which have been input by a user.
35. A server for interfacing with a device for validating an encrypted code, the server comprising: means for encrypting a code; means for transmitting the encrypted code to the device; means for receiving, from the device, data relating to a valid code.
36. A server according to claim 35, wherein the server is operable to receive the data relating to the valid code in a batch process. s
37. A server according to claim 35 or claim 36, wherein the server is operable to receive the data relating to the valid code dynamically.
38. A server according to any of claims 35 to 37, further comprising means for transmitting, to the device, data relating to a valid code which has been validated elsewhere.
39. A server according to any of claims 35 to 38, further comprising means for receiving, from the a device, acknowledgement of receipt of the data relating to a valid code which has been validated elsewhere.
40. A server according to any of claims 35 to 39, wherein the apparatus is operable to communicate with the device in any of a plurality of protocols.
41. A server according to claim 40, further comprising means for implementing a failover strategy wherein, if communication in a first of the plurality of protocols with the device fails, the server is operable to attempt to communicate with the device in another of the plurality of protocols.
42. A server for interfacing with a device for validating an encrypted code, the server comprising means for communicating with the device in any of a plurality of protocols and means for implementing a failover strategy wherein, if communication with the device in a first of the plurality of protocols fails, the server is operable to attempt to communicate with the device in another of the plurality of protocols.
43. A server according to claim 41 or claim 42, further comprising means for configuring the failover strategy.
44. A server according to any of claims 35 to 43, further comprising means for receiving the data relating to the valid code in packet form.
45 A server according to any of claims 35 to 44, wherein the server is operable to communicate with the device in the GPRS protocol.
46. A server according to any of claims 35 to 45, wherein the server is operable to communicate with the device over a CSD connection.
47. A server according to any of claims 35 to 46, wherein the server is operable to communicate with the device in SMS format.
48. A server according to any of claims 35 to 47, wherein the server is operable to communicate with the device over a network utilising, for example, ethernet technology.
49. A server according to any of claims 35 to 48, wherein the server Further comprises a state handler for controlling execution of a transition between states of operation of the device.
50. A server for interfacing with a device for validating an encrypted code, the server comprising a state handler for controlling execution of a transition between states of operation of the device.
S1. A method of redeeming a code in a transaction, the method comprising: storing data for validating transaction codes; recevmg a code; validating the code as a transaction code locally to the transaction; and S updating the data for validating transaction codes according to the validated code.
52. A method according to claim S 1, wherein the step of updating the data for validating transaction codes comprises storing data relating to the transaction code.
53. A method according to claim 52, wherein the step of validating the code as a transaction code comprises comparing data relating to the transaction code with data relating to transaction codes which have been stored previously.
54. A method according to any of claims S 1 to 53, further comprising receiving a key algorithm and the step of validating the code as a transaction code further comprises applying the key algorithm to the code.
SS. A method according to any of claims S 1 to 54, further comprising transmitting to a server data relating to a transaction code.
56. A method according to any of claims S 1 to SS, further comprising determining whether a connection with the server is available and delaying transmission of the data relating to the transaction code pending a connection becoming available.
57. A method according to claim SS or claim 56, further comprising transmitting the data relating to a transaction code in a batch process.
58. A method according to any of claims S5 to 57, further comprising transmitting the data related to a transaction code dynamically.
59. A method according to any of claims 55 to 58, further comprising receiving, from the server, data relating to transaction code which has been validated elsewhere.
60. A method of validating an encrypted code comprising: receiving a code to be validated; determining whether the code is valid; storing data relating to a valid code in a memory; and transmitting data relating to the valid code to a server.
61. A method according to claim 60, further comprising determining whether a connection with the server is available and delaying transmission of the data relating to the valid code pending a connection becoming available.
62. A method according to claim 61, further comprising transmitting the data relating to the valid code in a batch process.
63. A method according to claim 60 or claim 61, further comprising transmitting the data relating to the valid code dynamically.
64. A method according to any of claims 60 to 63, further comprising receiving, from the server, data relating to a valid code which has been validated elsewhere, and storing in the memory the data related to the valid code which has been validated elsewhere.
65. A method according to any of claims 60 to 64, further comprising acknowledging to the server receipt of the data relating to the validated code which has been validated elsewhere.
66. A method according to any of claims 60 to 65, further comprising communicating with the server in any of a plurality of protocols.
67. A method according to claim 66, further comprising implementing a failover strategy wherein, if communication with the server in a first of the plurality of protocols fails, the failover strategy makes an attempt to communicate with the server in another of the plurality of protocols.
68. A method for validating an encrypted code, the method comprising communicating with a server in any of a plurality of protocols and implementing a failover strategy wherein, if communication with the server in a first of the plurality of protocols fails, the failover strategy attempts to communicate with the server in another of the plurality of protocols.
69. A method according to claim 67 or claim 68, further comprising configuring the failover strategy.
70. A method according to any of claims 60 to 69, further comprising converting the data relating to the valid code into packet data and transmitting the data in packet form to the server.
71. A method according to claim 70, further comprising converting the packet data to SMS format.
72. A method according to any of claims 60 to 70, further comprising converting the data relating to the valid code into SMS format.
73 A method according to any of claims 60 to 72, further comprising communicating with the server in the GPRS protocol.
74. A method according to any of claims 60 to 73, further comprising communicating with the server over a CSD connection.
75. A method according to any of claims 60 to 74, further comprising communicating with the server in SMS format.
76. A method according to any of claims 60 to 75, further comprising communicating with the server over a network utilising, for example, ethernet technology.
77. A method according to any of claims 60 to 76, further comprising, once a code has been validated, providing information deemed to be relevant to a user.
78. A method according to any of claims 60 to 77, further comprising executing a transition between states of operation under the control of a state handler.
79. A method of validating an encrypted code in a device, the method comprising executing a transition between states of operation of the device under the control of a state handler resident in a server.
80. A method according to claim 78 or claim 79, further comprising controlling execution of a transition between states of operation of the device with a thin state handler resident in the device when no connection with the server is available. s
81. A method according to any of claims 60 to 80, further comprising reading details of the encrypted code optically.
82. A method according to any of claims 60 to 81, further comprising reading a two-dimensional encrypted code such as a bar code.
83. A method according to claim 81 or claim 82, further comprising reading the encrypted code from a display of a mobile communication device.
84. A method according to any of claims 60 to 83, further comprising receiving details of the encrypted code which have been input by a user.