GB2478147A

GB2478147A - System for exercising tokens

Info

Publication number: GB2478147A
Application number: GB1003249A
Authority: GB
Inventors: Timothy Paul James Gerard Kindberg
Original assignee: MATTER 2 MEDIA Ltd
Current assignee: MATTER 2 MEDIA Ltd
Priority date: 2010-02-26
Filing date: 2010-02-26
Publication date: 2011-08-31
Also published as: GB201003249D0

Abstract

A system is described for exercising uniquely identifiable tokens, such as vouchers, coupons or loyalty means stored on mobile devices. The system comprises terminals (140) with display means (134), processing means (144) and local wireless communication means (128), a token service (100) comprising a plurality of records (102) describing the properties of tokens and their historic usage. A token is exercised from a mobile device (120) at a terminal (140), resulting in a service or resource specified by the corresponding records (102). The processor (106) is arranged to verify the exercise of the token against the terms of use described in the records (102). In particular, the terms of use may include constraints on the location of the mobile device (120) that exercises the token. The processors (106 and 144), communicating together via a network (110), and communicating with the mobile device (120) via either a local wireless network (126) or a cellular network (130), are arranged to verify the location of the mobile device (120). Tokens can be contained in electronic business cards or web bookmarks, to facilitate their convenient storage, retrieval, sharing between users, and communication to the system described. Random identifiers, in particular identifiers chosen at random, are provided by the terminals (140) to aid in the evaluation of an implied location. The invention enables users to benefit from services or resources obtained by visiting places with terminals.

Description

Invention title: System and Method for Exercising Data Tokens

Field of the Invention

The present invention relates to data communication. In particular, but not exclusively, the invention relates to a system arranged to respond to tokens exercised from one or more mobile devices in order to provide services or resources to those devices or their owners, and to do so subject to verification of the location of the mobile devices.

Background to the Invention

Retail organisations have devised ways of motivating consumers to visit their environments and make purchases. These include coupons, which can be redeemed against purchases; and loyalty cards, which are presented at purchasing time in order to receive discounts. In return, the organisation makes sales that it may not otherwise have made, and gathers data about consumer behaviour. Conventionally, consumers acquire coupons in paper form from newspapers, direct mail etc. Conventionally, consumers register for loyalty cards and receive them in a physical form.

However, given their physical form, coupons and loyalty cards are liable to be forgotten or mislaid, or not used at all because of the perceived inconvenience of acquiring, carrying and presenting them.

From the retailer's perspective, while loyalty cards enable the monitoring of consumer behaviour over time, this is not always possible with paper coupons, which do not necessarily record anything about the identity of the coupon holder.

It is generally recognised that mobile phones and other types of mobile device can be used to enhance the retail experience for consumers, and increase sales and other factors of interest to retailers. Examples are: mobile coupons stored electronically on mobile devices, which users carry into retail environments to redeem instead of paper coupons; and mobile loyalty cards stored electronically on mobile devices, which users present electronically in retail environments.

In addition, the same mobile device can be used to obtain other benefits in retail environments, such as information about products, in-store navigation, payment, and self-checkout. From the retailer's point of view, those benefits would preferably be obtained in such a way that data about the consumer's behaviour could be gathered, just as purchasing behaviour is tracked via loyalty cards. They may also wish to make suggestions to consumers based in part on that observed behaviour.

Retail environments include not just individual shops but also places containing several shops such as shopping centres, strip malls, and airport retail environments. Those may also issue coupons, for redemption in one or more of the shops they contain; or they may issue loyalty cards that apply to more than one shop; or they may provide information and other services whose usage they wish to monitor in relation to individual behaviours.

In addition to retail environments, the owners of other types of space may wish to motivate people to visit their spaces through coupons, loyalty cards, etc. And they may also wish to provide mobile services to people visiting their spaces in such a way as to monitor, and seek to influence, the behaviours of identifiable consumers. Examples of those other spaces are theme parks, music festivals, cafes and restaurants, transportation hubs and social venues.

