GB2403579A - System for rapid and secure processing of mobile-tokens - Google Patents

Abstract

The invention discloses a financial Token processing system comprising: a Token issuing and authentication Server, and a wireless User-Terminal, and a corresponding Token-User account on The Token-Server, a wireless-Point-of-Transaction-Terminal and a corresponding Token-Redeemer account on The Token -Server and Token-Issuer accounts on the Token-Server wherein, Tokens representing a financial or quasi-financial value are issued from Token Issuer accounts to Token-User accounts by the Token-Server and Tokens are redeemed by the wireless-User-Terminal sending a request message to the Token-Server which Authenticates the Token request and sends an Authorisation request to wireless Point-of-Transaction-Terminal where it is presented via a Human-Machine Interface and Authorisation responses collected via this Human-Machine Interface are communicated back to the Token-Server.

Description

System for rapid and secure processing of mobile- Tokens.

Background

A mobile phone is a secure persona] electronic device and this creates an opportunity to use a mobile phone as a tool to initiate and authenticate financial or quasi-financial transactions. A mobile phone could be used as a tool for making payments, presenting tickets, vouchers, discomt coupons, receipts and so on.

There has, for example, been interest in the potential use of mobile discount coupons. In a typical conventional mobile discount coupon application, a consumer is sent; an SMS message containing a reference code which entitles the bearer to a discount or free product or some other offer. At the point of sale, the retail Assistant types this into a terminal which communicates with a central server and thus, or otherwise, veriLles that the discount-coupon is valid.

Despite the attractions to producers and retailers of mobile coupons in there are two significant practice] problems: Preventing fraudulent, duplication of coupons and Minimising the amount of time taken by the Retail Assistant to redeem the coupon at the Point of Sale.

There have been many attempts to produce improved coupon systems (see e.g. GB 2,372,367: GB 2,362,979: GB 2,'361,570: EP 1,178,42]: EP],150,228: WO 0]/93120: US 2002/00657]3: Jf'2002-109353).

These tend to fall into the following categories of approaches: (a) Send the coupon to the mobile phone in the form of a bar-code. The retailer then scans this in like a paper bar code.

(b) Avoid using the mobile phone at the point of sale at all. Instead connect the POS to a central server. Each time a consumer makes a 1.

purchase, use some sort of personal identifier (e.g. credit card number) to query the central database to see if they have any valid coupons.

All these various approaches have significant practical problems c hiefly: À While sending a coupon as a bar-code, makes it easier to enter the data into the Point; of-Sale terminal, it does not prevent the bar-code being fraudulently duplicated. Also not; all phones are capable of receiving bar-code images.

Moreover even when phones can receive these images it, is difficult for an optical bar-code reader l,o reliably read the image from the screen of the phone.

10. Connecting the Point-of-Sale terminal up to a central validation server makes the coupon secure, but has a major impact on the design of point of sale terminals and on the central validation server.

An object of the present invention is to make il. possible to redeem mobile-Tokens such as mobile discoZmt coupons, tickets, vouchers, payments etc in a manner which enables high volumes of traffic to be processed at retail point-of-sale terminals and maintains high levels of security but without having to make substantial modifications to the installed point-of-sale equipment or to the back office systems to which they are connected.

Summary of the Invention

The Invention provides a system which enables high volumes of mobileToken to be processed rapidly and securely at point-of-sale or point-of transaction terminals.

Tokens are processed in two stages: firstly they are issued, secondly they are redeemed.

In the first stage a mobile Token e.g. a mobile-discount-coupon is issued to the mobile phone. When a Token is issued the consumer's online account is updated with the Token details and optionally an SMS message containing details of the Token is sent; to the consumer's Mobile Terminal.

2, . . To redeem the Token, the mobile phone associated with the Token sends an authorization request message to the central Token server. This authorization request, contains: an identifier of the mobile phone sending the request, 5. an identifier of' the Token to be redeemed and an identifier of the POS terminal.

The central Token server then sends a message to a "Token Terminal " device associated with the ret,ailer's point of-sale terminal. This Token Termina] then converts the code to a bar code. In other words the Token terminal is in effect acting as an instant bar-code printer.

