1111111111111111 IIIIII IIIII 11111 1111111111 lllll lllll 111111111111111 111111111111111 11111111
`US 20050222961Al
`
`(19) United States
`(12) Patent Application Publication
`Staib et al.
`
`(10) Pub. No.: US 2005/0222961 Al
`Oct. 6, 2005
`( 43) Pub. Date:
`
`(54) SYSTEM AND METHOD OF FACILITATING
`CONTACTLESS PAYMENT TRANSACTIONS
`ACROSS DIFFERENT PAYMENT SYSTEMS
`USING A COMMON MOBILE DEVICE
`ACTING AS A STORED VALUE DEVICE
`
`(76)
`
`Inventors: Philippe Staib, Bangkok (TH); James
`Helm, Bangkok (TH); Thierry Renard,
`Bangkok (TH)
`
`Correspondence Address:
`REED SMITH, LLP
`ATTN: PATENT RECORDS DEPARTMENT
`599 LEXINGTON AVENUE, 29TH FLOOR
`NEW YORK, NY 10022-7650 (US)
`
`(21)
`
`Appl. No.:
`
`10/940,939
`
`(22)
`
`Filed:
`
`Sep. 14,2004
`
`Related U.S. Application Data
`
`(60)
`
`Provisional application No. 60/559,818, filed on Apr.
`5, 2004.
`
`Publication Classification
`
`Int. Cl.7 ....................................................... H04L 9/00
`(51)
`(52) U.S. Cl. ................................................................ 705/64
`
`(57)
`
`ABSTRACT
`
`A system for facilitating contactless payment transactions
`across different contactless payment systems using a com(cid:173)
`mon mobile device that acts as a stored value device is
`provided. A combination of a mobile application and a
`communication module allows the mobile device, which is
`associated with one payment system, to emulate various
`transmission standards and data exchange formats that are
`used in different payment systems in order to perform
`contactless payment transactions with merchants that are
`associated with different contactless payment systems. A
`service application running in a service operator computer
`communicates with the various contactless payment systems
`to facilitate the settlement of the amount owed to various
`payment systems by the one payment system associated with
`the mobile device.
`
`1q,
`___ 1~\~-----~-- ---··-·---··-·······----·-- ---·····-··-L-!_!!._j_,,,-Se,r-...,>1._{ce...,_..__.._~_,_ 48
`. ··•-•-·· ·-··----~•-- L Of~"'-1'.o'f"
`11(~
`-~--------.-...... --·- ---·-.
`~--------+-
`------------·· C
`,,__ _____ -----·-·-- --·--· ---
`-·
`··--· l".1'1"K ___ .................... ,, ........•..... •'"'"--··--·-·-+--i ~1...._-___.--'!C!..
`.... _-_-_-__
`\
`
`----------,
`I
`I
`,.,.......--:-c---i----._-50
`l
`\
`I
`~
`l
`I
`
`11-i
`
`t c - ~°.t~
`
`~~
`
`I
`
`J
`
`tf't
`
`,,
`
`,qi ,...._,,---.--t------,...,..__,
`• ~ p_ \\t Opt,,,-: uv'
`,
`r~;v-i~;~~ ~o.~l ,
`
`IS-f
`1......1-----~
`
`GOOG-1005
`GOOGLE LLC v. RFCYBER CORP. / Page 1 of 21
`
`

`

`Patent Application Publication Oct. 6, 2005 Sheet 1 of 9
`
`US 2005/0222961 Al
`
`-- -
`
`;;I-
`
`()0
`0
`
`(
`
`€~
`($
`,:$
`~ I,.
`~o
`
`lt
`
`...
`--
`
`:s
`
`()..
`<.J
`
`...._
`0
`rl H
`
`0
`
`!
`/4
`'-.A)
`0
`
`I
`
`,_
`
`-
`
`-
`
`-
`
`-
`
`- -1
`
`0
`
`- ~
`~
`+-(/\
`_f.
`($
`D
`
`00
`
`'"E"
`cf
`~
`'$')
`~ ~
`0
`0
`
`I
`
`'1---
`0
`
`I
`I
`
`-- --
`
`0
`
`[]J°
`a Qo
`
`~...-+
`
`-
`
`.
`\!)
`t-1
`LL
`
`GOOG-1005
`GOOGLE LLC v. RFCYBER CORP. / Page 2 of 21
`
`

`