Patent application GB2351827 "Loyalty Schemes" (WOODS SARAH [GB); MACKAY ROBIN (GB)) focuses on the social aspects of loyalty cards. It describes a system in which physical loyalty cards are collected and swapped, in particular between children and between parents and children, for redemption at public terminals. But collecting physical cards is inconvenient. Especially with the rise of social networking, the ability to collect and swap virtual coupons and loyalty cards would be a major advantage.

In all of the cases described above, the user presents a token of some kind at the point of purchase or service consumption. That token both conveys eligibility for one or more services or resources and, in some cases, the identity of the user (whether this is a true personal identity or a pseudonymous identity).

To replace physical paper and cards, various mobile technologies have been proposed.

These include: 1. Acquiring a token as text in an SMS message, storing the message on the mobile device like any other message and, to exercise the token, presenting it on the screen of the device to be read by a machine (using OCR) or transcribed by a human.

2. Acquiring a token as a barcode in an SMS or MMS message, storing the message on the mobile device like any other message and, to exercise the token, presenting the barcode for reading by a barcode-reading device.

3. Acquiring a token with an NFC (Near-Field Communication) device integrated into the mobile device, storing it there, and presenting the code to another NFC device for exercise.

The first two of those methods have the advantage that tokens can be acquired on any mobile phone. However, these two methods use the general message-store to hold tokens. This is typically not indexed or searchable in convenient ways for users to locate tokens to present. Another disadvantage is that they require either human transcription for exercise, or the presence of specialised devices such as devices performing optical character recognition or barcode reading.

Unlike the first two methods, the third method is rarely applicable, since NFC is rarely integrated into mobile devices outside certain parts of the Far East.

In addition, it is known for the exercise of a token such as a coupon to be dependent on the location of the user at the time of exercise. For example, a retail establishment may require the user to visit one of a restricted set of physical locations in order to benefit from a coupon, in order to promote visits to those locations. Hitherto, such methods have often relied on a location technology for mobile devices such as GPS or cellular methods. However, GPS is not available indoors or even outdoors in many urban locations. When it is available, the accuracy is highly variable and it will often not be possible to determine whether the mobile device is in one place rather than a nearby place. Similarly, location methods based on the cellular wireless infrastructure tend to be highly inaccurate.

Yet other existing methods include self-reporting of location, but users may state their location falsely, defeating the objective of the token providor.

Objectives of the invention It is an objective of this invention to provide tokens that may be stored electronically on mobile devices, to avoid the inconvenience of carrying physical tokens.

It is an objective of this invention to enable users to store these virtual tokens on any mobile device, without the need for application software other than what is generally pre-installed on the device.

It is an objective of this invention to facilitate the sharing of these tokens between users.

It is an objective of this invention to facilitate the finding of a particular token from the collection of tokens on a mobile device, for use in a particular location or situation.

It is an objective of this invention to enable the exercise of any particular token to be constrained to take place at one or more specified physical locations, and for the determination of the location at the time of exercise to be made accurately and in all required physical circumstances.

It is an objective of this invention to fulfill all of the above objectives for tokens whether they act as coupons, as loyalty cards, or as entities with any other type of service or resource obtainable by the holder of the token, whether that service or resource is monetary, experiential, or of any other type.

Description of the drawings

Figure 1 is a schematic diagram of apparatus for implementing an embodiment of the present invention.

Figure 2 is a flowchart describing a process for distributing a token to a mobile device in an "envelope" such as a business card, and for exercising the token from that device by sending the envelope over a wireless personal area network such as Bluetooth.

Figure 3 is a flowchart describing a process for distributing a token to a mobile device, and one method for validating the device's location while exercising the token from that device using a wireless local area network such as Wi-Fi (802.11).

Figure 4 is a flowchart describing a process for distributing a token to a mobile device, and a second method for validating the device's location while exercising the token from that device using a wireless local area network such as Wi-Fi (802.11).