This bar code can then be scanned using the normal POS bar code reader in exactly the same way that a bar code printed on a paper would be. If the POS terminal accepts the Token, then the Token is accepted on the Token Terminal e.g. by clicking on an OK button. The Token Terminal notifies the (Central Token Server which then accepts and cancels the Token for further use.

If there is more than one Token in the consumer's account, the Token terminal presents a series of Token and each may in turn be scanned in.

This same technique applies equally to other forms of Financial Tokens such as Tickets, Receipts, Credit Card numbers, vouchers etc. The invention also integrates a payment capability with the capability to redeem coupons. When a consumer opts to pay from and account associated with their mobile phone, then the value of' any discount coupons are automatically deducted from the bill and the balance of the amount is charged to the consumer account.

This approach has major benefits: 25. Tt is perfectly compatible with retailers existing equipment, and practices for redeeming Tokens. Tt does not require modifications to either IT systems or business processes.

Tt enable high volumes of traffic to be processed It is secure It, is perfectly compatible with basic mobile telephones. Consumers do not have to have "special" or advanced mobile phones with special capabilities.

Details of the Invention The Invention will now be further described with the aid of the following diagrams: Referring to Figure 1.

(10) is a Token Server that issues mobile Tokens and validates previously issued Tokens. It contains accounts for Token-Issuers (1]), consumers (12) and Token- Redoemers (13). It is connected to the mobile network via various media gateways, including but not limited to: a Voice gateway (17), an SMS gateway (19), and a Wap gateway (18).

(20) is a mobile terminal capable of some or all of the following, making voice calls, vending and receiving Short Messages, and accessing wap or web pages.

(30) is a wireless communication network capable of supporting some or all of the following: switched voice calls, packet data, and SMS messages.

(35) is a wireless or fixed communication network capable of supporting some or all of: circuit switched voice calls, SMS messages and packet data.

(do) is a Retail Point-of-Sale or Point-Of-Transaction or Point-of-Entry terminal where e.g. goods are paid for, transactions arc conducted, or consumers admil,l,ed 2() to locations.

(45) is a data cable which connects a bar-code reader to a Point-of-Sale l;erminal.

A data cable can also be used to connect a Token 'I'erminal (60)to a Point-of-Sale terminal (40).

(50) is an optical bar-code reader.

(60) is a Token Terminal. There is typically one Token Terminal associated with each individual Point-of-Sale terminal in a Store. For the purpose of this description, a "Store" is a group of Token Terminals.

The Invention provides a system for Issuing and redeeming mobile-Tokens.

Mobile 'l'okens, as defined for the purpose of this description, can be used in a multifarious different applications and issued in several different ways. These Tokens may be used for the purposes of providing e. g. mobile-discolmt coupons, 6 mobile-vouchers, mobile-receipts, mobile-t,ickets, mobile-payments and so on. For example, a merchant may issue a user with a Token when they buy a ticket to an event. Or, a merchant may provide a receipt when a consumer purchases goods or services. These tokens may be issued to consumers either in response to a request from a consumer or they may be unsolicited. For example a consumer may see an advert offering a discount coupon. A merchant may offer Token or vouchers each time a user visits a web-site or clicks-through on a banner ad.

For the purpose of this description, there are three parties who participate in a mobile-Token transaction: Token Issuers: These issue 'I'okens to consumers.

15. Consumer: Consumers collect and redeem Tokens.

Token-Redeemer: Redeemers accept, Tokens from consumers. They may in turn present these Tokens to the original Issuer and claim the monetary value represented by these Tokens.

The following section describes how Tokens are issued and the subsequent sections describe how they are redeemed.

In preparation for issuing mobi]c-Token the Token-Tssuer establishes a stock of mobile-Tokens in the Mobile Token-Server (10) and defines: I'he "value" of these Tokens: The value of the Token may be a a ticket l,o an event,, a money-off offer, a two-for-one type offer, a voucher entitling the bearer to a product or service, a credit card details etc. The rules for issuing Tokens e.g. a consumer may not be allocated more than say three discount COllpOIlS from a given Issuer (11) within a given period, or other similar rules.