`Patent Application Publication Oct. 6, 2005 Sheet 2 of 9
`
`US 2005/0222961 Al
`
`~
`s:
`Q.)
`Ii$ -t-
`s
`_.s;
`0-
`~
`u
`
`<l
`
`J--·----·------·-~
`\~
`
`:5
`
`~
`\.J
`
`-
`
`'
`
`!
`I
`
`I
`
`0 -
`
`+-:S:
`~
`_c
`u
`>
`q.>
`£
`
`ti
`•
`\.b
`.......
`LL
`
`~
`
`~
`
`l . ,,
`Q,I "
`-
`t
`
`a>
`. ;
`_{)
`()
`
`cl
`
`i~
`
`<
`
`~
`
`~
`
`~
`
`a_
`...s:.
`u
`
`-
`
`Ill
`).,
`lo,,
`0
`,:,
`~
`I.) Q)
`~ ~
`
`GOOG-1005
`GOOGLE LLC v. RFCYBER CORP. / Page 3 of 21
`
`

`

`Patent Application Publication Oct. 6, 2005 Sheet 3 of 9
`
`US 2005/0222961 Al
`
`- -- - i
`,~
`""
`l l
`JO
`t V ~'>
`v\
`
`- -
`
`.,.
`
`I
`
`I
`t
`I
`
`C)o
`
`·~
`
`~8
`~ .,,.
`0
`'>
`E~
`
`\
`
`e,
`
`--
`
`tJ~
`
`'
`\
`.__ _______ -
`I
`
`0
`4'
`
`£
`
`+-
`~ -
`l
`
`>--
`
`6.
`
`Qi
`
`t
`
`i,... ' Q)
`,
`. f ~ ,~
`I !_
`·~ 13
`0
`-
`l-t-
`
`I
`
`GI
`
`.J
`
`(V)
`•
`\!)"
`H
`lL
`
`GOOG-1005
`GOOGLE LLC v. RFCYBER CORP. / Page 4 of 21
`
`

`

`Patent Application Publication Oct. 6, 2005 Sheet 4 of 9
`
`US 2005/0222961 Al
`
`0
`
`0 -
`
`GOOG-1005
`GOOGLE LLC v. RFCYBER CORP. / Page 5 of 21
`
`

`

`Patent Application Publication Oct. 6, 2005 Sheet 5 of 9
`
`US 2005/0222961 Al
`
`!
`
`j
`1 a>
`d
`""
`II\
`~
`E
`
`----.)>
`
`~
`(cid:141)
`-t2-
`1
`
`~
`0
`~
`--
`Jl
`~
`3
`~
`
`A
`~
`
`0
`0
`
`/
`\
`
`ti, ~
`r,_1.
`,.. u
`<) >-
`QI ~
`t> ~
`
`U)
`.
`w
`\-l
`LL
`
`t
`,·;.
`~
`~
`s::: .~
`~
`ii
`.,,.
`£i l
`I u
`
`c,
`
`I
`
`cl
`----:-
`
`T
`
`s::
`~
`~
`~
`J
`rJ
`cE.
`
`0
`
`GOOG-1005
`GOOGLE LLC v. RFCYBER CORP. / Page 6 of 21
`
`

`

`Patent Application Publication Oct. 6, 2005 Sheet 6 of 9
`
`US 2005/0222961 Al
`
`0
`rt-
`
`GOOG-1005
`GOOGLE LLC v. RFCYBER CORP. / Page 7 of 21
`
`

`

`Patent Application Publication Oct. 6, 2005 Sheet 7 of 9
`
`US 2005/0222961 Al
`
`,..
`t--1-~ 4:.
`f - i 1...-
`i1o
`
`_o Q)
`
`'5
`
`<(
`
`·~
`c;,O
`
`.j-
`c;,o
`
`0
`QO
`
`~ ~
`oK
`>
`<5
`-
`',s
`__c
`\-
`
`0
`
`·~
`
`GOOG-1005
`GOOGLE LLC v. RFCYBER CORP. / Page 8 of 21
`
`