Figure 5 is a flowchart describing a process for distributing a token to a mobile device, and a method for validating the device's location while exercising the token from that device using any wireless access point, cellular or otherwise.

Detailed description of the invention

Figure 1 shows, schematically, apparatus for implementing an embodiment of the present invention. The apparatus for exercising tokens is divided into two parts: a token terminal 140 at which a token stored on a mobile device 120 is exercised, and a token service 100 that validates the token. The token terminal is installed in a public place such as a shop. The token service may be installed remotely and accessed from the token terminal via a network 110, or directly from a mobile device via a cellular wireless connection 130.

S

The token terminal may consist solely of a display 134, electronic or otherwise.

Optionally it contains processing means 144, storage means 142 and local wireless communication means 128.

The token service 100 is implemented using processing means 106, storage means 104 containing records 102 and attachment to the network 110.

The mobile device optionally has an interface 122 to wide-area (cellular) network connection 130 and a local or personal area wireless network interface 124 to a network 126 such as Bluetooth or Wi-Fi (802.11). In the former case, the mobile device can communicate with the token service 100 via cellular infrastructure 132 connected to network 110.

With respect to the tokens, in a preferred embodiment of this invention, the tokens are data values stored in electronic business cards (also known as personal information cards). Electronic business cards may be stored according to the vCard standard or in any other standard format, for example XML.

These electronic business cards can be transmitted to or from a mobile device in many ways, including by SMS, as an email attachment, as a web upload or download, via direct transmission between devices using for example Bluetooth or a cable, and by reading the business card data encoded in a barcode. Many methods have been devised for transferring business cards and other methods may be devised for doing so. By default, at least one such method is provided on the majority of current mobile devices.

Moreover, many services exist for managing collections of electronic business cards online.

All mobile phones and most other types of electronic device contain an application for managing the user's electronic business cards, often called a "Contacts" application.

Such applications index the electronic business cards by name and sometimes by other fields. They facilitate searching for contacts by name and sometimes by other fields.

They facilitate the transmission of electronic business cards, typically by SMS, Bluetooth, infrared, email, and presentation in the form of a barcode on the device's screen, for another device to read.

It will be apparent to one skilled in the art that there are various ways of incorporating the name of the token and the token itself in an electronic business card. Preferably, the

following vCard fields are used.

The N' or Name field is mandatory in the vCard specification. The value is a concatenation of the Family Name (first field), Given Name (second field), Additional Names (third field), Name Prefix (fourth field), and Name Suffix (fifth field) strings. This is preferably used to store the name of the token (first and second fields), and optionally

the value of the token (remaining fields).