The address that consumers contact to claim the Token: This address uniquely defines the Issuer (] 1). The address may be either a mobile telephone number (MS-ISDN), a short code (an abbreviated telephone number) or one of these used in combination with a keyword i.e. the consumer 6 must send a message to the number specified and include the specified keyword in the message. Alternatively the address may be a web/wap URI and optionally a keyword that the user must, enter into that web/wap page.

The t,ext/content, of the message that is sent with the Token when it is issued to a consumer.

10. Which:Redeemers the Issuer permits to redeem the Token.

Once this setup has been performed, this stock of mobile-Tokens can be issued to consumers.

Redeemers also pre-est,ablish an account (13) and define information that, includes but is not limited to 15. which Issuers (1]) they will accept Tokens from or which individual Token or types of Token they will accept, their geographic location, which Token 'I'erminals (60) are present iI1 a particular store. This enables all the Token Terminals (60) in a store to be addressed as a group. etc Mobile Tokens may be issued either by the Issuer either in response to a specific request from a Mobile Terminal (20) or at some other point of the Issuer's own choice.

To request a mobile Token, the requesting mobile Terminal (20) sends an Issue request message to the Token Server (l 0). This Issue request, message can be sent via one of several different media described below.

This Issue request message explicitly or implicitly contains and identifier of the requester and thus the consumer account (12) to which the mobile-Token should be allocated. It also contains an explicit or implicit identifier of the Issuer i.e. the Issuer account (11) from which the mobile-Token should be debited.

When the Token Server receives an Issue request message, it checks that all the conditions and rules for allocating this Token to this consumer (12) are fulfilled and either issues the Token or rejecl,s the request.

The Token Server (l 0) allocates the Token to the consumer account (] 2) and debits the account of the Token-Tssucr (11).

Mobile Tokens are issued in embodiments which include, but are not limited to, the following: A publication features a response mobile telephone number, either a full MS- ISDN or a short code, and optionally a keyword. This mobile telephone number together with any keyword together uniquely identify a specific Token Issuer Account (1]).

SMS Messages sent to this number or voice calls made to this number are routed to and terminated on the 'l'oken Server (10) via the respective gateway (17, 19).

The 'l'oken Server (l 0) extracts the identity, i.e. the MS-ISDN of the sender from the originating address of the SMS message /the calling line identifier of the voice caller. It also extracts the number to which the message had been sent and any keyword, since this defines who had issued the Token and therefore the corresponding Issuer Account (11). The Token Server (10) checks that the rules and conditions for issuing this Token are fulfilled and if so credits the Token to the consumer-account (12) and debits the Issuer Account (13). The Token Server (] 0) then optionally sends a confirmation SMS message to the requesting Mobile Terminal (20). This SMS message is what the consumer will perceive as the Token though the Token is in fact stored in the consumer account (12) on the Token Server (]0). This confirmation message can include a unique personalized Token Code. In another embodiment, the confirmation SMS message may be transmitted with an Originating Address corresponds to a different individual Token. T.e. each different Token sent l,o that particular Mobile Terminal (20) is transmitted with a different Originating Address. This use of a different Originating Addresses for each different Token in some circumstances simplifies the process of authorising an individual Token.

In another embodiment, the publication features the URL of a wap or web page (18) linked to the Token Server (10) and opl,ional]y a keyword. '['his URL or URL/keyword combination uniquely defines a specific Issuer account (11). When this URL is accessed and any necessary keyword is entered, the Token Server (10) identifies the consumer account (12) and the Issuer account (l 1). The consumer identity may either be passed to the wap gateway (18) from the mobile network, or a cookie is been pre-stored in the wap/web browser. 'l'he Token Server (IO) then checks that the conditions for issuing the Token are fulfilled and if so credits the consumer' account (12) and debits the corresponding Issuer account (]. I).

In another embodiment, an online publication e.g. a web or wap pages, feature a hyperlinked URL which links to the web/wap server (18). When the hyperlink is accessed, this causes an Issue request message to be sent to the Token Server.

This request includes at least the identity of the Token issuer (11). If no identifier of the consumer account (12) is included in the original request, then the Token Server (10) prompts the Mobile Terminal (20) to enter the data. When the Token Server (10) has collected the identity of both the consumer account (12) and the issuer account (11), the consumer account (12) is credited and the Issuer account (I]) is debited.

