US008118218B2
`
`United States Patent
`(12)
`(10) Patent No.:
`US 8,118,218 B2
`Kohet al.
`(45) Date of Patent:
`Feb. 21, 2012
`
`
`(54) METHOD AND APPARATUS FOR
`PROVIDING ELECTRONIC PURSE
`
`(56)
`
`References Cited
`
` U.S. PATENT DOCUMENTS
`
`(75)
`
`Inventors: Liang Seng Koh, Fremont, CA (US);
`Futong Cho, Milpitas, CA (US); Hsin
`Pan. Fremont. CA (US): Fuliang Cho
`San Jose, CA (US)
`
`(73) Assignees: Rich House Global Technology Ltd.,
`Shenzhen (CN); RFCyber Corp.,
`Fremont, CA (US)
`
`(*) Notice:
`
`Subject to anydisclaimer, the term ofthis
`patent is extended or adjusted under 35
`U.S.C. 154(0) by 1057 days.
`
`(21) Appl. No.: 11/534,653
`
`(22)
`
`Filed:
`
`Sep. 24, 2006
`
`(65)
`
`Prior Publication Data
`|
`US 2008/0073426 Al
`Mar. 27, 2008
`
`(51)
`
`Int. CL
`(2006.01)
`GO6K 5/00
`(52) U.S. CL.
`.......... 235/380; 235/451; 235/492; 705/26;
`705/39: 705/40; 705/41; 705/64
`(58) Field of Classification Search
`235/379
`235/380, 492
`See application file for complete search history.
`
`8/2003 Atsmonetal. 0.00 235/492
`6,607,136 BI*
`
`2002/0145632 Al* 10/2002 Shmwueli etal.
`...
`. 345/835
`2009/0313689 AL* 12/2009 Nystromet al. cscs. 726/9
`FOREIGN PATENT DOCUMENTS
`WO 2007068991 Al *
`6/2007
`WO
`* cited by examiner
`:
`Primary Examiner —'Vhien M. Le
`Assistant Examiner — Christopher Stanford
`(74) Attorney, Agent, or Firm — Joe Zheng
`(57)
`ABSTRACT
`‘lechniques for portable devices functioning as an electronic
`purse (e-purse) are disclosed. According to one aspect of the
`invention, a mechanism is provided to enable a portable
`device to conduct transactions over an open network with a
`payment server without compromising security.
`In one
`embodiment,a device is loaded with an e-purse manager. The
`e-purse manageris configuredto manage varioustransactions
`and functions as a mechanism to access an emulatortherein.
`The transactions may be conducted over a wired network ora
`wireless network. A three-tier security model is contemplated
`to support the security of the transactions from the e-purse.
`Thethree-tier security model includes a physical security, an
`e-purse security and a card managersecurity, concentrically
`encapsulating one with another. Security keys (either sym-
`metric or asymmetric) are personalized within the three-tier
`security model.
`18 Claims, 9 Drawing Sheets
`
`
`
`E Purse
`securit
`
`SAM
`Module
`
`212
`
`200
`
`
`
`We
` Payment network
`
`eb agent
`and servers 0
`on PC 14
`
`
`
`Existing hardware for
`
`land-based commerce
`
`
`(e.g., stores or
`
`transportation) in
`enclosed environment
`E-commerce
`
`
`
`
` ' Contactless interface
`
`
` ingle functional
`
`
`Smart card
`s
`protocol
`
`E-Purse
`
`
`applet built on
`
`GP wi
`th
`acces.
`S to MF
`password 206
`
`
`Cell phone with
`smart card
`module
`
`M-commerce
`
`RFID reader
`
`GOOG-1028
`Google LLC v. RFCyber Corp. / Page 1 of 15
`
`GOOG-1028
`Google LLC v. RFCyber Corp. / Page 1 of 15
`
`

`

`U.S. Patent
`
`Feb. 21, 2012
`
`Sheet 1 of 9
`
`US 8,118,218 B2
`
`FIG.1A
`
`100
`
`>_—
`
`104
`
`— >o
`
`Oo7
`
`) o ©
`
`)
`
`©O
`
`
`
`E-Pursesecurity
`
`102
`
`
`
`Physicalsecurity
`
`© C
`
`c ©= O
`
`o_
`
`
`
`GOOG-1028
`Google LLC v. RFCyber Corp. / Page 2 of 15
`
`GOOG-1028
`Google LLC v. RFCyber Corp. / Page 2 of 15
`
`

`