`

`Patent Application Publication Oct. 6, 2005 Sheet 8 of 9
`
`US 2005/0222961 Al
`
`GOOG-1005
`GOOGLE LLC v. RFCYBER CORP. / Page 9 of 21
`
`

`

`Patent Application Publication Oct. 6, 2005 Sheet 9 of 9
`
`US 2005/0222961 Al
`
`I
`
`J
`
`,,
`
`,qi
`
`r¼---,-;--,~-,,...,
`''N11,.\I~ o~~,' ,
`(:..C:::\1.1.i~(~~ ~/Ar,k_ ,
`
`4-'i ,--L----~
`
`I 'I',-
`
`1s0
`
`GOOG-1005
`GOOGLE LLC v. RFCYBER CORP. / Page 10 of 21
`
`

`

`US 2005/0222961 Al
`
`Oct. 6, 2005
`
`1
`
`SYSTEM AND METHOD OF FACILITATING
`CONTACTLESS PAYMENT TRANSACTIONS
`ACROSS DIFFERENT PAYMENT SYSTEMS USING
`A COMMON MOBILE DEVICE ACTING AS A
`STORED VALUE DEVICE
`
`CROSS REFERENCE TO RELATED
`APPLICATIONS
`
`[0001] This application claims priority to U.S. provisional
`patent application No. 60/559,818, filed Apr. 5, 2004, which
`is incorporated herein by reference.
`
`FIELD OF THE INVENTION
`
`[0002] This invention relates to mobile commerce, and
`more particularly electronic payment systems for portable
`devices that act as smart cards.
`
`BACKGROUND OF THE INVENTION
`
`[0003] Millions of consumers across the world are already
`paying for purchases of goods and services using contactless
`payment, with millions more expected in the years to come
`as new contactless payment initiatives are launched in many
`different countries.
`
`[0004] Consumers love the convenience and speed of
`paying with a contactless card or other contactless device
`with no more fumbling for cash, counting change, or worry
`about whether they have enough cash for a purchase. In
`many cases, consumers don't even need to sign a payment
`card receipt or enter a personal identification number (PIN).
`
`[0005] Contactless payment is particularly attractive in
`merchant segments where speed and convenience of pay(cid:173)
`ment are essential, for example, quick service restaurants,
`gas stations, convenience stores, parking facilities, transit
`services, entertainment venues, and unstaffed vending loca(cid:173)
`tions.
`
`[0006] Contactless payment can include account-based
`payment, traditional credit or debit card payment, and stored
`value payment. Transaction processors ( card operators) such
`as American Express, JCB, MasterCard, and Visa have all
`conducted pilot programs for contactless payment. Major
`cities around the world already use contactless cards for
`transit payment, with major cities in the United States also
`implementing or planning to implement contactless card(cid:173)
`based automatic fare collection (AFC) systems.
`
`[0007] Consumers are already using a number of contact(cid:173)
`less payment options in a variety of situations. Consumers
`purchase gasoline, fast food, and groceries. They pay mil(cid:173)
`lions of dollars in tolls and fares using a contactless tag
`device. One contactless payment system in Hong Kong, for
`example, processes 7.5 million transactions per day for 160
`different merchants.
`
`[0008] Contactless payment requires a wireless informa(cid:173)
`tion exchange between a consumer's payment token and a
`payment terminal or infrastructure device. Contactless pay(cid:173)
`ment can be enabled using a variety of technologies and
`tokens. Radio frequency (RF) technology has been used for
`most of the contactless payment initiatives. These systems
`use high-frequency solutions, low-frequency proprietary RF
`solutions, and ultra-high-frequency RF solutions.
`
`[0009]
`ISO/IEC 14443 is a contactless smart card tech(cid:173)
`nology standard operating at a high frequency of 13.56
`MHz. This standard was initiated in 1994 to standardize
`contactless payment cards and finalized in 2001. To date,
`approximately 250 to 300 million contactless cards that are
`based on the ISO/IEC 14443 standard have been shipped.
`The majority of these cards are used in transportation
`applications for automatic fare collection, with the largest
`installations in Asia. ISO/IEC 14443 cards are supplied by
`the largest base of semiconductor suppliers and card manu(cid:173)
`facturers.
`[0010] Some payment systems use a proprietary high(cid:173)
`frequency 13.56 MHz contactless technology and are used
`extensively for transit applications in Asia Pacific markets
`such as Hong Kong and Japan and, to a more limited extent,
`in the United States. Examples of such technology include
`the FeliCa™ card used by Hong Kong transit system and the
`Go Card™ used by a number of large transit operators. The
`FeliCa card uses the same frequency and form factor as
`ISO/IEC 14443-compliant cards but differs in some techni(cid:173)
`cal specifications. The Go Card™ technology uses the same
`frequency, modulation schemes, bit coding, and form factor
`as ISO/IEC 14443 Type B-compliant cards but differs in
`other technical specifications.
`[0011] Another technology in use is a proprietary low(cid:173)
`frequency 125 to 134 KHz RF technology. The low-fre(cid:173)
`quency RF technologies operate at less than 300 KHz. These
`technologies typically use a unique ID within an application
`and therefore are most often referred to as RFID technology.
`Such technologies have been used extensively for security
`applications such as automobile immobilizers and for access
`control. The Speedpass™ system is an example of the
`low-frequency RFID technology for payment in North
`America. The Speedpass™ technology operates at 134 KHz
`and can achieve ranges up to 10 centimeters but has a
`relatively low data-transfer rate. Low-frequency RFID tech(cid:173)
`nologies have no established communications standards at
`present and the RF tag has very limited processing power.
`[0012] The most predominant form factor used for low(cid:173)
`frequency RFID payment is the key fob or key chain device,
`but both automobile-mounted tags and tags embedded in
`watches are also commercially available. The auto tags are
`active tags, requiring a battery that must be replaced every
`3 to 4 years.
`[0013] Another contactless technology is a proprietary
`ultra-high-frequency RF technology which typically operate
`in the ISM band (902 to 928 MHz in the United States) and
`has an operational range of anywhere from 3 meters to more
`than 10 meters. These technologies generally use a unique
`ID within the application, so they are also referred to as
`RFID technology. The best example of the use of the
`ultra-high-frequency RF technology that is applicable to
`payment applications is the use of RF transponders to pay
`highway tolls, such as the E-ZPass™ system (used in the
`northeastern United States), TollTag™ (used in the Dallas
`metropolitan area), and FasTrack™ (used in California).
`[0014] However, a major limitation with the existing prior
`art for contactless payment is related to the ability of a
`consumer equipped with a con tactless payment device to use
`the same device on different contactless payment systems.
`This limitation originates from the following factors among
`others: different RF technologies, different payment appli(cid:173)
`cations, and different settlement systems.
`
`GOOG-1005
`GOOGLE LLC v. RFCYBER CORP. / Page 11 of 21
`
`