The following sections describe how the Invention redeems mobile-Token. Mobile Tokens may be redeemed in response to either requests from a Mobile Terminal (20) or from a Token Terminal (60).

To make an authorization request from a Mobile Terminal (20) the Mobile Terminal (20) sends a Token authorization request message to the 'I'oken Server (10). This request message explicitly or implicitly contains at least: À the identity of the Mobile Terminal (20) and An Identifier which corresponds to a Redeemers Accounts (13).

It can also contain: 30. information which identifies one specific Token, and information which identifies a specific Token Terminal (fig), and information which identifies a specific store, i.e. a group of Token Terminals (60).

The Invention has several features which, when employed, simplify the process of redeeming a Token. These features eliminate the need to explicitly include: an individual Token Terminal (60) identifier or À a Store identifier.

in the authorization request message.

To avoid the need to include an identifier for an individual Token Terminal (60) ] 0 the 'I'oken Server (l 0) sends the authorisal,ion data to all Token Terminals (fit)) in that particular store. Thus each of the Token Terminals (60) in a store will then contain duplicates of the same Tokens for an individual consumer (12). Thus whichever actual Token Terminal (60) the consumer actually uses, the Token data is available. On an individual Token Terminal (60) the Tokens l5 corresponding to a particular consumer account (] 2) may be identified by any personal identification data stored in the consumer account (12) and transmitted to the Token Terminal (60) for that purpose. Possible identifiers include but are not limited to: the MSISDN of the Mobile Terminal (20), a credit card number, a loyalty card number etc. In the preferred embodiment, the Token Terminal (60) includes a magnetic card / chip card reader c apability. By inserting a card containing any of these pre- registered data, the Token Terminal (60) matches the set of Tokens which corresponds to this personal Identifier. In another embodiment, the Token Terminal (60) does not have a magnetic card/chip card reader capability and the list of Token or set of Tokens available is presented on the display and may be selected via the user interface.

This feature is valuable because it saves the user the trouble of having to address a message to a specific Token Terminal (60) which will often be an unfamiliar reference number and permil,s them instead to address the message to something more understandable and familiar e.g. the normal name of the store. 9.

In order to avoid the need to include a Store identifier in the authorization request message, the Invention exploits the location positioning capabilities of the mobile network (30). When the Token Server (10) receives a authorization request that, does not include a Token Terminal (6()) or Store identifier, it queries the Mobile Network (3()) for the current geographic position of the Mobile Terminal (20). When the Mobile Network (30) supplies this information, l,he Token Server (10) uses this to look up a list, of pre-registered geographic co ordinates for specific Redeemers (l 3). If there is a match, the Token Server (10) uses this as the Store identifier sends the Authorisation request response message to all the Token Terminals (60) iI1 that store. If there is no match an error condition is created.

In another embodiment, each store has a unique mobile telephone number that the mobile rI'erminal (20) may ring or text.

The authorization request message may be sent via media which include, but are 16 not limited to the I'ollowing: Voice telephone call, SMS, WAP/web.

To initiate a Token authorization request by Voice call the Mobile Terminal (20) calls either: A telephone number specific lo an individual Token Terminal (6()). Calls to this number are terminated directly on the Voice gateway (17) or can be diverted to the Voice Gateway (17). The Token Server detects that there is an incoming call on a line which has been pre-defined to correspond to an individual Token Terminal and also uses the Calling Line Identifier to detect the identity of mobile phone that, is calling. The Token Server (10) does not need to answer the call, since al] this information can be gathered before it actually answers the call. By not answering the call the caller is spared the expense of paying for the call. The Token Server waits for a specified number of rings before answering the call. If the caller hangs up before the cat] is answered, the Token Server (10) sends data for all Tokens relevant to that consumer Account (12) in that store, to the Token Termina] (60). Tf the user holds until the call is answered, the Voice Gateway (17) prompts the caller to enter a reference number for a specific Token or Tokens. 'l'he Token Server (l0) then vends the data for this individual Token or Tokens to the Token Terminal (60).