`U.S. Patent
`
`Feb. 21, 2012
`
`Sheet 2 of 9
`
`US 8,118,218 B2
`
`OLL
`
`OLL
`
`s6e]
`
`GbOl
`
`s6e]sse99e
`
`Jadeey
`
`a1e5
`
`VLL
`
`uolouN
`0]SPUBLULUOD
`sesjoe
`
`9|Buls
`
`a|Buis91nd8xy
`
`UOIOUNL
`esind-J
`
`NddvJOsouenbes
`
`peseq
`
`pue]
`
`
`
`asJnd-3JUSW9|CGUuI
`
`YOMSU
`
`©}SPUBLULUOD
`JOWVS
`
`
`
`seyonssuolesedo
`
`aseyoind‘peo|
`
`esund-9
`
`JOAIOS
`
`cL
`
`GOOG-1028
`Google LLC v. RFCyber Corp. / Page 3 of 15
`
`GOOG-1028
`Google LLC v. RFCyber Corp. / Page 3 of 15
`
`
`
`
`
`
`
`

`

`U.S. Patent
`
`Feb. 21, 2012
`
`Sheet3 of 9
`
`US 8,118,218 B2
`
`00¢
`
`CLSWYvS
`
`S|NpoYW|
`
`easingJ
`
`junoes
`
`
`
`
`
`bleOdUOOleSJOAJBSPUL
`
`
`
`
`
`JO]aaempleyHunsixy
`
`
`
`
`
`JUSLUUOJIAUSPSSO|OUSSIJOWILWUOS-F
`
`
`
`SOJEBLUWOSPeseq-pue|
`
`ul(UoNewodsued
`
`
`
`JOSau0}s‘"6°9)
`
`
`
`Jepeslgi4Ay
`
`
`
`9DPJJ3]UISSOOeyUOD|
`
`
`
`jooo}oldpueda1|090}01d
`
`esund-J
`
`¢Ud
`
`
`90zpsomssed
`
`80¢4W0}sseo0e
`
`COZ
`
`
`
`YIMBUOY||8D
`
`piedWeLUS
`
`ainpow
`
`Joyejnwa|YIMdO
`
`
`
`uoyingje\dde
`
`S0JOLULUOD-//|]
`
`aaa2D°3oO
`
`LLa>Oo
`
`i®2>Oo
`
`coNS©3OoO
`9=—°s®D©oO—ai°Oo
`
`
`
`juebegan,yiomyeujuaWAeg
`
`
`
`
`
`GOOG-1028
`Google LLC v. RFCyber Corp. / Page 4 of 15
`
`
`
`
`
`

`

`U.S. Patent
`
`Feb. 21, 2012
`
`Sheet 4 of 9
`
`US 8,118,218 B2
`
`00&
`
`cOE
`
`|@UUOSJE0
`
`PaZouny
`
`
`
`80€)sodsuesy
`
`Bunsixy
`
`9iNpoVW
`
`UoNe}
`
`Vs
`
`vOE
`
`UONeZI|BUOSI3q
`
`uoieoddy
`
`90€
`
`-dMON
`
`asind
`
`sINpOyy
`
`Vs
`
`LLE
`
`
`
`Jebeuewpied
`
`VEDs
`
`CLE
`ja\ddy
`
`asJind-J
`
`Joyejnwe
`
`Jopeoy
`
`dlduy
`
`OLE
`
`aaa2D°3oO
`
`LLa>Oo
`
`i®2>Oo
`
`coNS©3OoO
`9=—°ifs)®D©oO—ai°Oo
`
`GOOG-1028
`Google LLC v. RFCyber Corp. / Page 5 of 15
`
`
`
`
`
`
`

`

`U.S. Patent
`
`Feb. 21, 2012
`
`Sheet 5 of 9
`
`US 8,118,218 B2
`
`Gé‘Sls
`
`Joye|nwe
`
`LLe !clejalddy!!JeBeuewpied3
`
`asind-4
`
` COL-dMON
`
`Oe
`
`
`
`80]Jodsues)
`
`Buisixg
`
`9|Npo|
`
`UO!}2}
`
`VS
`
`
`
`pukeyJOM}EU
`
`yuauAed
`
`SIOAIOS
`
`
`
`
`
`
`
`asind
`
`VS
`
`g|NpoY
`
`J9/PIIAI
`
`aaa2D°3oO
`
`LLa>Oo
`
`i®2>Oo
`
`coNS©3OoO
`9=—°©®D©oO—ai°Oo
`
`GOOG-1028
`Google LLC v. RFCyber Corp. / Page 6 of 15
`
`
`

`