The Uniform Resource Locator (URL') field. This is preferably used to store the token itself in the form of an http:' or https:' URI. For example, http://example.org/3278492133423472143092 189 identifies a token issued by example.org'. To access the web resource at this URL is to attempt to exercise the token or to obtain a description of it prior to exercising it.

The Electronic Mail (EMAIL') field. This can be used as an alternative field to store the token, for example in the format <token data> @ <token issuer's domain>, for example 3278492133423472143092189@example.org. To send an email to this address would be to invoke the token or obtain a description of it prior to exercising it.

It will be apparent to those skilled in the art that alternative ways exist for storing token names and tokens in electronic business card format. One advantage of the preferred method described above is that token names appear in the user's "Contacts" list, e.g. by the names of retailers where they may be used. They are thus easy for the user to find.

Another advantage of the preferred use of the URL' or EMAIL' fields is that the mobile device supports the exercise of the token directly by the user: when the user clicks on the URI or email address in the electronic business card, the Contacts' application launches the web browser to view the web resource at the token's URI, or the email client to transmit the token and receive a response..

An example of a token embedded in an electronic business card (vCard format) is as follows: BEGIN:VCARD VERSION:2.1 N:Marks & Spencer;Coupon for URL:http://www.marksandspencer.com/coupon/8231412447315131231232374 NOTE:Use this note to specify search terms or options END: VCARD When an electronic business card is transmitted to another mobile device, the receiving device displays the business card and can save it in the Contacts list of the receiving device. Thus one person can transmit a token directly to another person, for convenient use by that other person.

Another advantage of electronic business cards for the purposes of token exercise is that they can include a free-text "NOTE:" field. For example, a user can enter search terms into this field, to obtain location-specific search results at a token terminal; or they can use the field to enter a specification of a particular service required while exercising the token.

Not all mobile devices at the time of writing support the sharing of electronic business cards directly with another mobile device; in particular, that deficiency applies to Apple iPhonesTM and phones based on the Android1M operating system. In an alternative embodiment of this invention, the token is a URL that is stored and shared as a "bookmark" in the mobile device's web browser. The name of the bookmark is the title of the corresponding web page, which can be similar to the name used in a business card, for example "Coupon for Marks and Spencer". Many mobile devices come with a web browser installed that is capable of storing bookmarks, searching for them by their title, and sharing them by Bluetooth, email or SMS. However, not all mobile devices have web browsers; not all web browsers provide facilities to share bookmarks; and not all users are familiar with using the mobile web or wish to use it, due to concerns about the costs of mobile data plans. Therefore the electronic business card embodiment is preferred.

This invention incorporates "token terminals": devices or signs situated where tokens can be exercised in physical places such as shops and social venues, or in any other type of location.

In one embodiment, the token terminal is a device that receives electronic business cards containing tokens. In this embodiment, to exercise the token, the owner of a mobile device selects the token's electronic business card and sends that electronic business card to the token terminal. A preferred method of transferring the electronic business card to a token terminal is Bluetooth. In sending the electronic business card, the user performs Bluetooth discovery to look for the Bluetooth friendly name of the token terminal. That name may be made known to the user in several ways. For example, it may be displayed on the token terminal or written in accompanying leaflets.

Other ways of making known the Bluetooth friendly name are possible. Preferably, the name is chosen to be obvious; it consists of or includes the name of the place where the token terminal resides, for example "Marks & Spencer".

Bluetooth is a preferred method for sending electronic business cards to token terminals for two reasons. Firstly, Bluetooth is available on most mobile devices and it is free to use. Secondly, since Bluetooth is a short-range radio transmission technology, the fact that a business card is received over Bluetooth implies that the sender is physically nearby. Therefore, it is possible to implement policies governing the terms of use of a token, whereby the token may be exercised only in one or more specific locations. If, for example, the policy is for a token to be exercised only at a certain shop, then its receipt over Bluetooth at a token terminal in that shop is evidence that the policy has been satisfied.

One skilled in the art will be aware that there exist alternative technologies to Bluetooth for transferring the electronic business card to the token terminal, such as IrDA (infrared) and NFC. Both are free to use and use of either provides evidence that the bearer of the token is nearby. However, they are not widely available on mobile devices.

Yet other technologies that could be used for transferring the electronic business card in situ are SMS and email. The token terminal, or some other artifact nearby, could display a telephone number or email address for the user to send the business card to. However, if that information is static, then neither SMS nor email by itself (assuming the email is sent over the cellular network and not a local network) provides any evidence about the location of the person exercising the token, since they could be freely advertised over the internet, for example.

By whatever means the electronic business card is transmitted, the token terminal -or a service associated with it -receives the electronic business card and parses the data in the card to extract the token. It will be evident to one skilled in the art that this can be carried out by examining data from selected fields in the electronic business card. For example, the parsing software can extract whatever URI is in the URL' field of a vCard.

The token, or a value derived from the token, is used to access a database of records about the token. Some of that data concerns the token its elf: a description of the service or resource obtainable when the token is exercised; and the terms under which the token can be exercised. Other data records contain details of any previous exercises of the token. All of the aforementioned records are indexed by the token itself or a value derived from it.

A token service with access to the aforementioned database and associated with the token terminal verifies the legitimacy of the token and verifies that the exercise is within the terms of use. For example, it can verify that the token is one that was issued by the alleged authority. And it can verify whether, for example, a token that may be exercised only once has not been exercised before.

By known means, tokens can be made hard to guess, for example through the use of long random strings. Moreover, their authenticity can be verified against a database of bona fide tokens or verified by well-known cryptographic means including the use of techniques such as digital signatures or cryptographic hash functions.

Moreover the token service associated with a token terminal can verify that the terms of use applied to the token by its issuer have not been breached. For example, the token may have expired; it may have been issued for a limited number of uses; it may be for use only at certain locations. It will be evident to one skilled in the art that the parameters governing the terms of use of a token can be stored along with the token (or data derived from the token) in a database; that the details of all prior exercises of the token can also be stored in the database; and that the terms of use can be evaluated against all the aforementioned data at the time of exercise.

The token service declines the exercise of the token if the terms of use have not been satisfied. Otherwise, it looks up the services (or resources) that become available upon exercise of the token and offers, delivers or executes them to or for the user.

A service (or resource) obtained on exercise of the token may be provided in a variety of ways. For example, the token may provide a discount at the point of purchase.

As another example, a resource provided when the token is exercised may be content that is sent to the mobile device, such as a video clip, or premium information of interest to the user.

As another example, the service provided when the token is exercised may be participation in an activity such as a lottery or a vote, or an Alternate Reality Game.

As another example, the service provided when the token is exercised may be the addition of points to an associated loyalty scheme. Alternatively, loyalty points may be added as a side-effect when the token is redeemed for some other service.

As another example, the token may be turned into a further token or ticket designed to be readable nearby according to whatever method is available there. For example, the token terminal that receives the electronic business card may as a result print a further token that can be read or transcribed at a nearby Point of Sale, for example a barcode readable by a laser scanner. Or it may issue an image of a 2D barcode to the user's mobile device, which can be read at a Point of Sale by an image-based barcode reader.

Alternatively, the second token could be for use as a ticket to gain entry to a restricted place.

It will be appreciated that tokens, as described above, in the form of electronic business cards, may behave like paper coupons, or they may behave like loyalty cards, or a combination of the two. The user may conveniently delete from their Contacts' application electronic business cards containing used-up tokens, or they may keep in their Contacts' application the electronic business cards containing tokens of persistent value.

The same considerations apply, mutatis mutandis, when tokens are implemented as web bookmarks, which may be sent to token terminals in similar ways as for electronic business cards.

Figure 2 is a flowchart describing the aforementioned process for exercising a token over Bluetooth or a similar short-range wireless network.

At step 200 a token is stored as data in an "envelope" which is an electronic business card or web bookmark or similar sharable information entity. This is transmitted by existing widely applicable means such as SMS at step 202 to a mobile device. At step 204, the user of the mobile device sends the envelope to a token terminal via short-range wireless means such as Bluetooth. The token terminal extracts the token from the envelope in step 206, and transmits it to the token service for validation in step 208, in so doing identifying itself as the location of exercise. The token service checks that the token is being exercised in accordance with its terms of use, including any constraints on the location of exercise. If the exercise passes those tests, the corresponding service or resource is provided in step 210.

In another embodiment, the token terminal is a device containing a wireless local area network access point such as a Wi-Fi (802.11) access point. In this embodiment, to exercise the token, the owner of a Wi-Fl-enabled mobile device connects to the token terminal's access point, then clicks on the token's URI in an electronic business card or a bookmark in the browser to access the corresponding web resource.

Wi-Fi is a preferred method for exercising tokens at token terminals for two reasons.

Firstly, Wi-Fi is available on increasingly many mobile devices and it is free to use.

Secondly, since Wi-Fi is a short-range radio transmission technology, the fact that a token's URI is accessed over Wi-Fi implies that the sender is physically nearby. If the service for verifying and exercising tokens described above resides in the token terminal, then this service automatically handles only tokens exercised by users who are nearby. If, on the other hand, this token service resides on another network, then it is necessary to provide evidence to that service of whether the exerciser of the token resides at the assumed location. The token terminal, qua Wi-Fi access point, can intercept the mobile device's communications when the device accesses the token's URI, in such a way as to provide that evidence to a remote token service.

In particular, the token terminal may act as a proxy for all the traffic between mobile devices connected on the Wi-Fi network and the token service. For example, the token terminal can use a secure and authenticated channel such as one created by the TLS (Transport Layer Security) protocol to forward all web requests addressed to the token URI to the token service and in doing so verifying that the request was received over a local wireless channel.

Alternatively, the token terminal can redirect mobile devices accessing the token URI to another URI that addresses the token service directly and contains data that authenticates the location of the mobile devices to the token service. For example, the query string of the redirected URI may include an identifier of the token terminal, and encrypted values respectively of a nonce and the Exclusive-Or of the nonce with the current date and time, using a key shared between only the token service and the token terminal. The token service can then verify that the requestor's location is vouched for by the terminal at that location, without vulnerability to a known-plaintext attack. It does so by decrypting the two encrypted values, taking the Exclusive-Or of the two resultant values, and comparing the result with the current date and time. It will be apparent to one skilled in the art that variations on this authentication scheme are possible.

Figures 3 and 4 are flowcharts that show the process of distributing tokens as URIs and exercising them at token terminals that act as Wi-Fi or similar local area network access points.

At identical steps 300 and 400 a token is stored as an http(s) URI that references the token service, in an "envelope" which is an electronic business card or web bookmark or similar sharable information entity. This envelope is transmitted by existing widely applicable means such as SMS at identical steps 302 and 402 to a mobile device. At identical steps 304 and 404, the user connects the mobile device to the token terminal acting as an 802.11 or similar wireless access point, and at identical steps 306 and 406, the user navigates to the token's URI in the envelope.

In step 308, the token terminal acts as a proxy: it adds its own identifier as the mobile device's location to the mobile device's web request, and forwards the request over a secure, authenticated channel that it shares with the token service. The token service checks that the token is being exercised in accordance with its terms of use, including any constraints on the location of exercise. If the exercise passes those tests, the corresponding service or resource is provided in step 310.

It will be appreciated by those skilled in the art that the terminal can also act as a proxy for an email message sent over a local wireless network via the token terminal, and similarly the terminal can add its identifier as the mobile device's location and forward the message securely to the token service.

In step 408, the token terminal redirects the mobile device's web request to a URI that once again references the token service, but now adding data in the query part of the URI to authenticate the location of the mobile device. The added data consists of a nonce (a fresh random value) encrypted with a key shared between the token terminal and the token service, the Exclusive-Or of that nonce and the current date and time again encrypted with the same key, and the identifier of the token terminal. In step 410, the token service decrypts the two encrypted values using the key shared with the token terminal identified in the URI, and verifies that the Exclusive-Or of the two decrypted values is the current date and time within a suitable tolerance. If the location is thus verified, the token service checks that the token is being exercised in accordance with its terms of use, including any constraints on the location of exercise. If the exercise passes those tests, the corresponding service or resource is provided in step 412.

It will be appreciated that all of the aforementioned technologies used for exercising a token -Bluetooth, Wi-Fi, SMS, email etc. -and similar technologies may be provided in any combination.

In a third embodiment, the token terminal is a means of displaying or providing identifiers for the holder of the token to transcribe into their mobile device at the time of exercising the token. The identifier plays a role analogous to the strings that appear in "captchas" on web sites. Captchas provide evidence of human presence, to distinguish them from nuisance programs designed to fill out web forms. The identifiers provided at token terminals can be thought of by analogy as "locchas": they provide evidence of the location of the user.

Locchas are chosen randomly so that someone not present where the loccha is provided will find them hard to guess. Since people who are present may inform others about them, locchas are provided on a constrained basis. For example, they may be provided on unique printed tickets to individuals, for one use only over a suitable period of time.

Alternatively, they may be provided publicly on signs or displays, but change at intervals chosen to suit the owner of the space where the token terminal resides. For example, a displayed loccha may change every ten minutes or hour.

Locchas may be presented on an electronic display. Alternatively, they may be provided entirely by non-electronic means, and consist, for example, of locchas printed on tear-off pieces of paper, either for dispensing to individuals or so that staff can conveniently change a publically displayed loccha at intervals.

It will be appreciated that other forms of loccha are possible. For example, locchas may be provided on slips at the time of making a purchase. Or locchas may appear inside sweets in a bowl.

Locchas may be presented as strings of characters for transcription by the user. They may also be presented as barcodes for reading by users with camera-equipped mobile devices.

In this third embodiment, the user navigates to the token service at the token URI in their electronic business card or web bookmark while connected to any network, including the device's cellular network, or a local area wireless network. If the token service requires evidence of location, it requests a loccha. The user must enter the loccha correctly (by hand or, conveniently, by reading a barcode) in order to verify their location before they can exercise the token.

Locchas may be chosen to be globally unique among all token terminals at any given time. However, locchas will then need to be relatively long if they are to be hard to guess.

Alternatively, shorter locchas may be used in combination with a location technology.

For example, IP numbers are assigned to mobile devices on a country-wide or regional basis, and so a loccha need be unique only to a country or region if it is taken in combination with the mobile device's IP number.

Even shorter locchas may be used in combination with a location system based on the presence of short-range wireless beacons. In particular, locchas may be used in combination with the previous embodiments of this invention. For example, a loccha of just three or four digits could be displayed on a screen in a retail environment with a Wi-Fi or Bluetooth-based token terminal to provide proof of the user's location to very high precision. This is advantageous to the space owner because it requires users to visit very specific locations in the space. Space owners can also use locchas to ensure that people who might otherwise be able to access a token terminal from outside a space (due to transmission of the wireless signal beyond its walls) must instead come inside to read the loccha.

Figure 5 is a flowchart that shows the process of distributing tokens and exercising them at token terminals using locchas.

As before, at step 500 a token is stored as an http(s) URI that references the token service, in an "envelope" which is an electronic business card or web bookmark or similar sharable information entity. This is transmitted by existing widely applicable means such as SMS at step 502 to a mobile device. At step 504 the user connects (if not already connected) to any wireless access point (cellular or otherwise), and at step 506 the user navigates to the token's URI in the envelope.

In step 508, the token service responds with a request for the loccha, which the user reads from the token terminal in step 510. The token service verifies the loccha and checks that the token is being exercised in accordance with its terms of use, including any constraints on the location of exercise. If the exercise passes those tests, the corresponding service or resource is provided in step 510.

Determining the location of a mobile device by one of the aforementioned means of interacting with or via a token terminal, including means based on Bluetooth, Wi-Fi and locchas, can provide better accuracy and better availability of the location determination function than other technologies. In particular, GPS is not available indoors or even outdoors in many urban locations. When it is available, the accuracy is highly variable and it will often not be possible to determine whether the mobile device is in one place rather than an adjacent place. Similarly, location methods based on the cellular wireless infrastructure tend to be highly inaccurate. By contrast, the signal strength of Wi-Fi and Bluetooth transceivers in token terminals can be reduced to provide unambiguous location information; and unique locchas can be placed with arbitrary precision.

Claims

Claims 1. A system for transmitting, storing and exercising tokens comprising: A plurality of tokens, each associated with a set of one or more services or resources for which they can be exercised; A means to store tokens on a mobile device and to send tokens to and from a mobile device; A plurality of locations at which tokens may be exercised, via mobile devices that store the tokens; A means to determine at which location a token is exercised from a mobile device; Terms of use for tokens, include possible requirements that the mobile device exercising a token be physically present at one of a specified set of locations; Data storage means for storing and retrieving specifications of the services or resources associated with tokens, the terms of use for tokens, and records of token exercises; A means for verifying that a token is exercised in accordance with the terms of use, and a means for providing the associated services or resources.
2. A system as claimed in Claim 1, including a plurality of terminals whose presence defines the locations at which tokens may be exercised.
3. A system as claimed in Claim 1, in which tokens are stored in electronic business cards and transmitted to and from mobile devices in electronic business cards.
4. A system as claimed in Claim 1, in which tokens are stored in web bookmarks and transmitted to and from mobile devices in web bookmarks.
5. A system as claimed in Claim 1, in which tokens are stored in email messages and transmitted to and from mobile devices in email messages.
6. A system as claimed in Claim 2, in which tokens are exercised by transmitting them from a mobile device to a terminal over a short-range wireless network.
7. A system as claimed in Claim 6, in which the short-range wireless network is Bluetooth.
8. A system as claimed in Claim 6, in which the short-range wireless network is TEEE 802.11 (Wi-Fi).
9. A system as claimed in Claim 6, in which the short-range wireless network is IrDA.
10. A system as claimed in Claim 6, in which the short-range wireless network is Near-Field Communication.
11. A system as claimed in Claim 6, in which the location of a mobile device that sends the token to a terminal over a short-range wireless network is taken to be the location of the terminal, and the terms of use of the token applied accordingly.
12. A system as claimed in Claim 11, in which the token is transmitted to the terminal in an electronic business card.
13. A system as claimed in Claim 11, in which the token is transmitted to the terminal in a web bookmark.
14. A system as claimed in Claim 11, in which the token is included in a URT and transmitted to the terminal over the terminal's wireless network by accessing the associated web resource from the mobile device that stores the token.
15. A system as claimed in Claim 11, in which the token is included in an email message stored on the mobile device and transmitted to the terminal over the terminal's wireless network by sending or replying to the email message.
16. A system as claimed in Claim 11, in which the terminal acts as a proxy to forward the token exercise request, together with location information, to a service that processes the attempted exercise.
17. A system as claimed in Claim 14, in which the terminal redirects the mobile device to a URI of a service that processes the attempted exercise, including in that URT data that authenticates the location of the mobile device.
18. A system as claimed in Claim 2, in which the terminal provides a time-limited identifier that identifies the terminal during the time for which it is provided, and which is chosen at random so that the probability of guessing it correctly is less than a required value.
19. A system as claimed in Claim 18, in which the token is included in a URI and the token is exercised by accessing the associated web resource on the mobile device that stores the token.
20. A system as claimed in Claim 18, in which the token is included in an email message and the token is exercised by sending or replying to that message from the mobile device that stores the token.
21. A system as claimed in Claim 18, in which the token is included in an SMS message and the token is exercised by sending or replying to that message from the mobile device that stores the token.
22. A system as claimed in Claim 18, in which the exercise of the token is subject to receipt of the time-limited identifier provided by the terminal and evaluation of the implied location with respect to the terms of the token's use.
23. A system as claimed in Claim 18, in which the method of display is an electronic screen.
24. A system as claimed in Claim 18, in which the identifier is displayed on a printed artefact.
25. A system as claimed in Claim 18, in which the identifier is displayed in alphanumeric characters.
26. A system as claimed in Claim 18, in which the identifier is displayed as a machine-readable symbol such as a barcode.
27. A system as claimed in Claim 24, in which the artefact is provided directly to individuals.
28. A system as described in Claim 18, in which the identifiers are chosen so that they are unique only within an area or region identified by a second location technology, and can therefore be shorter than global identifiers.
29. A system as described in Claim 28, in which the second location technology is based on the IP address of the device exercising the token.
30. A system as described in Claim 28, in which the second location technology is based on the presence of short-range wireless sources such as Bluetooth or IEEE 802.11.
31. A terminal that comprises processing means, storage means, display means and wireless communication means for the exercise of tokens at the location of the terminal.
32. An apparatus for the temporary and local provision of random identifiers by printed or displayed means, wherein the probability of an absent agent or party guessing such an identifier during its provision and within a given number of attempts is below a given value.
33. A system for supplying tokens, wherein the tokens are for exercise at one or more specific locations, and for validating the tokens with respect to their terms of use, on presentation of the tokens for exercise.