A telephone number specific to a particular store (group of Token Terminals (60). The Voice Gateway (17) waits a specified number of rings before answering the call. Tf the caller hangs up before the call is answered, then the Token Server sends Token data for al] Tokens which are relevant for that l0 Consumer Account (12) in that store. The rl'oken data is sent to all Token rl'erminals (60) in that store. Tf the caller holds until l, he call is answered, then the Voice Gateway (17) prompts the caller to enter l;he name or reference number for a specific Point-of-Sale / Token l;erminal (60) and specific Token.

If no specific Token Terminal (60) identifier is entered then the Token data is delivered to all Token Terminals in the Store. If no specific Token identifier is enl,ered then Token data for all Tokens that are potentially relevant for that Consumer Account (12) in that store.

A telephone number previously used as an Originating Address in a Token sent, l,o that MT (20) in a SMS message. The Token Server (10) treat calls to this number as a request to authenticate this specific Token. The Token Server (1()) then instructs the voice gateway (17) to prompt, the user to enter the name or reference number for the store / Point-of- Sale terminal. The Token Server (] 0) then authenticates and accepts or rejects the request and sends a response to the Tokenrl'erminal (60).

25. A telephone number which serves multiple stores associated with a particular Redeemer Account (13). In this case the Token Server (10) either instructs the voice gateway (17) to prompt the user to enter the store name / reference code, or uses the location positioning capabilities of the Mobile Network (30) to determine which store l,he Mobile Terminal (20) is located in.

To initiate a Token authorization request by SMS the Mobile Terminal (20) either: Originates a new SMS to a destination address specific to an individual Token Terminal (60). If this message does not contain an identifier for a specific Token, then the Token data for all Tokens relevant for that Consumer Account (12) in that store are sent to the Token Terminals (60). If the message does contain an identifier for a specific Token then the Token data for that Token is sent to that specific Token Terminal (60).

À Originates a new SMS to a destination address specific to a specific store. If this message does not contain an identifier for a specific 'l'oken Terminal (60) or a specific 'l'oken, then the Token for all Tokens relevant for that Consumer Account (12) in that store are sent to all Token Terminals (60) in the store. If lO the message does contain an identifier for a specific Token Terminal (60) and a specific Token then the Token data for that. rI'oken is sent to that specific Token Terminal À Replies to an address previously used as an Originating Address in a Token sent to that MT (20) in a SMS message. The Token Server (10) treats messages to this number as a request to authenticate this specific Token. If the SMS message does not contain the reference code for a store or specific Token terminal, then the SMS (gateway (19) prompts the Mobile Terminal (20) with an SMS message to enter the reference code for the store or Token Terminal. When the Mobile Terminal (20) replies with this information, the Token Server (10) then authenticates and accepts or rejects the request, and sends a response l,o the Token Terminal (60) or all Token Terminals (60) in the store.

Originates a new SMS to an address which serves multiple stores and include the name / reference code of the Redeemer (13) in the body of the SMS. If' the 26 SMS message does not contain this identifier, then the SMS gateway prompts the Mobile Terminal (20) with an SMS message to supply this information.

When this information becomes available, the Token Server (l 0) then authenticates and accepl,s or rejects the request and sends a response to the Token Terminal (fi0) or all Token Terminals (60) in the store.

To initiate a Token authorization request by wap or web the Mobile Terminal (20) accesses the URL, associated with the Issuer account (I]) and any necessary keyword is entered. The Mobile Terminal (2()) is identified either by the MS ISDN passed from the mobile network (30), from a cookie stored in the browser in the Mobile Terminal (20) or it is prompted to log in with a username and password. The Mobile Terminal (20) is then prompl,ed to supply the identifier of a particular Token and Token Terminal (60) or store. The Mobile Terminal (10) then makes an authorization request for individual or groups of Tokens. Token 6 Server (10) then authenticates and accepts or rejects the request and sends a response to the Token Terminal (60) or all Token Terminals (60) in the store.