`U.S. Patent
`
`Feb. 21, 2012
`
`Sheet6 of 9
`
`US 8,118,218 B2
`
`
`
`
`
`osejauueyoAjNosseYSI|Qe}Se0}UIEWOPAjLINdasUOHeo|ddeesj
`
`OSE
`
`
`
`ZSEuolezijeuosisd9]eNU|
`
`bSepeday}Woy|He}eyopeey
`
`
`
`
`
`
`
`
`
`SdIASPBU}UlJa/ddeasund-suepuepYysasund-sMauUeUaaMjagq
`
`
`
`
`
`
`
`geYS8sund-3mau3u]UsamjaqsuIdpueSheyOIesadoasund-aayesausy
`
`SOlASpP9u]UlJa|ddeesund-98uepue
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`asind-auepue;wYysHulsixe9u]UeaMmieqoF"E)/4B9E,.PEzI|euosied,JOa]e}s&0}asuNd-9ay]18Sf@dlA8p3ujulJe|dde
`
`
`
`
`
`09€jauueUDAjUuNnd—aseYSsI|qe]se0]UlBWWOpAndesUuolealddeasp
`
`
`
`
`
`
`
`c9eQ|62)ou)pueWYSBunsixeoy)BIAJo}e/NWAUeJoShayPSUOJsUeI)9}2JBUaS)
`
`
`
`
`
`
`
`
`
`Joye|Nwaay}pueIVSBunsixeau)Usemjeq
`
`Q|5e}8u)pueWSBunsixeueelASouOmMssed4a}e18Uas)
`
`
`
`801Aapau}U!Jaj\ddeasund-3uepueWyySUOneLodsuedBurysixeueUsaMjaq
`
`
`
`
`
`CNA
`
`Lea>oO--2Da°°°Oo
`
`a2>Oo
`
`coNS©3OoO
`wo=—°-ooD©a—ar=°oO
`
`GOOG-1028
`Google LLC v. RFCyber Corp. / Page 7 of 15
`
`
`
`
`

`

`U.S. Patent
`
`Feb. 21, 2012
`
`Sheet 7 of 9
`
`US 8,118,218 B2
`
`00V
`
`
`
`vOvpleaBulja]UdJayeJe|pIwWeBIASONbale9yeNIU]
`
`
`
`
`
`
`
`
`
`90}8|PILUBU)0}BSUOdSsaleCSeSodWOdssund-y
`
`
`
`asuodsalau}
`
`éPalla
`
`
`
`
`
`ja|ddeasind-a0}ysanbelespuasje/pI\
`
`
`
`
`
`JaBeuewasindau}sseo9e0}Nid
`
`VySid
`
`yuegaU}WOBsuodsasBSAIGDOyY
`
`
`
`clyJaJSUBAPUN]eBsleliulpuejUNODDeBulpuodseiooeALA
`
`
`
`PSIJIBAJ‘yUueqBullosuodse0}Isanbe.
`
`
`
`aaa2D°3oO
`
`LLa>Oo
`
`i®2>Oo
`
`coNS©3OoO
`9=—°©®D©oO—ai°Oo
`
`GOOG-1028
`Google LLC v. RFCyber Corp. / Page 8 of 15
`
`
`
`
`

`

`U.S. Patent
`
`Feb. 21, 2012
`
`Sheet 8 of 9
`
`US 8,118,218 B2
`
`GySls
`
`glyasund-994}0}Way)puespueSPUBWLUODNGdY192.1xepuediusJ9/pI|\y
`
`
`
`
`
`22JaAjesjuawAed3y}0}JSaNbssYOMaUBUI
`
`
`
`8U}PUBIC
`asuodselNGdYVUeSO}EINWUO}JEU}]S/PILUBU}0}JOY]BSayBISUaD
`
`
`
`
`SPUBWLUODSpUsspUeAIONUBUINEAGdYSu}Sayeasund-y
`
`
`
`
`UOIJEIIJIBA9]JOLpoulejesSIasuOdsedAdagy9u)veye
`
`abessowYOMISUBUlPeppsequeesUOdSe
`
`
`
`
`
`
`JQ|pllusO,oBessowsnjejsjnysseoonseo}es9Ues
`
`
`
`Bo}uonoesue.)eseyepdnpueJoyejnwa9au}0}
`
`CNA
`
`Lea>oO--2Da°°°Oo
`
`a2>Oo
`
`coNS©3OoO
`wo=—°oooD©a—ar=°oO
`
`GOOG-1028
`Google LLC v. RFCyber Corp. / Page 9 of 15
`
`
`

`

`U.S. Patent
`
`Feb. 21, 2012
`
`Sheet 9 of 9
`
`US 8,118,218 B2
`
`Buloueuls
`
`INNVS
`
`sINPo|
`
`CVV
`
`vrV
`
`O14
`Ils
`
`}8|PIUU|sdBeueW
`
`asund
`
`aaa2D°3oO
`
`LLa>Oo
`
`i®2>Oo
`
`coNS©3OoO
`re)=—3Oo=®D©oO~ai3Oo
`
`GOOG-1028
`Google LLC v. RFCyber Corp. / Page 10 of 15
`
`
`
`