`

`US 2005/0222961 Al
`
`Oct. 6, 2005
`
`2
`
`[0015] As discussed above, there are four main RF tech(cid:173)
`nologies that are used for contactless payment applications
`today. A contactless payment device for use with one RF
`contactless payment technology cannot be used with a
`different RF contactless payment technology.
`
`[0016] Even if the RF technology is the same, the con(cid:173)
`tactless payment systems in commercial operation and in
`development today use different software applications and
`settlement systems. For instance, the contactless payment
`systems deployed by the payment card (credit and debit
`card) companies use the existing settlement system and
`infrastructure already in place for payments with the stan(cid:173)
`dard card products, with applications developed for use with
`this existing infrastructure and settlement system. However,
`other contactless payment systems use different applications
`and settlement systems. For instance, the Octopus card in
`Hong Kong is based on a rechargeable stored-value account
`in the card, with the operator of the Octopus card settling
`directly with the merchants accepting the Octopus card for
`payment. Contactless payment systems use different under(cid:173)
`lying funding process for the transactions by the consumers
`on these systems, such as account-based payment, tradi(cid:173)
`tional credit or debit card payment, and stored value pay(cid:173)
`ment.
`
`[0017] Accordingly, a user equipped with a contactless
`payment device that has been enabled for a specific con(cid:173)
`tactless payment system cannot use the same device on other
`contactless payment systems, even if the contactless RF
`payment technology is the same. This is because the appli(cid:173)
`cations in the contactless payment device are designed based
`on the specific requirements, such as data exchange, secu(cid:173)
`rity, and settlement, of that specific contactless payment
`system, which are different for each contactless payment
`processing system.
`
`[0018] Another limitation of the prior art systems is that
`the stored value account can only be recharged using dedi(cid:173)
`cated hardware such as dedicated recharge
`terminals,
`recharge points, or specific ATM type terminals with
`recharge capability.
`
`[0019] Therefore, it is desirable to provide a contactless
`payment system that links multiple payment systems to
`allow a user with a single mobile contactless device to pay
`for good and services that are provided across different
`contactless payment systems.
`
`[0020]
`It is also desirable to provide a contactless payment
`system that allows the user to recharge the stored value in the
`mobile contactless device anywhere without requiring the
`user to be near a dedicated hardware terminal.
`
`SUMMARY OF THE DISCLOSURE
`
`[0021] According to the principles of the present inven(cid:173)
`tion, a system for facilitating contactless payment transac(cid:173)
`tions across a plurality of different contactless payment
`systems using a common mobile device that acts as a stored
`value device is provided.
`
`with those other payment systems by emulating the trans(cid:173)
`mission standards and data exchange formats used by those
`payment systems.
`[0023] Once the transactions take place, a service appli(cid:173)
`cation running in a service operator's computer communi(cid:173)
`cates with the various contactless payment systems to settle
`the amounts owed to other contactless payment systems by
`the one contactless payment system that is associated with
`the mobile device.
`[0024] The combination of the mobile application and the
`service application provide a complete solution to allow a
`common mobile device to pay for goods and services
`through merchants that are associated with different pay(cid:173)
`ment systems as well as subsequent settlement of payments
`among the different payment systems.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`[0025] FIG. 1 is a functional block diagram of a payment
`processing system according to the present invention.
`[0026] FIG. 2 is a block diagram of a smart mobile device
`containing a processor chip, a stored value and a contactless
`communicator according to the present invention.
`[0027] FIG. 3 illustrates a process flow of a contactless
`purchase transaction using a smart mobile device associated
`with a particular payment system according to the present
`invention.
`[0028] FIG. 4 illustrates an alternate process flow of a
`more secure contactless purchase transaction using a smart
`mobile device and a subsequent settlement of payment
`according to an alternative embodiment of the present
`invention.
`[0029] FIG. 5 illustrates a flow of an encrypted payment
`token to ensure payment and reduce payment disputes
`according to the present invention.
`[0030] FIG. 6 illustrates an overall diagram and process
`flow of an inter-operable payment and settlement system
`according to the present invention in which a user belonging
`to one contactless payment system purchases an item in a
`different contactless payment system using the same mobile
`device.
`[0031] FIG. 7 is an exemplary process flow of the pay(cid:173)
`ment and settlement system of FIG. 6 where a user residing
`in Hong Kong travels to Thailand and purchases an item in
`Thailand.
`[0032] FIG. 8 illustrates a process flow of a remote charge
`and recharge of stored value in the smart mobile device
`according to the present invention.
`[0033] FIG. 9 illustrates an alternative process flow of a
`remote charge and recharge of stored value in the smart
`mobile device according to the present invention.
`
`DETAILED DESCRIPTION OF THE
`INVENTION
`
`[0022] A mobile application running in the mobile device
`is associated with one contactless payment system. While
`the mobile device is not associated with other contactless
`payment systems, it can nevertheless perform contactless
`payment transactions with merchants that are associated
`
`[0034] Referring now to FIG. 1, a payment processing
`system 1 of the present invention comprises a plurality of
`computers 100 that are connected to each other through a
`computer network such as the Internet. The computers 100
`of the system 1 cooperate with each other to provide
`
`GOOG-1005
`GOOGLE LLC v. RFCYBER CORP. / Page 12 of 21
`
`

`

`US 2005/0222961 Al
`
`Oct. 6, 2005
`
`3
`
`comprehensive processing and settlement of purchase trans(cid:173)
`actions that are made by the same mobile device across
`different payment systems regardless of the difference in
`transmission technology, processing applications or settle(cid:173)
`ment applications.
`[0035] As illustrated in FIG. 1, each computer 100 is
`connected to a computer network such as the Internet
`through, for example, an 1/0 interface 102, such as for a
`LAN, WAN, or fiber optic, RF or cable link, which receives
`information from and sends information to other computers
`100 and smart mobile devices 10. Each computer 100 is also
`connected to a keyboard 118 for controlling the computer.
`[0036] Each computer 100 includes a memory 104, pro(cid:173)
`cessor (CPU) 106, program storage 108, and data storage
`110, all commonly connected to each other through a bus
`112. The program storage 108 stores, among others, pay(cid:173)
`ment processing and settlement software programs or mod(cid:173)
`ules 114. Any of the software program modules in the
`program storage 108 and data from the data storage 110 are
`transferred to the memory 104 as needed and is executed by
`the processor 106.
`[0037] Computers 100 at merchant locations 22 are con(cid:173)
`nected to contactless reader (contactless communicator) 12
`at the point of sale which are adapted to communicate with
`smart mobile devices 10 for facilitating purchase transac(cid:173)
`tions. The system 100 can be any computer such as a
`WINDOWS-based or UNIX-based personal computer,
`server, workstation or a mainframe, or a combination
`thereof. While the system 100 is illustrated as a single
`computer unit for purposes of clarity, persons of ordinary
`skill in the art will appreciate that the system may comprise
`a group of computers which can be scaled depending on the
`processing load and database size.
`[0038] Referring to FIG. 2, the smart mobile device 10 in
`this embodiment is a mobile telephone containing a CPU 14,
`an input device 20 such as a keypad connected to the CPU
`and a memory 15 storing a mobile application 2 and the
`stored value ( digital cash) which is stored in a secured area
`of the memory 15. The keypad 20 controls the mobile device
`10. A communication module (NFC) 16 connected to the
`CPU 14 includes a communication chip and may also
`contain its own processor for handling data encryption and
`the like and secure memory area for storing the stored value.
`In an alternative embodiment, an external module may be
`connected to the NFC chip 16 which would comprise a
`secure storage area which in turn would contain its own
`processor and operating system. This external module can be
`used to store the stored value in its secure memory area. Still
`in another alternative embodiment, the stored value can be
`stored in a separate hardware such as in a USIM (Universal
`Subscriber Identity Module) (not shown) which is in com(cid:173)
`munication with the NFC module 16.
`[0039] The NFC module 16 is connected to its own
`antenna 18 and the CPU 14 of the smart mobile device 10.
`Although FIG. 2 shows a mobile telephone that acts as a
`smart card, the contactless device (comprised of the chip 16
`and antenna 18) that can communicate with the contactless
`communicator/reader 12 can be incorporated into a variety
`of portable devices such as a PDA, notebook computer, key
`chain, traditional plastic card, pager devices, watch or the
`like.
`[0040] At a merchant 22 where goods and services are
`rendered, the contactless communicator 12 is the RF reader
`
`device that communicates with the mobile device 10 to
`facilitate the purchase and payment. Similar to the mobile
`device 10, the contactless communicator 12 contains a chip
`(NFC module) 23 and an antenna 24. A merchant computer
`100 running a merchant application software 39 at the retail
`location 22 is connected to the NFC module 23 for process(cid:173)
`ing the purchase transaction.
`[0041]
`In one embodiment, the NFC module 16 and the
`antenna 18 are based on RFID technology called NFC
`("Near Field Communication") which enables wireless
`interface between two devices. NFC is a short range tech(cid:173)
`nology that supports communication at distances measured
`in centimeters. The devices have to be literally almost
`touched to establish a communication link between them.
`This has two important advantages. One, the devices are
`inherently secure since they need to be placed very close to
`the communicator 12. Two, NFC technology supports pas(cid:173)
`sive mode of communication. This is very important for the
`battery-powered devices since conservation of energy is a
`high priority. The NFC protocol allows such devices as a
`mobile phone to operate in a power-saving mode-the
`passive mode of NFC communication. This mode does not
`require both devices to generate the RF field and allows the
`complete communication to be powered from one side only.
`Of course, the device itself will still need to be powered
`internally but it does not have to waste the battery on
`powering the RF communication interface.
`[0042] The NFC protocol is also compatible with a wide
`variety of contactless smart card protocols.
`[0043]
`In the embodiment shown, software applications
`that can be downloaded to and executed by the processor 14
`of the smart mobile device 10 for communication with and
`control of the NFC module 16 is done using J2ME MIDP
`(Mobile Information Device Profile), Version 1.0 and 2.0.
`The MIDP 1.0 provides core application functionality
`required by mobile applications, including basic user inter(cid:173)
`face and network security. The MIDP 2.0 further provides
`new features such as an enhanced user interface, multimedia
`and game functionality, greater connectivity, over-the-air
`(OTA) provisioning, and end-to-end security. In various
`implementations, there may be an external security module
`and storage area attached to the NFC interface. This secure
`module may have the ability to utilize the operating system
`of the mobile phone 10 to create secure internet connections
`for the purposes of transferring data directly from the secure
`storage to the service operator 48.
`[0044] MIDP 2.0 adds a robust end-to-end security model,
`built on open standards, that protects the network, applica(cid:173)
`tions and mobile information devices. MIDP 2.0 further
`supports HTTPS and leverages existing standards such as
`SSL and WTLS to enable the transmission of encrypted data.
`In MIDP 2.0, security domains protect against unauthorized
`access of data, applications and other network and device
`resources by MIDlet suites on the device, which are small
`application programs similar to Java applets. By default
`MIDlet suites are not trusted, and are assigned to untrusted
`domains that prevent access to any privileged functionality.
`To gain privileged access, a MID let suite should be assigned
`to specific domains that are defined on the smart mobile
`device 10, and should be properly signed using the X.509
`PK.I security standard. In order for a signed MIDlet suite to
`be downloaded, installed and granted associated permis(cid:173)
`sions, it should be successfully authenticated.
`
`GOOG-1005
`GOOGLE LLC v. RFCYBER CORP. / Page 13 of 21
`
`

`

`US 2005/0222961 Al
`
`Oct. 6, 2005
`
`4
`
`[0045]
`Instead of MIDP, other standards such as the
`BREW™ specification developed by Qualcomm Inc. of San
`Diego, Calif. and Windows Mobile TM operating system
`developed by Microsoft Corporation of Redmond, Wash.
`may be used.
`
`[0046] A contactless payment transaction involves the
`following players: service operator 48, wallet operator 50,
`users who subscribe to the payment services of the service
`operator, financial institutions 49 holding deposit accounts
`of the users, and merchants 22 who provide goods or
`services.
`
`[0047] The service operator 48 provides the software and
`information technology requirements of the payment clear(cid:173)
`ing service of all purchase transactions. The wallet operator
`50: 1) receives customer's money on its bank account from
`the customer's bank during the initial load and top up of the
`stored value; 2) pays the merchants 22 or the contactless
`payment networks with roaming agreements for customer's
`transactions; 3) converts stored value into foreign currency
`when the customer goes abroad and coverts it back into
`home currency when the customer returns; 4) pays wallet
`operators of different contactless payment systems whether
`they are located in other areas or the same areas. The
`functions provided by the service operator 48 and wallet
`operator will be explained in detail later herein.
`
`[0048]
`Initially, a user signs up for a contactless payment
`service with the service operator 48. The wallet operator 50
`has an existing arrangement with the bank 49 holding the
`user's deposit or credit card account (see FIG. 8). During
`sign-up, a predetermined amount of money is transferred
`into a bank account of the wallet operator 50 and is written
`into the secured area of the memory 15 of the smart mobile
`device 10 as a stored value. The mobile device 10 is now
`associated with a particular payment system or network such
`as shown in FIG. 3 which shows the merchant 22, mobile
`device 10, service operator 48 and wallet operator 50 all
`associated with a single payment system or network. The
`merchants 22 have an existing arrangement with the service
`operator 48. Once goods or services have been rendered, the
`merchant 22 presents a payment request to the wallet
`operator 50.
`
`[0049] The wallet operator 50, which essentially acts as a
`bank, may be a part of the service operator 48 or a separate
`entity that has an existing agreement to handle all financial
`aspects of the contactless payment transactions for the
`service operator 48.
`
`[0050] A more detailed explanation is made below with
`reference to FIG. 3, which illustrates a process flow of a
`purchase transaction of a smart mobile device associated
`with a particular payment system and subsequent settlement
`of payment.
`
`[0051] Step 32 is an optional step that is executed only
`when the user is traveling to a foreign country and needs to
`convert the currency of the stored value into the respective
`foreign currency. In this step, using the mobile device 10, the
`user executes a mobile application program 2 stored in the
`memory 15 which was developed using MIDP 2.0. When a
`"roaming" option and a particular foreign country is
`selected, the mobile application program 2 determines
`whether a cross border application 41 is loaded into the
`memory 15. If not, the mobile program downloads the cross
`
`border application 41 (plug-in module) stored in the com(cid:173)
`puter 100 of a foreign exchange service operator 30. The
`cross border application 41 can be downloaded through OTA
`(Over The Air) download through a mobile telephone opera(cid:173)
`tor network over SSL GPRS connection or by a distributor
`installed via NFC. In a deployment where an external
`security module is used, the mobile phone 10 may be used
`to create a secure Internet connection to the service operator
`48 and that the data and/or application are transferred
`directly from the secure storage area to the service operator
`or vice versa as required. In one embodiment, the service
`operator 48 also serves as the foreign exchange service
`operator 30 and the wallet operator 50 as a single entity. The
`cross border application 41 is executed by the processor 14
`and is capable of reading the currency stored in the mobile
`device 22, converting it into the appropriate foreign currency
`and writing the new converted value into the mobile device.
`The cross border application 41 is also capable of emulating
`the RF standard and data exchange standards of the payment
`system in use in that foreign country.
`[0052]
`In step 34, the user is ready to purchase an item.
`The user places the mobile device 10 near the contactless
`communicator 12 to initiate a payment for the purchase of
`the item. At the merchant location 22, a merchant applica(cid:173)
`tion 39 is stored in the memory of a merchant computer 100.
`In step 36, the contactless communicator 12 queries the
`mobile NFC device 10 for the stored value stored in the
`mobile device. At that point, the mobile device 10 together
`with the mobile application 2 determines the payment sys(cid:173)
`tem in use by the merchant and places the mobile device in
`an emulation mode to emulate the transmission standard and
`data exchange format used by the merchant 22.
`
`[0053] The determination of which particular payment
`system is in use can be done automatically by the mobile
`application 2 and the merchant application 39. Specifically,
`the merchant application 39 transmits an 'application id' to
`the mobile device 10 through the merchant communicator
`12, which is received by the NFC module 16. The mobile
`application 2 (global application which is a part of the
`mobile application) looks up the 'application id' within a list
`of the applications stored within the mobile device 10. The
`application id is stored the mobile device when the mobile
`application 2 is installed. Each 'application id' is unique and
`registered in the global application portion of the mobile
`application 2. When a match is found, the mobile application
`sets the mobile device in an emulation mode to emulate the
`transmission standard and data exchange format required by
`the payment system in use.
`
`[0054] Alternatively, the mobile application 2 can manu(cid:173)
`ally determine the payment system in use by receiving from
`the user a selection of the payment system/network among
`many payment systems in a menu displayed by the mobile
`application.
`
`[0055] The merchant's communicator 12 then authenti(cid:173)
`cates itself with the mobile device 10 so that the mobile
`device recognizes the merchant as a legitimate merchant.
`Once authenticated, the communicator 12 sends a "read
`command" for the stored value.
`
`In step 38, in response to the query, the NFC
`[0056]
`module 16 on the mobile device 10 passes data back to the
`merchant computer 100 in an encrypted form. The data
`includes the stored value, customer ID, transaction ID, time
`
`GOOG-1005
`GOOGLE LLC v. RFCYBER CORP. / Page 14 of 21
`
`

`

`US 2005/0222961 Al
`
`Oct. 6, 2005
`
`5
`
`stamp and the like. After decrypting the data, the merchant
`application 39 determines whether the stored value is suf(cid:173)
`ficient to pay for the item being purchased. If yes, then the
`merchant application 39 calculates the balance and passes
`the balance data to the mobil