Token authorization requests may also be initiated from a Token Terminal (60) as well as from the Mobile Terminal (20). To make an authorization request from a Token Terminal (60), an identifier for the corresponding to a consumer account (12) is entered into the Token Terminal. This idenl,ifier can be either: Any pre-registered personal identifier e.g. credit card number, loyalty card number, The MS-TSDN of the Mobile Terminal (20) or any other personal idenl,ification data that has been pre-registered with the Token Server (10) 15. A unique personalized token code sent in a SMS token message This identification data may be entered manually or swiped in from an attached magnetic/chip card reader. In the prcf'erred embodiment, the Token Terminal (60) includes a magnetic card / chip card reader capability. When a card containing any of these pre-registered data is swiped (read), the Token Terminal (60) passes this data to the 'l'oken Server (10) which retrieves the set of Tokens, if any, which corresponds to this personal Identifier and treats this message as a Token aul;horisation request message.

When the Token Server (10) receives a Token authorisal,ion request, i, checks its 26 records to confirm whether or not this Token has previously been authorised and cancelled and if all of' any other terms and conditions applying to this Token are valid. The Token Server (10) either aul, horises or rejecl;s the Token authorisal,ion request and communicates this in a response message back l,o the Token Terminal (60). This authorization response message contains data which includes but is not limited l,o: 1c À binary indication of whether or not the request was accepted or rejected An authorization code which is unique to this particular transaction A reference number or code for the Token which has been authorised Additional informational data about the Token which has been authorised, e.g. the Terms and Conditions of the Token e.g. "This Ticket admits One person to the Concert" or "This coupon entitles the bearer to $6.00 off any hardback book". etc In some embodiments, not al] these data elements are present.

In the preferred embodiment, the Token 'I'erminal (60) formats the reference number or code for the Token which has been authorised as an optically readable bar code i.e. the Token Terminal (60) acts in effect as an "instant bar-code printer". This bar-code can then be scanned into the POS terminal (40) using a conventional bar-code reader (50). In another embodiment, the Token Terminal (60) displays this as numerical / alphanumerical data ] 5 If there is more that one Token in the stream of information sent to the Token Terminal (60) then this is displayed as a series of bar-codes. The user interface of the Token Terminal (60) enables each Token to be selected in turn.

When a Token is accepted by the Redeemer, this is indicated on the user interface ol the Token Terminal (60) e.g. by clicking a button etc. The Token Terminal (60) then notifies the Token Server (1()) that the Token has been accepted and the Token Server (10) records this fact and prevents that Token from being used again. If the Redeemer accepts the Token, they then they permit the consumer to do the item indicated by the Token e.g. deduct the value of the rl'oken, redeem the voucher, permit the consumer access to an event etc. In anol;her embodiment the Token Terminal (60) is physically connected to or integrated with the Point-of- Sale terminal, e.g. 'of" cabled into the same socket as the bar-code reader. In this embodiment, when the Token Terminal (6()) receives dal;a from the Token Server (10) it enters the some or all of l;he data received direcl,ly into the Point-of:Sale terminal (40) via an interface without any need for a Retail Assistant to manually scan the Token Terminal ( 60) with the Bar code 14.

reader (40).

In another embodiment of the invention, the Mobile Terminal (20) initiates a Token authorization session with the Token Server (l O) and identifies the Token Terminal (60) or store. The 'I'oken Server (10) thencommunicates directly with the POS terminal (40) or indirectly with an attached POS controller system which controls multiple POS terminals (40). The Token Server (10) informs the POS (40) or its controlling system which Tokens are held on behalf of that Mobile Terminal (20) and which may be valid for the Redeemer that owns/operates the POS terminals (40). The POS terminal (40) or the attached controlling system, then informs the Token Server (10) which of these Tokens, if any, it; accepts. The Token Server then records that these Tokens have been accepted and cancels them from future use. The POS terminal may then indicate that the Tokens have been accepted and record this fact for it records.

The invention provides a payment capability whereby the value of any valid mobile discount-coupons is deducted from the bill and the balance is charged to the Consumer Account, (12). To make a payment in this form, the Mobile I'erminal (20) sends an authorisat;ion request message to the Token Server (10) that contains (as well as identifiers previously mentioned for the Tokens to he redeemed and the Token Terminal (60) where it should be redeemed), the amomt payable and, À a signature (a PIN number or password, or voice print).

