GB2396520A - System for issuing and authenticating mobile tokens - Google Patents

System for issuing and authenticating mobile tokens Download PDF

Info

Publication number
GB2396520A
GB2396520A GB0227358A GB0227358A GB2396520A GB 2396520 A GB2396520 A GB 2396520A GB 0227358 A GB0227358 A GB 0227358A GB 0227358 A GB0227358 A GB 0227358A GB 2396520 A GB2396520 A GB 2396520A
Authority
GB
United Kingdom
Prior art keywords
message
mobile
token
sms
coupon
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
GB0227358A
Other versions
GB0227358D0 (en
Inventor
Robert Joseph Gerard Macnamee
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
LIQUID DROP Ltd
Original Assignee
LIQUID DROP Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by LIQUID DROP Ltd filed Critical LIQUID DROP Ltd
Priority to GB0227358A priority Critical patent/GB2396520A/en
Publication of GB0227358D0 publication Critical patent/GB0227358D0/en
Publication of GB2396520A publication Critical patent/GB2396520A/en
Withdrawn legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/325Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks
    • G06Q20/3255Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks using mobile network messaging services for payment, e.g. SMS
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/326Payment applications installed on the mobile devices
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322Aspects of commerce using mobile devices [M-devices]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/363Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes with the personal data of a user
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/387Payment using discounts or coupons
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/02Marketing; Price estimation or determination; Fundraising
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F7/00Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/0866Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means by active credit-cards adapted therefor

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • General Business, Economics & Management (AREA)
  • Finance (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Development Economics (AREA)
  • Computer Security & Cryptography (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Game Theory and Decision Science (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Cash Registers Or Receiving Machines (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

A representation of a finacial token, e.g. a discount coupon is delivered to a mobile station in an SMS/MMS message. The SMS/MMS message contains an embeded source address and the source address is selected so that the combination of the mobile's number (the destination address) and the source address uniquely identify an individual financial token. To authenticate and redeem the financial token, the mobile station sends an SMS/MMS/voice message back to the source address which links to the Token Issuing and Authentication server. The server checks if the financial token is valid and if so sends a SMS/MMS message back to the mobile phone.

Description

Patent Specification
System for issuing and authenticating mobile-tokens.
Background
Making a call OI1 a mobile phone is in fact also making a tinancal tra. Iusacton, where the item purchased Is the telephone call itself. Mobile phones are now secure personal electronic devices and provide an excellent basis for a variety of financial and quasl-financal insl, ruments such as discount-coupons, vouchers, and tickets.
For the purpose of this specification, these will be referred to as Tokens.
I'he first form of token Is a dscount-c,oupon. Discount c,ouporus are an extremely popular and powerful marketing tool. They have for many years been used in paper form where they are priIIted iI1 magazines, press etc and consumers take them to Retail stores to redeem them. To redeem them, the Retailer visually examines the C.OUpOI1 to satusfy herself that the COUpOI1 iS autheIll,ic and is within its validity period. If the Ret. aller IS sashed of this she retains the paper coupon and presenl,s it to its Issuer, typically a. product manufacturer to collect the monetary value of the coupon. 'lithe Retail also defaces the coupon e.g. by crossing out with a pen to prevent it bemg represented on a subsequent occasion.
With the rise of online stores and e-commerce, the concept and practice of electronic coupons was quickly est;abllshed. A common method of iSSUiIlg online coupons Is to Issue visitors to a web site, a reference code. When consumers buy something from this or an affiliated web-ste, they type this reference code into a field m the web
sites payment page. The web-site then -leducts the value of the coupon from the purchase. Note that there is an mporl.ant difference in the way that "offline" and "online" coul.,orls are authenticated. There are two general approaches to authenticating any kind of token: (a) Ically
(b) (centrally.
Offline, e.g. paper based coupons are typically authenticated "bank note style" Ye.
locally by printing the coupon on a type of paper, with certain limts and inks that cannot easily be copied by would be fraudsters. The quality of the design and prmtmg efforts proportional to the value of the coupon. Obviously the effort pul, mto the production of a ú6() bank note is substantially greater than that put into a 60p off coupon but, the principle Is exacl,ly the same.
Onlme e.g. web based COUpOIlS are authenticate.cl (centrally by referring back to the sysl,em which generated them in the first place.
I'he concept, of mobile coupons has been arotmd for roughly as long as web-based coupons. 'lhere has been a lol, of talk about the "concept" of mobile coupons but a lol, less attention l;o the pracl,ical details which will create a practical service. The concept Is similar to web based COupOIIS, the consumer is sent, a reference number In a mobile message. 'lathe consumer may then redeem this coupon either at an online web-site, exactly hke any other web-based coupon or may redeem it a physical store.
Ilowever rodeemmg a mobile coupon at a physical store is quite different and much more difficult than recieemmg it via a web-ste. 'I'here are several differences and difficulties arlsng from the fact, that Retail stores are typically offline rather than online environments. Mobile coupons are a kmd of hybrid between the online world and the offline worldly Ilms Important to reahse that one could authenticate coupons m many ways If one had the freedom to Install new functonalil,y In either l, he mobile or at the Point-of S.lle. It Is an entirely different challenge to authent,cate a C'OUpOI1 in a mobile phone which contains special software and authenticate a coupon in a perfectly standard (ASH, SMS capable phone. For example If there was a standarclisecl widely used method for leletulg used coupons from a mobile phone, then the challenge would be greatly simplifiecl. The Mobile Token Apphcation deals only with the case of standard phones '.e. (-'SM, SMS capable phones and this document Is concerned only with this situation.
If we consider the case of standard mobile phones only then it Is obvious that Mobile coupons cannot be authenticated locally. It is simply too easy to repror.luce the token. Even If the coupon was sent as a complex graphical Image in a picture message it would still be relatively easy to make a copy of this or to forward It to a frond. It Is not possible to, aut;hentical-e the coupon simply by viewing it on the (consumers phone s display screen since this Carl be easily manually typed m or sent from one phone to another.
Smce It cannot be authenticated locally it may only be authenticated by referrulg back t, a central server. Ilowever while it; is obvious in principle this still presents huge, practical problems. For a start il. demands a c entral authentication mrastructure which does not exist. For example credit card systems have a central authenticat;on/aut;horisatior1 infrastructure which has taken years to evolve and costs milhons of dollars to install an maintain. (treating a comparable infrastructure for mobile coupons IS a totally unrealistic lrospecl. Another fairly obvious approach would be for the coupon tx, include a contact number retailer to ring up the issuer of the coupon and ask if that coupon was vahd. However this would be such a waste of precious retail staff time that it would be totally unworkable in practice.
Ever1 If it is obvIous, that one should contact the issuer of a coupon it. Is by no means clear that the lLetarl staff member who has to redeem the coupon will in practice know W}10 the Issuer is or how to c.olltact them. rlhe Retail staff member may not know if the coupon was Issued by the Retailer themselves or by a third party manufacturer Lf this comport was issued by the retailer himself the retailer may then check in his records If the coupon Is valid and whether or not it has been already been presented. If the coupon was issued by a product manufacturer rather than the Retailer then the Retailer must c onsult the Issuers records.
I he specific difficulties with a system for c entrally authorisng mobile coupons are: À Retail F'oS systems does riot typically have a manual method for entering coupon oxides Into the F'oS equipment.
À There Is no easy widespread method of c.ommurlicatrng between a mobile phone
and a Point of Sale terminal.
The lletal] I'oS system does not have an automatic mechamsm for entering the coupon code moo the PoS equipment À The Fetal PoS equipment floes not typically have automatic moans for deducting the value of the coupon from the purchase, À The lLetarl T3oS system does not typically have an online connection to the a database or databases of coupons, either those Issued by the retailer or those issued by third party manufacturers or wholesalers and thus cannot, authenticate whether the coupon is authentic or not..
À There is no smgle issuer of coupons and consequently no single database that the retailer should refer to. Nor is it likely that m the foreseeable future thal.
aggregators will emerge (cf. (redrt (:'ard processing services).
[There have been many proposals by many diverse orgarlisations suggesting techniques to reduce or eliminate some or all of these difficulties. 'lithe main classes of proposals; are as follows: Don't use a mobile at all: Some approaches e.g. Ericsson suggest that. usmg mobile c oupons Is so awkward tha.l. the best thing to do is to avoid usmg them at all! Rather than stormg the C.OUI'OIS on a mobile phone they suggest storing them on a central datal-'ase along with e.g. the users credit card number. Then when the user makes a credit cartl purchase, the coupon database is checked and the value of the coupon automatically deducted from the purchase. This is a highly unreahstic approach smce it would mean that: À A large number of consumers are prepared to register their credit card details each time they claim a mobile coupon Retailers and/or c relit card acquiring back modify their systems so that each and every credit curd transition is also passed to one or more coupon databases on
the off chance that there might be a discount coupon pertinent to this transact Ion À It would not be possible to associate the coupon which Is specific to a particular product with a credit card authentication request which merely specifies the amount. of money for which authorsation is sought.
I.e. while the concept of mobile coupons has been around for a long time and despite the amount of work to date the problem with them has been and remams the difficulty of producing a system that will Issue and redeem tokens m a way that is easy for consumers arid does not require a huge investment in changing existing retail systems.
Barodes: Serldrlg COUpOllS to the mobile phone s display as a bar-code or some other machine readable format. I his allows t he coupon to be scanned in exactly like a paper coupon. I lowever there are still major practical problems with this approach: À Harcode readers can t read them all that reliably. T]R.tlil assistant would have to attempt to scan many many times to get the bar c-ode reader to accept it. This would mean that retails would not accept; this as an acceptable solution.
À It Is skill quite easy to c opy and or reuse the c oupon sloce it has not Leon deleted from the phone. This approach still requires a central authen tcatio n/authorisatioll rnfrastruc t ure.
Use InfraRed / BlueTooth: Send information from the mobile phone via a short range wireless link lo the Point of Sale terminal. This approach Is totally irnpract;'cal since only a few mobile phones have these short range wireless links and practically no PoS equipment has the corresponding links. Even if these were available complex authentication standards that would be required between mobile and E'otS these would have to be agreed and embodied in software and have become c ommonplace before they c ould be used as the basis of a practical system.
Use WAP: Many moble-coupon.Ipproaches are based on using WAT' and based on the Implicit assumption that W1W (mobile internet) pages will operate rr1 exactly the
same way as fixed mternet (HTML) systems.
Use special software in the phone: Some people suggest using special software m the phones. However t;hls is Impractical since practcllly no current phones have the ability to download and use special software applicat,ons. Moreover without hnks to central aul,hentcation systems the Retailer remamC; highly vulnerable to fraudulent, software m the mobile software.
I: F'atent. (13 2 1372 '367 (1,rlcsson) acknowledges that mobile COUpOllS are weld known and that, the problem with the normal method of redeeming them, ''showing his C'OtlpOn on the phone's display to a sales assistantthe coupon iS typically a referomce code", Is cumbersome and slow for both consumer and retailer. It proposes a solution to wherein data is stored on a central server, (rather than on the consumers phone) and are automatically deducte:l when the consumer makes a purchase. To enable thus, when the coupon is generated, it Includes details of the purchasers Identity. Also the F,omt of Sale terminal must, be c,omected to the mt; crnet,. (coupons are generated In response to e.g. Ads on TV. Consumer claims the ad by using their mobile ptlone (not specified exactly how) by hrowsmg to the web page specified for that TV commercial. (consumer must submit personal data which will allow subsequent purchases to he to he linked back to this COUpOII reglued,. (consumer makes a purchase. Point of Sale device is linked to Internet,.
I'omt of Sale device uses personal data provde:l by the consumer (credit, card no, mobile phone no) to flurry the database which Issued the coupon. (central server links the personal flats to the coupon (no details given on resolving ambiguities).
Sends the c-,oupon back from the central server to the point of Sale. Point of Sale device deducts the value of the coupon.
In patent, (my 2 '3ti2 979 (N()KIA) users buy goods online e.g. via a web or wap page.
The cost of the goods LS debited from the users credit card and the user Is then sent a bar-colo which acts as a receipt, for the goods. The user then goes to a physical dispenser e.g. a cinema t,cket printer, has the bar code scanned and the tickets are printed out. This mventon fails to solve the problem of repeated use or copies of the receipt rlata. E.g. a fraudulent, user could present the receipt over and over again and gain multiple tickets. Another mayor problem that this patent alludes to but
does not solve is the fact that it is very difficult to read a bar code from a mobile phone screen. With a standard bar code reader with red leds the scanner works about 6()-80% of the time, If one carefully wiggles the scam1er about anal gets the right. angle. A SUCCESS rate of 60 8()% is OK for lab demo but nowhere near good enough for a commercial service. The Nokia pat;enl, says that it works better if you use white led Illumination, but smc.e most installed bar code scanners use red teds, this is a moot point,. This approach could not be used as the basis of a pract,ic.al service.. I'atent (JIB 2 361 670 (13A) is a pa,oerless ticketing system. It, Is pretty much the same as Ll 2 3;2 979 (NOKIA) except that insteafl of sending the mobile phone a picture SMS the ticket data Is sent as text and the phone contains a SlM Tool Kit software application which converts this into a barcode. It does recognise that it is necessary to connect the barcode reader back to' the central ticket issuing computer In order to avoid multiple presentations of the same ticket.
Patent, W() ()1/9312() (lll<LSTRA NEW WAVE) is yet another WAP / barcode a.pplcaton. It has one small twist. It claims a self vahdatng bar-code whereby the barcor.le number Is created from an algorit,hlmc combination of things Eke the date, the mobile phone number and so on so that it can be validated locally. Flut nevertheless to prevent repeat, redemptions it has to be checked against a local computer so it might as well have been checked against the central computer. I.c.
this IS a pretty useless ar:ldtion.
US 2U()2/()():;;713 (AWAL)A) has a Ivery] slight twist; on location based services.
('onventonal cellular location based scrvces allow a user to browse to a wap page that; will give him a hst of faclt,ies local to his currcat location e.g. nearest petrol stations, banks, resturant,s elf. The "nnovatol1" U1 this patent is tt' give the user a coupon to these stores.
JO 2002 109353 (STT,) IS yet another WAF'/barcxde (or other image) coupon. The twist n1 this cease is that there a three st,e,o procedure (a) the consumer browses to a
wap page to request the coupon (b) the wap server delivers an advert (c) the wap server then delivers the Image of the COUpOIl.
Similar fraud Issues apply to Issuing and redeeming any kmd of voucher or ticket based on SMS messaging. It is simple to send an SMS to someone saying something akin to "This is 'l'icket No. 123166 for the Show ". IIowever it IS highly unlikely that with the current state of fraud protection lhat event orgamsers would accept this as a legitimate ticket.
This vulnerabihty of tSMS based dscounl COUpOllS and mobile-tckets if unchecked would limit their adoption and usage. The object of the present invention IS to reduce and as far as possible eliminate fraud on these. There are many possible ways that this fraud could be avoided but. that would require large investments In infrastructure terminal equipment and staff tra.imug. Another object of this mveIltiorl Is to enable authentication without requlrmg any large additional Investments of this rmture and thereby encotlragc service deployment and adoption.
Summary of the Invention.
This invention reduces the possibility of fraud on SMS delivered mobile tokens (dlS()Unt, Coupons, vouchers t tickets etc) by providing a Token Issumg and Authentication system.
The baisc idea Is to send the coupon in a text message and to make this message appear 1' come from a particular mobile number which is unique to that particular user/coupon. Then to redeem the coupon the user simply uses the mobile phone's normal automatic text message reply feature. The central server then authenticates is rcqtlest and sends the authentication message in a special type of text message that appears Immediately on the screen of the mobile phone (rather than going Into the sms message inbox). If the Retailer has a mobile phone or an Tnternet browser device then the authentication message may also be sent thorn.
To Issue a mobile token the Issuing Merchant sends an SMS text message to the consumer contaimng details of the offer. A key feature of this message Is that it contalms a "Reply" number i.e. a telephone number dent; 'fymg the entity which orgmated the message.
The Issuing Merchant maiIltalns a pool of these Reply numbers and Bantams a database that records which Reply number was used when sending a particular SMS discount coupon to a particular consumer's mobile phone.
To authenticate a moblc-token the consumer Replies to the original message. The Authentication ('entry ther1 receives a message. It knows the mobile number of the consumer who sent this message and the number which it sent the message lo. 11 can thou use these two numbers to retrieve from its database details of l he mobJe-
token. It can check that this token was mdeed correctly Issued and has not already l:,een redeemed.
l'he consumer may optionally Include other Information in the reply message e.g. the name of the lletallor the Name or code of the product and so on.
I'he authentication system then sends the authentication message back to the consumer's mobile phone. It sends this In a special type of SMS message. It sends the authentication message m a "(lass ()" SMS message. This type of message Is not stored m the phone's Inbox but rather Is displayed Immediately on the phone's display. The Retail Sales asssl;ant then witnesses this message arriving. Because the message arrives In realtme rather than being stored In the phone's memory the Rel.aler can be much more confident thal the message has nol been counterfeited.
The system may also send flus message from an Originating mobile number that has been prc-agrecd with the Retailer. The Retailer may Ihen check that the message had been sent by this number and not by another entity attempting to fraudulently simulate a real-tme authentication message.
q
To record the coupon and to deduct it from the sale the retail sales assistant may then selects one of a series of available bar-codes and scans this m.
Because tSMS messages are sometimes not delivered the system will permit. another attempt to authenteate a token some time after the initial attempts In this case the system checks that the original message was not; delivered. If it was then subsequent attempts tin autlierll cat;e are denied but if the original was not delivered t;hon a subsequent attempt. ix permitted.
rl he benefits of this system are: it elmmates a large qua.rll sty of potential fraud.
It Is easy for (consumer and Retailer lo use It provides a. rapid authenlrcatror1 service The Relarler doe s not have to Invest in addt; ional Point of-Sale equipment The c osls of authentication are not borne by the retailer I he syslerm provides some Indirect protectors against mis-redemptron. T he system creates a time-stamped rec::,rd calf when the coupon Is redeemed. Ihls may be subsequently c ross-checked against the Retailers product sales records for that day.
I his cross-checking will reveal If a coupon from one manufacturer was redeemed but a product from aot;her manufacturer was In fact bought. This will enable the Retail to Identify the slaff merntJer who ms-redeerned the coupon and to re-tram them lo avoid further onyx urrerlce.
Details of the Invention I he InventioI1 will now he further described with the aid of the following diagrams: Referring to Figure 1.
(1()) Is a mobile phone that has the capability to originate and tic receive Short Messages. 1b
(20) is a wireless mobile communication nct,work (30) Is a Mobile Token Issuing and Authent,caton Server (40) is a medium where coupons and tickets may be pubhshed and from where the consumer may Initiate the collect,oll of a coupon.
(G()) Is a Poirlt,-of-Sale terminal or Pomt-of-erltry where goods are sold or consumers adrmrt,td to events.
(60) Is a human operative.
(70) Is a schematic of the corlsttuent parts of a mobile Short Message (SMS). (80) is the "prom" field or ()rigmat;mg Address ova SMS, (90) is the Lo,, field or
Destination Address of the SMS and (100) IS the "Message" of the SMS.
This mvent,on provides a syst,ern for Issumg and authentication mobiletokens.
These tokens may be used for the purposes of providing e.g. discount coupons, mobile-vouchers, moble-tickets and so Oll.
There are three parties who participate iTI a mobile-Token transaction: The Token-lssuer the consumer, and the rl'oken- ldeemor Before 'l'okens are Issued, the 'I'oken-lssuer estabhshes a stock of Tokens in the Authentcat,ion Server (30). They define t;hc nominal value of these Tokens, the message that is sent with the rl'oken and an ()riginat,ng Address (80) that will be used to send Authentication messages.
The Issuing of a mobile-token may be triggered in a wide variet-,y ol'differellt ways.
They might be Issued to c osumors either m response to a request from a consumer or they may be unsohcrted. For example ( IF XXXXXXX discloses a system where
consumers may request mobile-tokens In response to viewing specific advertisements. Similarly merchants may issue tokens lo consumers who perform certain actions on a web-ste or to consumers who buy tickets. Alternat.vely a Merchant may spontaneously issue tokens to existing customer or to potential c ustomers.
I'o prepare to Issue mobrlc-Token the'l'okerl-lssucr establishes a stock of mobile-
lokers in the'l'okerl-Server (my A mobile-tfkerl Is issued as follows. All action occurs which st.imulat;cs the rl'oken-
Server (do) to despatch a mobile-token. The Server (''30) formulates a message to send to the destination consumer. The body of lithe message (100) Is a predeEned message defined by the organsal;ron publishing the mobile-token. 'lithe message has an ()rrgirlatrrlg Identifier (80) and a destination identifier ('3()) which is the molJrle number of the consumer 'l'he 'l'oken-Scrver (.30) has a portal of available C)riginating Identifiers (80). 'l'he Server (30) maintains a record of which OrgnatiIlg Identifier (80) was used along with which Dest.,natiori identifier ('3()) to send that Token.
l'he consumer then receives the SMS message. If the c onsumer c houses to keep for future use the 'l'okerl represented by this SMS message then they store it in their mobile ph:me's memory. ((:)r equivalently in the memory provided In the phone's SIM). l'o redeem the Token the consumer Replies to the message representing the Token and tiers actors Is witnessed by a human representative (60) of the orgar.tisation accepting the'lokerl. The consumer sends a blank reply to the message contammg the Token. They may optionally include information mto this reply such as l. he Name of the Retailer and/or the Product Name or code of the product against; which thc token Is lacing redeemed.
l'he vast; majority of mobile phones provide an SMS Reply feature which automatically addresses all outgoing text message to the (:)rigmatmg Address ova received SMS. If the mol.nle terminal does not provide this feature the user would have to manually address the limply to the () rrgmating telephone number of the I_
Token SM:S.
rl'hs Reply SMS is then received by the Authentication Server (30). The Authentication Server (80) DOW checks: (a) That the Token was in fact, issued at some point m the past i.e. that pair of ()rgnatmg arid Dest, ulation addresses had been employed to send a Token.
(b) that the Token ahs not already been redeemed.
if the consumer also included additional text in t,helr reply message, then this is parsed to, vahdatc-, that all the condtiolls arc acceptable, e.g. that, the named Retailer accepts these c oupons, and that the Coupon issuer corltillues to honour these rl'okens and so on.
If t,hcsc tests are passed then t,ho Authentcatoll Server (.()) send an a. ut,helltcation message to the consumers phone (10). in t;hc preferred embodiment t,hs message IS vent as a with the Data ('oding Scheme of the User Data set to "(lass 0". This causes the message to be displayed Immediately on the mobile phone's screen rather than bemg recorded m the phones SMS inbox. rl'hls has two advantages. Firstly it, allows the IlR, tail Sales Assistant to witness the message coming through in mall time, they do not have to ask the consumer to find and open a message from their UlbOX smco this would give the c onsumer the opport,unt,y to open a bogus authentication message. Secondly it provides a rapid method of aut; honticaton since this type ol message is sent immediately, unlike conventional SMS messages which are store-and-forward. Another a.dvant; age is that if the message cannot be delivered for any reason, the system will lie aware of this Immediately and can retry.
Likewise the lift,aller and c.onsumor will become accustomed to the filet, that, either the message will come through immediately or not at all.
In an alternative implementation, the authentication. message is sent in a conventional Sms message.
In the preferred embodiment the system sends the Authentcator1 message with an ()rgnating Address (80) that has been pre-defined by the Issuing Merchant. This
allows the Retail Sales Assistant (60) to see and validate that the message did Indeed come from the server rather than from an cntt;y attempting to send a. bogus autheTltcaton message.
The Issumg Merchant may also pre-detinc a Password with the Authentcallon Server (). TIZIS E: assword Is then sent in each Authentication message This alto allows the tluman (gatekeeper (G x) to vahdate that the message IS authentic.
The Authentication server ('30) c an additionally send an authentication message to a terminal Device bolongmg to the Acceptor. This device may be as simple as a mobile phone r e the, Authentication Server (30) sends the authentrcal;ron message to the Ac.cept,ors mobile phone.
If the token does not pass these tests then the system sends a Dadurc message If the Retalcr then agrees to accept the Token, they then they permit the consumer to do the item '.ndc.ated by the token e.g. deciuct the value of the coupon, redeem the voucher, perrtZlt the consumer access to an event etc. ]:'he Merchant, may record the acceptance ot'thrs'l'oken m any number of known ways. 1+

Claims (1)

  1. Claims
    l) An elec.tromc couponng system comprlsmg a mobile terminal and a Token ssunng and Redempr,ron Server wherrn coupons are Issued by clelverlllg an SMS or MMS to a mobile and Include an embedded source numDcr and where the cornblllatron of the mobile number and the embedded source number Comely rdontlfy an individual Moulton and wherrll the the token IS autherlblca.t.eil by the mo'olle phone sending a reply SMS/vIMS to the 'lioken lssuug acid Redemption Server, the Token Issumg and Rec'eptron server chcckmg that this particular coupon has not; previously been redeemed and if not sends an authentrcatlon SMS leach to the mobile phone 2) A system as in claim 1 wherein the authentrcatlon message IS sent directly to the screen of the mobile phorc, l e it '.s rnmedetly visible and is not sent to an "inbox".
    3) A system as in claim 1 wherem the reply c.ontaZns an rcLentlfier for another term.rllal clcvrce and a.utllenticaton message Is delivered, not back to the rnobl]e phone, but, to the terminal ldontltlfred In the reply message 4) A system as m Clalm.'3 where the authentrcal;on message has a source acLdress Welch Is pre-regrstcredl WlI;h anti known to the rec, lprent 5) A. system as In claim '3 where the Token authorlsaton message IS sent to a dostm.at,r<'n other than the back to the requesting moUl].e device where this alternative destination Is preregistered In the Token Issuing and Authentication server as cor
GB0227358A 2002-11-23 2002-11-23 System for issuing and authenticating mobile tokens Withdrawn GB2396520A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
GB0227358A GB2396520A (en) 2002-11-23 2002-11-23 System for issuing and authenticating mobile tokens

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
GB0227358A GB2396520A (en) 2002-11-23 2002-11-23 System for issuing and authenticating mobile tokens

Publications (2)

Publication Number Publication Date
GB0227358D0 GB0227358D0 (en) 2002-12-31
GB2396520A true GB2396520A (en) 2004-06-23

Family

ID=9948388

Family Applications (1)

Application Number Title Priority Date Filing Date
GB0227358A Withdrawn GB2396520A (en) 2002-11-23 2002-11-23 System for issuing and authenticating mobile tokens

Country Status (1)

Country Link
GB (1) GB2396520A (en)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102005062342A1 (en) * 2005-12-23 2007-06-28 Abb Patent Gmbh Request e.g. service request, allocation and automatic processing system for use over e.g. data network, has unit administering or processing allocations of conditions to process using access codes and/or identification characteristics
GB2461730A (en) * 2008-08-22 2010-01-13 Peter Tanner Pairing outgoing messages with end user responses
GB2490007A (en) * 2011-03-21 2012-10-17 Ibm Tracking message responses by associating calling and recipient phone numbers with a message
US8688090B2 (en) 2011-03-21 2014-04-01 International Business Machines Corporation Data session preferences
US8903847B2 (en) 2010-03-05 2014-12-02 International Business Machines Corporation Digital media voice tags in social networks
US8959165B2 (en) 2011-03-21 2015-02-17 International Business Machines Corporation Asynchronous messaging tags

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003044711A1 (en) * 2001-11-21 2003-05-30 Kent Ridge Digital Labs Method for distributing and redeeming electronic coupons using an electronic messaging service

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003044711A1 (en) * 2001-11-21 2003-05-30 Kent Ridge Digital Labs Method for distributing and redeeming electronic coupons using an electronic messaging service

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102005062342A1 (en) * 2005-12-23 2007-06-28 Abb Patent Gmbh Request e.g. service request, allocation and automatic processing system for use over e.g. data network, has unit administering or processing allocations of conditions to process using access codes and/or identification characteristics
GB2461730A (en) * 2008-08-22 2010-01-13 Peter Tanner Pairing outgoing messages with end user responses
GB2461730B (en) * 2008-08-22 2010-11-10 Peter Tanner A communication device
US8903847B2 (en) 2010-03-05 2014-12-02 International Business Machines Corporation Digital media voice tags in social networks
GB2490007A (en) * 2011-03-21 2012-10-17 Ibm Tracking message responses by associating calling and recipient phone numbers with a message
US8600359B2 (en) 2011-03-21 2013-12-03 International Business Machines Corporation Data session synchronization with phone numbers
US8688090B2 (en) 2011-03-21 2014-04-01 International Business Machines Corporation Data session preferences
US8959165B2 (en) 2011-03-21 2015-02-17 International Business Machines Corporation Asynchronous messaging tags

Also Published As

Publication number Publication date
GB0227358D0 (en) 2002-12-31

Similar Documents

Publication Publication Date Title
US20190188682A1 (en) Mobile image payment system using sound-based codes
AU2006318892B2 (en) Electronic vouchers
US9721243B2 (en) Mobile payment system using subaccounts of account holder
US20130110607A1 (en) Coupon generation, authentication, and redemption via a network
US20070156517A1 (en) System and method for redemption of a coupon using a mobile cellular telephone
US20120179531A1 (en) Method and System for Authenticating and Redeeming Electronic Transactions
KR20000023866A (en) Ticket selling system
WO2008008037A1 (en) Voucher systems and methods
GB2396520A (en) System for issuing and authenticating mobile tokens
KR20100007063A (en) Trading system of mobile coupon and method of trading the mobile coupon
US20080120179A1 (en) Method Of Commerce
KR20120114799A (en) Payment system using qr code
US20140074710A1 (en) Consumer Processing of Payments for Merchants
IES20040572A2 (en) A system and method for validation of electronic vouchers
JP2022122507A (en) Settlement processing method
WO2005081148A1 (en) A system and method for the validation of electronic vouchers
US20230041655A1 (en) Slap pay and snap pay contactless payment and data systems
EP4075366A1 (en) Method and system for crediting a reward to an electronic wallet account
JPWO2005073885A1 (en) Card payment system
KR20020094082A (en) SMS Information service apparatus using SMS gift certificate and method thereof
KR20030023944A (en) Buying certification and payment system by handphone
GB2432702A (en) Electronic vouchers
Vatsavayi et al. M-commerce payment systems
KR20040008391A (en) System for settling account service using 2-dimensional barcode
CA3012504A1 (en) Justwallet payment systems and method

Legal Events

Date Code Title Description
WAP Application withdrawn, taken to be withdrawn or refused ** after publication under section 16(1)