`

`
`
`mB wu
`
`1. Technical Field
`The present invention is generally related to commerce
`over networks. Particularly, the present inventionis related to
`electronic purses that can be advantageouslyused in portable
`devices configured for both electronic commerce (a.k.a.,
`e-commerce) and mobile commerce(a.k.a., m-commerce).
`2. Description of the Related Art
`Single functional cards have been successfully used in
`enclosed environments such as transportation systems. One
`example of such single functional cards is MIFAREthatis the
`most widely installed contactless smart card technology in
`the world. With more than 500 million smart card ICs and 5
`million reader components sold, MIFARE has been selected
`as the most successful contactless smart card technology.
`n> D
`MIFAREis the perfect solution for applications like loyalty 2
`and vending cards, road tolling, city cards, access control and
`gaming.
`It is noticed that such enclosed systemsare difficult to be
`expanded into other areas such as e-commerce and m-com-
`merce becausestored values and transaction information are :
`stored in data storage of each tag that is protected bya set of
`keys. The nature ofthe tag is that the keys need to be delivered
`to the card for authentication before data can be accessed
`during a transaction. This constraint makes systems using
`such technology difficult to be expanded to an open environ-
`ment such as the Internet for e-commerce and cellular net-
`works for m-commerce as the key delivery over a public
`domain network causes security concerns.
`‘There is, thus, a need for a mechanism in devices, espe-
`cially portable devices, functioning as an electronic purse
`(e-purse) to be able to conduct transactions over an open
`network with a payment server without compromising secu-
`rity.
`
`35
`
`40
`
`50
`
`2
`tion with a paymentserver. In one embodiment, the essential
`data to be personalized into an e-purse include one or more
`operation keys(e.g., a load key and a purchase key), default
`PINs, administration keys (c.g., an unblock PIN key and a
`reload PIN key). and passwords (e.g., from Mifare). During a
`transaction, the security keys are used to establish a secured
`channel between an embedded e-purse and an SAM (Security
`Authentication Module) or backend server.
`The invention may be implemented in numerous ways,
`including a method, system, and device. In one embodiment,
`the present invention is a methodfor providing an e-purse, the
`method comprises providing a portable device embedded
`with a smart card module pre-loaded with an emulator, the
`portable device including a memoryspace loaded with a
`midlet that is configured to facilitate communication between
`ane-purse applet therein and a paymentserver over a wireless
`network, wherein the portable device further includes a con-
`tactless interface that facilitates communication between the
`e-purse applet therein and the paymentserver, and personal-
`izing the e-purse applet by reading off data from the smart
`card to generate one or more operation keys that are subse-
`quently used to establish a secured channel between the
`e-purse and. a SAM or a paymentserver.
`According, to another embodiment, the present inventionis
`a system for providing an e-purse, the system comprises a
`portable device embedded with a smart card module pre-
`loaded with an emulator,
`the portable device including a
`memory space loaded with a midlet that is configured to
`facilitate wireless communication between an e-purse applet
`therein and a payment server over a wireless network, the
`portable device further including a contactless interface that
`facilitates communication between the e-purse applet therein
`and the paymentserver, the payment server associated with
`an issuer of the e-purse, and a SAM module configured to
`enable the e-purse, wherein the SAM module is behind the
`payment server when the e-purse is caused to communicate
`with the payment server via the midlet over a wireless net-
`work (M-commercein FIG.2) or via the agent on a PC over
`a wired network (E-commerce in FIG.2).
`Accordinglyonc of the objects ofthe present inventions is
`to provide a mechanismto be embedded in devices, especially
`portable devices, to function as an electronic purse (e-purse)
`to be able to conduct transactions over an open network with
`a paymentserver without compromising security.
`Other objects, features, and advantages of the present
`invention will become apparent upon examining the follow-
`ing detailed description of an embodimentthereof, taken in
`conjunction with the attached drawings.
`
`
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`US 8,118,218 B2
`
`1
`METHOD AND APPARATUS FOR
`PROVIDING ELECTRONIC PURSE
`
`BACKGROUND
`
`SUMMARY
`
`This section is for the purpose of summarizing some
`aspects ofembodimentsofthe present invention andto briefly
`introduce some preferred embodiments. Simplifications or
`omissions in this section as well as the title and the abstract of
`this disclosure may be made to avoid obscuring the purpose of
`the section, the title and the abstract. Such simplifications or
`omissions are not intended to limit the scope of the present
`invention.
`Broadly speaking, the inventionis related to a mechanism
`provided to devices, especially portable devices, functioning
`as an electronic purse (e-purse) to be able to conduct trans-
`actions over an open network with a payment server without
`compromising security. According to one aspect of the
`present invention, a device is loaded with an e-purse manager.
`The e-purse manageris configured to manage varioustrans-
`actions and functions as a mechanismto access an cmulator
`therein. The transactions may be conducted over a wired
`network or a wireless network.
`According to another aspect of the present invention, a
`three-tier security model is proposed, based on which the
`present invention is contemplated to operate. The three-tier
`security model includes a physical security, an e-purse secu-
`rity anda card managersecurity, concentrically encapsulating
`one with another. Security keys (either symmetric or asym-
`metric) are personalized withinthe three-tier security model
`so as to personalize an e-purse and perform secured transac-
`
`55
`
`The invention will be readily understood by the following
`detailed description in conjunction with the accompanying
`drawings, wherein like reference numerals designate like
`structural clements, and in which:
`FIG. 1A showsa three-tier security model based on which
`the present invention is contemplated to operate according to
`) one embodimentthereof;
`FIG. 1B showsa data flow in accordance withthethree-tier
`securily model amongthree enlilies;
`FIG. 2 shows an exemplary architecture diagramaccording
`to one embodiment ofthe present invention;
`FIG. 3A a block diagramofrelated modules interacting
`with eachotherto achieve whatis referred to herein as e-purse
`2
`personalization by an authorized person as shown in ['IG.2;
`
`GOOG-1028
`Google LLC v. RFCyber Corp. / Page 11 of 15
`
`GOOG-1028
`Google LLC v. RFCyber Corp. / Page 11 of 15
`
`

`

`US 8,118,218 B2
`
`3
`FIG. 3B showsa block diagram of related modules inter-
`acting with each other to achieve whatis referred to herein as
`e-purse personalization by a user of the e-purse as shown in
`FIG. 2;
`FIG. 3C showsa flowchart or process of personalizing an
`e-purse according to one embodimentof the present inven-
`tion:
`FIG. 4A and FIG. 4B showtogether a flowchart or process
`offinancing, an e-purse according to one embodiment ofthe
`present invention; and
`FIG. 4C shows an exemplary block diagram of related
`blocks interacting with each other to achieve the process FIG.
`4A.
`
`
`
`DETAILED DESCRIPTION OF THE INVENTION
`
`
`
`
`36
`
`35
`
`
`
`4
`in order to secure the message channel betweenthe purse and
`the SAM or backendservers. For a single functional card, the
`e-purse security 104 will act as gates to protect actual opera-
`tions performed ona single functional card. During person-
`alization, the single functional card access keys(or its trans-
`formation) are personalized into the purse with the purse
`transaction keys.
`Card ManagerSecurity 106, referring to a general security
`framework of a preload operating system in a smart card,
`provides a platform for PIN management and security chan-
`nels (security domains) for card personalization. This plat-
`form via a card managercan be used to personalize a purse in
`one embodiment. One example of the card managersecurity
`106 is what is referred to as a Global Platform (GP) thatis
`created by a cross-industry membership organization to
`advancestandards for smart card growth. A GP combines the
`interests of smart card issuers, vendors, industry groups, pub-
`lic entities and technology companiesto define requirements
`and technology standards for multiple application smart
`cards. In one embodiment, a global platform security is used
`to personalize a smart card. As a result, both c-purse keys and
`card access keys are personalized into thetarget tag.
`FIG. 1B showsa data flow in accordance withthe three-tier
`security model amongthree entities a land-based SAM or a
`network e-purse server 112, e-purse 114 acting as a gate
`keeper, and a single function lag 116. According to one
`embodiment of the present
`invention, communications
`betweenthe land-based SAM orthe network e-purse server
`112 and the e-purse 114 are conducted in sequence of a type
`of commands(e.g.,APDU) while communications between
`the e-purse 114 andthe single function tag 116 are conducted
`in sequence of another type of commands, wherein the
`e-purse 114 acts as the gate keeper to ensure only secured and
`authorized data transactions could happen.
`In reference to FIG. 1A,the physical securityis realized in
`an emulator. As used herein, an emulator means a hardware
`device or a program that pretends to be another particular
`device or program that other components expect lo interact
`with. The e-purse securily is realized between one or more
`applets configured to provide e-purse functioning and a pay-
`mentserver. ‘he card managersecurity (e.g., global platform
`security) is realized via a card manager to update security
`keys to establish appropriate channels for
`interactions
`between the server and the applets, wherein the e-purse
`applet(s) acts as a gatekeeper to regulate or control the data
`exchange.
`According to one embodiment, a smart card has a pre-
`loaded smart card operation system that provides security
`framework to control the access to the smart card (e.g., an
`installation of external applications into the smart card). In
`order to manage the life cycle of an external application, a
`card manager module is configured by using the smart card
`security framework. For instance, a Java based smart card,
`SmartMX,is preloaded with an operating system JCOP4.1.
`The Global Platform 2.1 installed on the SmartMX performs
`the card managerfunctionality.
`Referring now to FIG. 2, there shows an exemplary archi-
`tecture diagram 200 according to one embodiment of the
`present invention. The diagram 200 includes a cellphone 202
`embedded with a smart card module. An example of such a
`cell phone is a near field communication (NFC) enabled
`cellphone that includes a Smarl MX (SMX) module. The
`SMX is pre-loaded with a Mifare emulator 208 (which is a
`single functional card) for storing values. The cellphoneis
`equipped with a RFID interface (e.g., ISO 144443) that
`allowsthe cellphoneto act as a tag. In addition, the SMX is a
`JavaCard that can run Java applets. According to one embodi-
`
`45
`
`50
`
`55
`
`60
`
`65
`
`In the following description, numerousspecific details are
`set forth to provide a thorough understanding of the present
`invention. The present invention may be practiced without
`n> D
`these specific details. The description and representation 2
`herein are the means used bythose experienced or skilled in
`the art to effectively convey the substance of their work to
`others skilled in the art. In other instances, well-known meth-
`ods, procedures, components, and circuitry have not been
`described in detail since theyare already well understood and :
`to avoid unnecessarily obscuring aspects of the present inven-
`tion.
`Reference herein to “one embodiment” or “an embodi-
`ment” meansthat a particular feature, structure, or character-
`istic described in connection with the embodiment can be
`includedin at least one implementation ofthe invention. The
`appearances of the phrase “in one embodiment” in various
`places in the specification are not necessarily all referring to
`the same embodiment,nor are separate oralternative embodi-
`ments mutually exclusive of other embodiments. Further,the
`order of blocks in process, flowcharts or functional diagrams
`representing one or more embodiments do not inherently
`indicate any particular order nor imply limitations in the
`invention.
`Embodimentsofthe present invention are discussed herein
`with reference to FIGS. 1A-4C. However, those skilled in the
`art will readily appreciate that the detailed description given
`herein with respect to these figures is for explanatory pur-
`poses only as the invention extends beyond these limited
`embodiments.
`FIG. 1A showsa three-tier security model 100 based on
`which the present
`invention is contemplated to operate
`according to one embodimentthereof. The three-tier security
`model 100 includes physical security 102, e-purse security
`104 and card managersecurity 106.
`Physical securily 102 refers to a security mechanism pro-
`vided by a single functional card to protect data stored on the
`card. ‘he card may be hardware implemented or software
`emulated running on a type of media. Data on a single func-
`tion card is protected by a set of access keys. These keys are
`configured onto the card when the card is issued. To avoid
`obscuring aspectsofthe present invention, the process ofhow
`the keys are configured onto the cards is to be omitted. For
`accessing the data, related keys are delivered to a reader for
`authentication.
`
`E-purse security 104 defines a set of protocols that enable
`micro paymenttransactions to be carried out in both wired
`and wireless environments. With anelectronic purse (a.k.a.,
`e-purse) stored on a smart card, a set ofkeys (either symmet-
`ric or asymmetric) is personalized into the purse when the
`purse is being issued. During a transaction, the purse uses a
`set of respective keys for encryption and MACcomputation
`
`40
`
`GOOG-1028
`Google LLC v. RFCyber Corp. / Page 12 of 15
`
`GOOG-1028
`Google LLC v. RFCyber Corp. / Page 12 of 15
`
`