The Token Server (10) deduces from the presence of the amount payable and signature fields that this is a request to make a payment, not just to redeem Tokens. The Token Server (10) then, as previously described, has a dialogue with the Token Terminal (60) to authorise and accept or reject individual discount coupons. At the end of this process the 'I'oken Terminal deducts the value of any Tokens accepted from the original amount, payable and charges the balance to the consumer account (12). The consumer Account (12) can have either a positive cash balance (i.e. a prepaid account) from which this amount is deducted or it may have a negative cash balance (i.e. a credit account) and the value of the purchase added to this balance subject to this being within the consumer account's credit limit.

In another embodiment, of the Invention, the Token Terminal (60) is utilised as a 6 payment card authorization terminal.

The payment card is swiped as normal and the authorization message is sent to the Token Server. The Token server then sends a signature request to the Mobile Terminal (20) by SMS, voice or WAP push. The consumer then signs this message using a PIN number and replies to the Token Server (10) .

In another embodiment, the consumer sends an authorization message to the Token Sever (10) containing the amount payable and their PIN number, but not containing an Identifier of either the Token Terminal (60) or Store. This message may be sent using Voice, SMS or wap. An identifier associated with the Consumer Account (12) is then entered into the Token Terminal (fig) and delivered to the rl'oken Server (10). This data may be manually typed in or swiped in from a magnetic/chip card. The Token Server (10) then matches the request coming from the Token Terminal (60) with the Request; coming from the Mobile Termina] (20). i.e. the consumer did not have to enter a reference number or code for the retailer who they are paying in this transaction.

The 'loosen Server (10) then sends an authorization message to the Token Terminal (60) and sends a Token which acts as a "Receipt" to the Mobile Terminal (20). It the consumer replies to this Receipt, message with their e-mail address this causes the Token Server (10) to transmit details of this lleceipt, to that e-mail address. The Invention thereby provides a "paperless" purchasing system.

This Invention has several major advantages: It corresponds closely to the way paper Tokens are handled. Thus there is little mental adjustment or learning for either consumer or retailer.

Moreover no change is required to the redeemer's cxist;ing Point-of-Sale equipment.

It avoids any need to manually transcribe Token codes from mobile phones to 1Gi the Point-of-Sale device. This is highly time consuming and error prone and reduces the throughput at the Point of Sale.

It avoids the need for consumer's to possess mobile phones capable of receiving bar-codes.

5. The redeemer sees the 'token dal,a on their own device (60) rather than the consumer's device (20) and thus has a much higher level of trust.

It avoids the need to physically, collect, count and remit paper Token.

It provides a convenient method of payment which automatically saves the consumer money by automatically deducting the value of coupons redeemed.

Claims Claims will be supplied at, a later date.

Claims (1)