`

`US 8,118,218 B2
`
`5
`ment, an e-purse is built on top of the global platform and
`implementedas an applet in SMX. The e-purseis configured
`to be able to access the Mifare data structures with appropri-
`ate transformed passwords based onthe access keys.
`In the cellphone 202, a purse manager midlet 204 is pro-
`vided. For M-commerce, the midlet 204 acts as an agent to
`facilitate communications between an e-purse applet 206 and
`one or more payment network and servers 210 to conduct
`transactions therebetween. As used herein, a midletis a soft-
`ware component suitable for being executed on a portable
`device. The purse manager midlet 204 is implemented as a
`“midlet” on a Java cellphone, or an “executable application”
`ona PDA device. Oneofthe functions this software compo-
`nent provides is to connect to a wireless network and com-
`municate with an e-purse applet whichcan reside on eitherthe
`same device or an external smart card. Inaddition, it is con-
`figured to provide administrative functions such as changing
`a PIN, viewing a purse balance and a history log. In one
`application in which a card issuer provides a SA module 212
`n> D
`that
`is used to enable and authenticate any transactions 2
`between a card and a correspondingserver(also referred to as
`a payment server). As shown in FIG. 2, APDU commandsare
`constructed by the servers 210 having access to aSA module
`212, where the APDUstands for Application Protocol Data
`Unit that isa communication unit between a reader andacard.
`The structure of an APDUis defined by the ISO 7816 stan-
`dards. Typically, anAPDU commandis embedded in network
`messagesand delivered to the server 210 or the e-purse applet
`206 for processing.
`Tor e-commerce, a web agent 214 on a computing device
`(not shown)is responsible for interacting with a RI'ID reader
`and the network server 210. In operation, the agent 214 sends
`the APDU commandsorreccives responses thereto through
`the RFID reader 216 to/from the e-purse applet 206 residing
`in the cellphone 202. On the other hand, the agent 214 com-
`poses network requests
`(such as HTTP) and receives
`responses thereto from the paymentserver 210.
`To personalize the cellphone 202, FIG. 3A showsa block
`diagram 300 ofrelated modules interacting with eachother to
`achieve whatis referred to herein as e-purse personalization
`byanauthorized person as shown in FIG. 2. FIG. 3B shows a
`block diagram 320 of related modules interacting with each
`other to achieve what is referred to herein as e-purse person-
`alization bya user of the e-purse as shown in FIG.2.
`FIG. 3C showsa flowchart or process 350 of personalizing
`an e-purse according to one embodimentofthe present inven-
`tion. FIG. 3C is suggested to be understood in conjunction
`with FIG, 3A and FIG. 3B. The process 350 may be imple-
`mented in software, hardware or a combination of both.
`As described above, an e-purse is built on Lop of a global
`platform to provide a security mechanism necessary to per-
`sonalize applets designed therefor. In operation, a security
`domainis used for establishing a secured channel between a
`personalization application and the e-purse. According to one
`embodiment, the essential data to be personalized into the
`purse include one or more operation keys(c.g.. a load key and
`a purchase key), default PINs, administration keys (c.g., an
`unblock PIN key and a reload PIN key), and passwords (c.g.,
`from Mifare).
`Tt is assumedthat a user desires to personalize an e-purse
`embeddedin a device (e.g., a cellphone). At 352 of FIG. 3C,
`a personalization process is inilialed. Depending on imple-
`mentation, the personalization process may be implemented
`in a module inthe device and activated manuallyor automati-
`cally, or a physical process initiated by an authorized person
`(typically associated with a care issuer). As shown in FIG. 3A,
`an authorized personal initiates a personalization process 304
`
`:
`
`36
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`6
`to personalize the e-purse for a user thereof via new e-purse
`SA module 306 and an existing SA module 308 with the
`RFID reader 310 as the interface. The card manager 311
`performs at least two functions: 1. establishing a security
`channel, via a security domain, to install and personalize an
`external application (e.g., e-purse applet) in the card person-
`alization; and 2. creating security means (e.g., PINs) to pro-
`tect the application during subsequentoperations. As a result
`ofthe personalization process 304, the c-purse applet 312 and
`the emulator 314 are personalized.
`Similarly, as shownin FIG. 3B, a user ofan e-purse desires
`to initiate a personalization process to personalizethe e-purse
`wirelessly(e.g., via the m-commerce path of FIG.2). Differ-
`ent from FIG. 3A, FIG. 3B allows the personalization process
`to be activated manually or automatically. For example, there
`is a mechanismona cellphonethat, if pressed, activates the
`personalization process. Alternatively, a status of “non-per-
`sonalized” may promptto the userto start the personalization
`process. As described above, a midlet 322 in a device acts as
`an agentto facilitate the communication between a payment
`server 324 and the e-purse 312 as well as the emulator 314,
`wherein the payment server 324 has the access to the new
`e-purse SA module 306 and anexisting SA module 308. As a
`result of the personalization process, the e-purse applet 312
`and the emulator 314 are personalized.
`Referring nowback to FIG. 3C, afler the personalization
`process is started, in view of FIG. 3A, the RFID reader 310 is
`activated to read the tag ID andessential data from a card in
`the device at 354. With an application security domain (e.g.,
`a default security setting by a card issuer), a security channel
`is then established at 356 between a new e-purse SAM(e.g.,
`the SAM 306 of FIG. 3A) and an e-purse applet (e.g., the
`e-purse applet 312 of FIG. 3A) in the device.
`Each application security domain of a global platform
`includes three 3DES keys. For example:
`Keyl:
`404142434445464748494a4b4c4d4e4f
`Key2:
`404142434445464748494a4b4c4d4e4l
`Key3:
`404142434445464748494a4b4c4d4e4f
`A security domain is used to generate session keys for a
`secured session between twoentities, such as the card man-
`ager applet and a host application, in which case the host
`application may be cither a desktop personalization applica-
`tion or a networked personalization service provided by a
`backendserver.
`A default application domain can be installed by a card
`issuer and assigned to various application/service providers.
`Therespective application owner can changethe value of the
`key sets before the personalization process(orat the initial of
`the process). Then the application can use the newset to
`create a security channel for performing the personalization
`process.
`With the security channelis established using the applica-
`tion provider’s application security domain, the first sct of
`data can be personalized to the purse applet. The secondsct of
`data can also be personalized with the same channel, too.
`However, ifthe data are in separate SAM,then a new security
`channel with the same keyset (or different key sets) can be
`used to personalize the second set of data.
`Via the new purse SAM 306, a set ofe-purse operation keys
`and pins are generated for data transactions betweenthe new
`e-purse SAMandthe e-purse applet to essentially personalize
`the e-purse applet at 358.
`is then established at 360
`A second security channel
`between an existing SAM(e.g., the SAM 308 of PIG. 3A) and
`
`255/1/DES-ECB/
`
`255/2/DES-ECB/
`
`255/3/DES-ECB/
`
`
`
`GOOG-1028
`Google LLC v. RFCyber Corp. / Page 13 of 15
`
`GOOG-1028
`Google LLC v. RFCyber Corp. / Page 13 of 15
`
`

`

`US 8,118,218 B2
`
`2
`
`mB wu
`
`7
`the e-purse applet(e.g., the e-purse applet 312 of FIG. 3A) in
`the device. Al 362, a set of transformed keys is generated
`using the existing SAM andthe tag ID. The generated keys are
`stored in the emulator for subsequent data access authentica-
`tion. At 358, a set of MF passwords is generated using the
`existing SAM and the tag ID, then is stored into the e-purse
`applet for future data access authentication. After it is done,
`the e-purse including the e-purse applet and the correspond-
`ing emulatoris set to a state of “personalized”.
`FIG. 4A and FIG. 4B showtogethera flowchart or process
`400 of financing an e-purse according to one embodiment of
`the present invention. The process 400 is conducted via the
`m-commerce path of FIG. 2. To better understand the process
`400, FIG. 4C shows an exemplary block diagram 450 of
`related blocks interacting with each other to achieve the pro-
`cess 400. Depending onan actual application ofthe present
`invention, the process 400 may be implemented in software,
`hardware or a combinationof both.
`A useris assumed to have obtained a portable device(e.¢.,
`n> D
`a cellphone) that is configured to include an e-purse. The user 2
`desires to fund the e-purse from an accountassociated with a
`bank. At 402, the user enters a set of personal identification
`numbers (PIN). Assumingthe PIN is valid, a purse manger in
`the deviceis activated and initiates a request(also referred to
`Nea
`an OTA top off request) at 404. The midlet inthe device sends :
`a request to the e-purse applet al 406, which is illustrated in
`FIG. 4C where the e-purse manager midlet 434 communi-
`cates with the e-purse applet 436.
`At 408, the e-purse applet composesa response in respond-
`ing to the request from the midlet. Upon receiving the
`response, the midlet sends the response to a payment network
`and server over a wireless network. As shown in FIG. 4C, the
`c-purse manager midlict 434 communicates with the e-purse
`applet 436 for a response that is then sent to the payment
`network and server 440. At 410, the process 400 needs to
`verify the validity of the response.If the response can not be
`verified, the process 400 stops. Ifthe response can beverified,
`the process 400 moveslo 412 where a corresponding account
`ata bank is verified. If the account does exist. a fund transler
`requestis initiated. At 414, the bank receives the request and
`responds to the request by returning a response. In general,
`the messages exchanged between the payment network and
`server and. the bank are compliant with a network protocol
`(e.g., HTTP for the Internet).
`At 416, the response from the bank is transported to the
`payment network and server. The midlet strips and extracts
`the APDU commands from the response and forward the
`commandsthe e-purse at 418. The e-purse verifies the com-
`mands at 420 and, provided they are authorized, send the
`commandsto the emulator at 420 and, meanwhile updating a
`transaction log. At 422, a lickel is generated to formulate a
`response (e.g., in APDU format) for payment server. As a
`result, the payment server is updated with a successful status
`message for the midlet, where the APDU response1s retained
`for subsequent verification at 424.
`As shownin FIG. 4C, the payment network and server 440
`receives a response from the purse manager midlet 434 and
`verifies that the responseis from an authorized e-purseorigi-
`nally issued therefrom with a SAM module 444. After the
`response is verified, the payment network and server 440
`sends a request to the financing bank 442 with which the user
`432 is assumed to maintain an account. The bank will verily
`the request, authorize the r