1. Claims 1) A financial Token processing system comprising: a Token issuing

   and authentication Server, and a wireless User-Terminal, and a corresponding Token-User account on the Token-Server a wireless-Point-of-Transaction Terminal and a corresponding Tokcn-Redeemer account on the Token Scrver and Token-Issuer accounts on the Token-Server wherein, Tokens representing a financial or quasi-financial value are issued from Token Issuer accounts to Token-User accounts by the Token-Server and Tokens are lO redeemed by the wireless-User-Terminal sending a request message to the Token-Server which Authenticates the Token request and sends an Authorisation request to wireless Point-of-Transaction-Terminal where it is presented via a Human-Machine Interface and Authorisation responses collected via this Human-Machine Interface are communicated back to the Token-Server.

   2) A system as in Claim I where the Token-Server contains accounts corresponding to Token-Users, Token-Issuers and Token-Redeemers. In the preferred embodiment there is one-one correspondence between Token-User accounts and wireless-User-Terminals. In another embodiment there is a one-many correspondence between the Token-User account and wireless UserTerminals.

   3) A system as in Claims 1 to 2 where Tokens are transferred from TokenIssuer accounts to Token-User accounts in response to request messages sent from an associated wireless-User-Terminal 4) A system as in Claims I to 3. where unsolicited Tokens are added to the Token-User accounts 5) A system as in Claims 1 to 4 where the Token-Server maintains a database and a set of rules relating to which Tokens and how many Tokens may be issued to Token-Users either in response to requests from wireless- User Terminals or unsolicited.

   6) A system as in Claims 1 to 5 where the Token Server maintains a database of which Token Redeemers may redeem each individual Token held in a individual Token-User account.

   7) A system as in Claims 1 to 6 where each individual wireless Point-of Transaction-Terrninal is allocated a virtual telephone number and calls to this virtual number are delivered to the Token-Server which maintains a mapping to the actual address of the wireless Point-of-TransactionTerminal, and after processing the Token redemption request, communicates authorisation data to the wireless Point-of-Transaction-Terminal. In an alternative embodiment, a system as in Claims 1 to 6 where SMS messages addressed to the virtual telephone number are delivered to the Token Server and processed as described above. In an alternative embodiment, a system where the SMS message contains an alphanumeric keyword and the combination of the virtual telephone number and the keyword uniquely define a wireless-Point of-Transaction terminal.

   8) A system as in Claims I to 6 wherein a notification SMS is sent to the wireless-User-Terminal when a Token is issued and the SMS contains an embedded Reply-To number such that the combination of the number of the wireless-User-Terminal and the embedded Reply-To-number uniquely defines an individual Token. If a message sent to the Reply Number from the user Wireless Terminal contains an identified for a wireless Point of Transaction Terminal then and authorisation request message for only that individual token will be sent to the said wireless Point of Transaction Terminal.

   9) A system as in Claims 1 to 8 where data representing the Token and thereby representing an implicit Token authorisation request, is presented on the screen of the wireless Point of Transaction Terminal in a optical bar-code format and the wireless Point of Transaction Terminal has human input means presenting a human operator the means to accept or reject the coupon 10) A system as in Claims I to X where data representing the Token is communicated via a serial port on the wireless Point-of-TransactionTerminal 3 0 to the bar-code/keyboard input port of a PC or Point-of-Sale terminal.

   11) A system as in Claims I to 10 where in a single request from wireless User Terminal to an individual wireless Point of Transaction Terminal is treated as a request to process all Tokens in the corresponding Token User account - q which are permitted to be redeemed by the Token Redeemer corresponding to the individual wireless Point of Transaction Terminal.

   12) A system as in claims 1 to 11 where Token issue request messages from the wireless-User-Terminal to the Token-Server are via the following media: Dialled digits/Voice call, dedicated SMS number, shared SMS number with a keyword, Wap or HTML.

   13)A system as in Claims I to 12 where Token authorization request and response messages are communicated between the wireless User Terminal and the wireless-Point-of-Transaction-Terminal are via the following media: wireline circuit or packet data or wireless data including SMS, GSM circuit switched data, GPRS packet data, WCDMA, cdmal cdma IX or any other I wireless bearer channel.

   ]4) A system as in Claims 1 to 13 where a Token redemption request message from the wireless-User-Terminal contains, explicitly or implicitly, an identifier of the wireless-User-Terminal, the wireless Point-of-Transaction Terminal and the Token-Server uses these data to deduce which Tokens may be redeemed at t 15) A system as in Claims 1 to 14 where the Token redemption request also contains a request to make a payment to the wireless-Point-of-Transaction Terminal i.e. a payment to the organization pre-registered to the Token Redeemer Account for that wireless-Point-of-Transaction-Terminal.

   According to the media used for the request, as identified in Claim 12, the I payment request is expressed in a form that is obvious to those familiar with the art. In the preferred embodiment payments request are via dialling the Telephone number associated with the wireless Point-ofTransaction Terminal being rung and entering the amount payable and a PIN code entered. In an alternative embodiment, the data is communicated using SMS.

   In a further alternative the data is communicated via Wap.

   16) A system as in Claim 15 where there is a Credit or Debit account, associated: with the Token-User account and where the value of any authorised discount coupons are deducted from the total amount due and the balance of the funds are charged to the Credit/Debit account. The Token Server sends a payment authorization request to the Credit/Debit account provider on behalf of the Ed Token Redeemer. When the payment authorization response message is received back from the Credit/Debit account, the Token-Server communicates the result to the wireless-Pointof-Transaction-Terminal.