`
`United States Patent
`(12)
`(10) Patent N0.:
`US 8,118,218 B2
`
`Koh et a].
`(45) Date of Patent:
`Feb. 21, 2012
`
`(54) METHOD AND APPARATUS FOR
`PROVIDING ELECTRONIC PURSE
`
`(5 6)
`
`References Cited
`U.S. PATENT DOCUMENTS
`
`
`(75)
`
`Inventors: Hang Seng Koh, Fremont, CA (US);
`Futong (jhna Milpitag CA ([13); I-Isin
`Pan Fremont CA (US) Fuliang Cho
`San Jose, CA (US)
`
`8/2003 Atsmon et a1,
`6,607,136 B1 *
`. ............... 235/492
`
`2002/0145632 A1 * 10/2002 Shinueli et a1.
`. 345/835
`2009/0313689 A1* 12/2009 Nystrom et a1,
`726/9
`FOREIGN PA'l'EN'l' DOCUMENTS
`“’0 2007068991 Al *
`6/2007
`
`WO
`
`(73) Assignees: Rich House Global Technology Ltd.,
`Shenzhen (CN); RFCyber Corp.,
`Fremont, CA (US)
`
`are cited by examiner
`
`.
`Primary Examiner 71111611 M. Le
`Assistant Examiner 7 Christopher Stanford
`
`( * ) Notice:
`
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U’S‘C’ 15403) by 1057 days.
`
`(2]) Appl- N05 115345653
`
`(22)
`
`Filed:
`
`Sep. 24, 2006
`
`(65)
`
`Prior Publication Data
`
`I
`US 2008’ 0073426 A1
`
`Mar. 27’ 2008
`
`(51)
`
`Int. C1.
`G06K 5/00
`(52) US. Cl.
`
`(2006.01)
`235/380; 235/451; 235/492; 705/26;
`705/39: 705/40; 705/41; 705/64
`(58) Ficld 0f Classification Search
`23 5/379
`235/380, 492
`See application file for complete search history.
`
`(74) Attorney, 4489714 07' Firm * Joe Zheng
`(57)
`ABSTRACT
`Techniques for portable devices ftmctioning 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 manager is configuredto manage various transactions
`and functions as a mechanism to access an emulator therein.
`The transactions may be conducted over a wired network or a
`wireless network. A three-tier security model is contemplated
`to support the security of the transactions from the e-purse.
`The three-tier security model includes a physical security, an
`e-purse security and § card manager 56.011110} 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
`
`212
`
`200
`
`Web agent
`14
`
`RFID reader
`
` Payment network
`
`and servers 210
`on PC 2
`
`Exrstlng hardware for
`
`
`land—based commerce
`
`(e.g., stores or
`
`
`transportation) in
`enclosed environment
`E-commerce
`
`
`
`
`
` l Contactless interface
`
`
`Single functional
` Smart car'd
`orotocol
`
`o rotocol
`l
`
`EePurse
`
`
`applet built on
`GP with
`access to MF
`nassword 206
`
`
`Cell phone Wllh
`202
`smart card
`module
`
`M-commerce
`
`
`
`Google LLC v. RFCyber Corp. / Page 1 of 15
`
`6006-1028
`
`GOOG-1028
`Google LLC v. RFCyber Corp. / Page 1 of 15
`
`PGR2022-00003
`Apple EX1028 Page 1
`
`
`
`U.S. Patent
`
`Feb. 21, 2012
`
`Sheet 1 019
`
`US 8,118,218 132
`
`FIG.1A
`
`100
`
`0
`
`>\4—:
`"C
`:5
`
`O G
`
`)
`(D
`L—
`
`G)
`U)
`(U
`
`C C
`
`104
`
`
`
`E-Pursesecurity
`
`102
`
`
`
`Physicalsecurity
`
`O 2 '
`
`C)5—
`
`CD
`
`
`
`Google LLC v. RFCyber Corp. / Page 2 of 15
`
`GOOG-1028
`
`GOOG-1028
`Google LLC v. RFCyber Corp. / Page 2 of 15
`
`PGR2022-00003
`Apple EX1028 Page 2
`
`
`
`2Bm
`
`29Imm:wt
`
`US. Patent
`
`b.n
`
`8,SU
`
`0:
`
`mo:Emmqoo
`
`
`n,.995918%.mesqm
`gm9mixa
`
`mmfimam“9mm“mmmoom
`
`
`
`Doa<”6mocmscmm
`
`
`
`359$E9525:2mvcmEEoo
`
`mm:0320:9on
`
`
`
`mmwcoSQ6mg
`
`N:
`
`ummmn
`
`6:3
`
`Lo_>_<m
`
`{95ng
`
`8590
`
`.638
`
`Google LLC v. RFCyber Corp. / Page 3 of 15
`
`GOOG-1028
`
`
`
`
`
`
`
`
`
`
`
`GOOG-1028
`Google LLC v. RFCyber Corp. / Page 3 of 15
`
`PGR2022-00003
`Apple EX1028 Page 3
`
`
`
`US. Patent
`
`2w.
`
`om
`
`:_Acosmtonumcmb
`
`
`
`L8.,995memczgxm
`
`
`
`2Lo38%$3oEM858250898-29.639aim
`
`
`
`F3NOn_:0SN29meccm
`
`
`
`
`
`EoEce_>co886:0moEEESM080E809:
`
`
`
`3835:wwmzomEoo"m_
`
`m58:8206:5Emu5:6
`
`
`
`60905Ewe"6865.w
`
`8,.5:,893=8muNOEa8,wowwow2026mm.vow.w.mH__>_9wmwoomBEEmBEBE,»ES,n5memcmEav“.
`
`2O9B939:Ghmwow98tchm.
`
`go:5365%85;c
`
`omSnTm.U.
`
`mW.
`
`oo5MH4OmM
`
`
`
`Emmanm>>{0E2EoExmm
`
`
`
`
`
`com
`
`
`
`N_\N_>_<w
`
`0:822
`
`$3;m_
`
`2508
`
`
`
`
`
`
`
`
`GOOG-1028
`Google LLC v. RFCyber Corp. / Page 4 of 15
`
`PGR2022-00003
`Apple EX1028 Page 4
`
`
`
`US. Patent
`
`F
`
`
`
`
`
`
`
`.mmomLoqwcmficozmflficoflmmmom$.51
`
`
`
`mégxm3m
`
`oom
`
`mom65.8.6.
`
`8Nco§<
`
`
`
`
`
`
`
`
`
`
`-m_>>mz
`
`93622N<w3,SEEco_Hmo__qq<<w
` _Rmmv.mmLoomomm"N5E_Qq<_GEE05m."mmSn_-m_mmmmmGnu:mua"59:9:960ummmm0:622
`
`
`2mm...w.GauSm.0E............................m.m,uumm_535:5_=CV..
`
`G5
`
`GOOG-1028
`Google LLC v. RFCyber Corp. / Page 5 of 15
`
`PGR2022-00003
`Apple EX1028 Page 5
`
`
`
`US. Patent
`
`n
`
`9:922
`
`c039
`
`<w
`
`omm922%.
`
`
`
`momLoawcmt.
`
`
`9m851mm66:2mauu5_ummrwm_%"memcmEEmu"
`m9058n,95{035:m.EmFSmQ
`mm0Ewmmm--------------------------Jm89"firm".w.wm.65szmmMuuuumN5#0591_mmmw.
`
`
`
`mm«aG6
`
`GOOG-1028
`Google LLC v. RFCyber Corp. / Page 6 of 15
`
`PGR2022-00003
`Apple EX1028 Page 6
`
`
`
`US. Patent
`
`Feb. 21, 2012
`
`Sheet 6 0f 9
`
`US 8,118,218 B2
`
`wmm_>_<m$59.,»Em:9:593mg95cammax85$on3:5529950
`
`83%9:E#9qu$59Gcmvcm
`
`
`
`
`
`
`
`
`
`omm69:203283w525.38BEmEou330mmcozmoiqmmm:
`
`83mm9:EExam0838cmEm_>_<m@23626:cmc0938
`
`
`
`0mm
`
`
`
`Nmmcoswwzmcofloa93E.
`
` ma28m559,,o.93atoRow.
`
`
`
`
`
`
`
`
`on.w‘l3m.__uoN__mcoem5_=B9%m2«28$9:How
`
`
`
` amova9:E5anmmsqécmucm_>_<wmEExm9::mmen
`
`Dzm
`
`
`
`
`
`n:9305can_>_<mmczmxmcmas855quH__>_99950
`
`
`
`
`
`own$565@503mcmfifimmEEmEouErgomm:ozmflaammm:
`
`
`
`
`
`83%9,::_5qu8:56cmucm_>_<.wgermtoamcmh952$cmc8258
`
`
`
`mwmn:mg9:ucm_>_<w9525m5m_>SESEmcm,693umELouacmz23950
`
`553:3or:Ucm_>_<mmcnflxw9:c0238
`
`.lOC.lebV.CFRv.CLLbg0OG
`
`82maooG
`51fO7egaPla.
`
`GOOG-1028
`Google LLC v. RFCyber Corp. / Page 7 of 15
`
`PGR2022-00003
`Apple EX1028 Page 7
`
`
`
`US. Patent
`
`Feb. 21, 2012
`
`Sheet 7 0f 9
`
`US 8,118,218 B2
`
`09»
`
`
`
`
`
`
`
`
`
`vow_o__m>922cm5%6:28mm_>60.39m.93::
`
`3».0E
`
`xcmg9:E0:8:0mem968m
`
`
`BEL?u:.xcmn
`
`
`
`oc_,_0mcoqwm2“$369w;Lflmcmb9.2m99:5UcmE388mcficoqmotoOm>+_._m>
`
`
`
`mo59.:or:B020qua$8980093$
`
`66%@9590B7,033..mwvcmm66:2
`
`EmmcmE0239:$8822E
`
`88qu9.:
`
`«VBE?
`
`.lOC.lebV.CFRv.CLLbg0OG
`
`82maooG
`51fO8egaPla.
`
`GOOG-1028
`Google LLC v. RFCyber Corp. / Page 8 of 15
`
`PGR2022-00003
`Apple EX1028 Page 8
`
`
`
`US. Patent
`
`mS
`
`Dan?cm$635.2HEBEEm596x0:a3:29.009GMmmv53mmE02389:0..$939{0259.mEm@30me
`
`sawBESEQ9:BmmvcmEEoomccmmUcm363553Den?9:moctms859m.
`
`
`
`
`m.w;859$m59E9:UcowUcmmucmEEoo301<UmhxmEx9566:2
`
`mm00IGWm».0Ew1C1,ozmw00V.mm
`{036:m.EcmvumnEw8:0qu0529:0“.
`mmmmmmE
`
`
`
`mBEm5.538%m@6556mCezmoctg9.25+8532m_mmcoqmm:3n_n_<9:LEEm66::L9mammme
`m2genommcmbm3685
`
`m.
`
`R
`
`G9
`
`
`
`GOOG-1028
`Google LLC v. RFCyber Corp. / Page 9 of 15
`
`PGR2022-00003
`Apple EX1028 Page 9
`
`
`
`US. Patent
`
`Feb. 21, 2012
`
`Sheet 9 0f 9
`
`US 8,118,218 B2
`
`N:0.3Sin
`
`
`mEocmcE_>_<w
`
`
`22022
`
`
`
`82maooG
`51fOo1egaPla.rOCrebyCFRv.CLLbg0OG
`
`GOOG-1028
`Google LLC v. RFCyber Corp. / Page 10 of 15
`
`PGR2022-00003
`Apple EX1028 Page 10
`
`
`
`US 8,118,218 B2
`
`1
`METHOD AND APPARATUS FOR
`PROVIDING ELECTRONIC PURSE
`
`BACKGROUND
`
`2
`tion with a payment server. 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 (e.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 method for providing an e—purse, the
`method comprises providing a portable device embedded
`with a smart card module prc-loadcd with an emulator, the
`portable device including a memory space loaded with a
`midlet that is configured to facilitate communication between
`an e—purse applet therein and a payment server over a wireless
`network, wherein the portable device further includes a con-
`tactless interface that facilitates conmrunication between the
`e—purse applet therein and the payment server, 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 payment server.
`According to another embodiment, the present invention is
`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 payment server, 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—commerce in FIG. 2) or via the agent on a PC over
`a wired network (E-eommercc in FIG. 2).
`Accordingly one of the objects ofthe present inventions is
`to provide a mechanism to be embedded indevices, especially
`portable devices, to function as an electronic purse (e—purse)
`to be able to conduct transactions over an open network with
`a payment server without compromising security.
`Other objects, features, and advantages of the present
`invention will become apparent upon examining the follow-
`ing detailed description of an embodiment thereof, taken in
`conjunction with the attached drawings.
`
`
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`The invention will be readily understood by the following
`detailed description in conjunction with the accompanying
`drawings, wherein like reference numerals designate like
`structural elements, and in which:
`FIG. 1A shows a three-tier security model based on which
`the present invention is contemplated to operate according to
`one embodiment thereof;
`FIG. 1B shows a data flow in accordance with the three-tier
`security model among three entities;
`FIG. 2 shows an exemplary architecture diagram according
`to one embodiment of the present invention;
`FIG. 3A a block diagram of related modules interacting
`with each other to achieve What is referred to herein as e-purse
`:
`personalization by an authorized person as shown in FIG. 2'
`
`10
`
`15
`
`
`
`1. Technical Field
`The present invention is generally related to commerce
`over networks. Particularly, the present invention is related to
`electronic purses that can be advantageously used in portable
`devices configured for both electronic conmlerce (aka,
`e-commerce) and mobile commerce (aka, m-commerce)
`2. Description of the Related Art
`Single functional cards have been successfu ly used in
`enclosed environments such as transportation systems. One
`example of such single functional cards is MIFARE that is 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.
`NHFARE is the perfect solution for applications like loyalty
`and vending cards, road tolling, city cards, access control and
`gaming.
`It is noticed that such enclosed systems are difficult to be
`expanded into other areas such as e-eommerce and m-com-
`merce because stored values and transaction information are '
`stored in data storage of each tag that is protected by a 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 difiicult to be expanded to an open environ—
`ment such as the lntemet for e—comrnerce 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.
`
`30
`
`35
`
`SUMMARY
`
`This section is for the purpose of summarizing some
`a spects ofembodiments ofthe present invention and to 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 invention is 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 c-pursc manager is configured to manage various trans-
`actions and functions as a mechanism to access an emulator
`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 and a card manager security, concentrically encapsulating
`one with another. Security keys (either symmetric or asym-
`metric) are personalized within the three-tier security model
`so as to personalize an e-purse and perform secured transac-
`
`4O
`
`45
`
`5O
`
`55
`
`60
`
`65
`
`GOOG-1028
`Google LLC v. RFCyber Corp. / Page 11 of 15
`
`GOOG-1028
`Google LLC v. RFCyber Corp. / Page 11 of 15
`
`PGR2022-00003
`Apple EX1028 Page 11
`
`
`
`US 8,118,218 B2
`
`3
`FIG. 3B shows a block diagram of related modules inter—
`acting with each other to achieve what is referred to herein as
`e—purse personalization by a user of the e—purse as shown in
`FIG. 2;
`FIG. 3C shows a flowchart or process of personalizing an
`e-purse according to one embodiment of the present inven-
`tion:
`FIG. 4A and FIG. 4B show together a flowchart or process
`of financing an e-purse according to one embodiment of the
`present invention; and
`FIG. 4C shows an exemplary block diagram of related
`blocks interacting with each other to achieve the process FIG.
`4A.
`
`
`
`D 4 TAIL A D D 4 SCRIPTION OF THE INVENTION
`
`
`10
`
`15
`
`4
`in order to secure the message channel between the purse and
`the SAM or backend servers. For a single functional card, the
`e-purse security 104 will act as gates to protect actual opera-
`tions performed on a 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 Manager Security 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 manager can be used to personalize a purse in
`one embodiment. One example of the card manager security
`106 is what is referred to as a Global Platform (GP) that is
`created by a cross-industry membership organization to
`advance standards for smart card growth. A GP combines the
`interests of smart card issuers, vendors, industry groups, pub-
`lic entities and technology companies to 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 e-purse keys and
`card access keys are personalized into the target tag.
`FIG. 1B shows a data flow in accordance with the three—tier
`security model among three entities a land—based SAM or a
`network e—purse server 112. e—purse 114 acting as a gate
`keeper, and a single function tag 116. According to one
`embodiment of the present
`invention, communications
`between the land-based SAM or the 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 and the single function tag 116 are conducted
`in sequence of another type of commands, wherein the
`c-purse 114 acts as the gate keeper to ensure only secured and
`authorized data transactions could happen.
`In reference to FIG. 1A, the physical security is 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 to interact
`with. The e-purse security is realized between one or more
`applets configured to provide e-purse functioning and a pay-
`ment server. The card manager security (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
`applct(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 JCOP 4.1.
`The Global Platform 2.1 installed on the Smarth/[X performs
`the card manager functionality.
`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 Smart MX (SMX) module. The
`SMX is pre—loaded with a Mifare emulator 208 (which is a
`single functional card) for storing values. The cellphone is
`equipped with a RFID interface (e.g., ISO 144443) that
`allows the cellphone to act as a tag. In addition, the SMX is a
`JavaCard that canrun Java applets. According to one embodi-
`
`
`
`
`
`In the following description, numerous specific details are
`set forth to provide a thorough Imderstanding of the present
`inven ion. The present invention may be practiced without
`these specific details. The description and representation
`herein are the means used by those 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 they are already well understood and '
`to avoid unnecessarily obscuring aspects of the present inven-
`tion.
`Reference herein to “one embodimen ” or “an embodi-
`ment” means that a particular feature, structure, or character-
`istic described in connection with the embodiment can be
`included in at lea st 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 or alternative embodi—
`ments mutually exclusive of other embodiments. Further, the
`orc er of blocks in process, flowcharts or functional diagrams
`representing one or more embodiments do not inherently
`incicate any particular order nor imply limitations in the
`invention.
`Embodiments ofthe 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 shows a three—tier security model 100 based on
`which the present
`invention is contemplated to operate
`according to one embodiment thereof. The three—tier security
`model 100 includes physical security 102, e-purse security
`104 and card manager security 106.
`Physical security 102 refers to a security mechanism pro-
`vided by a single functional card to protect data stored on the
`card. The 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 aspects ofthe 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 payment transactions to be carried out in both wired
`and wireless environments. With an electronic 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 IWAC computation
`
`30
`
`35
`
`4O
`
`45
`
`5O
`
`55
`
`60
`
`65
`
`GOOG-1028
`Google LLC v. RFCyber Corp. / Page 12 of 15
`
`GOOG-1028
`Google LLC v. RFCyber Corp. / Page 12 of 15
`
`PGR2022-00003
`Apple EX1028 Page 12
`
`
`
`US 8,118,218 B2
`
`5
`ment, an e—purse is built on top of the global platform and
`implemented as an applet in SMX. The e-purse is configured
`to be able to access the Mifare data structures with appropri-
`ate transformed passwords based on the 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 therebctwcen. As used herein, a midlet is 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”
`on a PDA device. One of the functions this software compo—
`nent provides is to connect to a wireless network and com-
`municate with an e-purse applet which can reside on either the
`same device or an external smart card. In addition, 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
`that
`is used to enable and authenticate any transactions
`between a card and a corresponding server (also referred to as
`a payment server). As shown in FIG. 2, APDU commands are
`constructed by the servers 210 having access to a SA module
`212, where the APDU stands for Application Protocol Data
`Unit that is a communication unit between a reader and a card.
`The structure of an APDU is defined by the ISO 7816 stan-
`dards. Typically, anAPDU command is embedded in network
`messages and delivered to the server 210 or the e-purse applet
`206 for processing.
`For e-commerce, a web agent 214 on a computing device
`(not shown) is responsible for interacting with a RFID reader
`and the network server 210. In operation, the agent 214 sends
`the APDU commands or receives 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 payment server 210.
`To personalize the cellphone 202, FIG. 3A shows a block
`diagram 3 00 ofrelated modules interacting with each other to
`achieve what is referred to herein as e-purse personalization
`by an authorized 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 by a user of the e-purse as shown in FIG. 2.
`FIG. 3C shows a flowchart or process 350 of personalizing
`an e—purse according to one embodiment ofthe 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 top of a global
`platform to provide a security mechanism necessary to per-
`sonalize applets designed therefor. In operation, a security
`domain is used for establishing a secured chamlel 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 (e.g., a load key and
`a purchase key), default PINS, administration keys (e.g., an
`unblock PIN key and a reload PIN key), and passwords (e.g.,
`from Mifare).
`It is assumed that a user desires to personalize an e—purse
`embedded in a device (e.g., a cellphone). At 352 of FIG. 3C,
`a personalization process is initiated. Depending on imple-
`mentation, the personalization process may be implemented
`in a module in the device and activated manually or 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
`
`10
`
`15
`
`'
`
`30
`
`35
`
`4O
`
`45
`
`50
`
`SS
`
`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
`chaimel, 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 subsequent operations. As a result
`ofthe personalization process 304, the e-purse applet 312 and
`the emulator 314 are personalized.
`Similarly, as shown in FIG. 3B, a user ofan e—purse desires
`to initiate a personalization process to personalize the 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 mechanism 011 a cellphone that, if pressed, activates the
`personalization process. Alternatively, a status of “non-per-
`sonalized” may prompt to the user to start the personalization
`process. As described above, a midlet 322 in a device acts as
`an agent to facilitate the communication between a payment
`server 324 and the e-pursc 312 as well as the emulator 314,
`wherein the payment server 324 has the access to the new
`e—purse SA module 306 and an existing SA module 308. As a
`result of the personalization process, the e—purse applet 312
`and the emulator 314 are personalized.
`Referring now back to FIG. 3C, after the personalization
`process is started, in View of FIG. 3A, the RFID reader 310 is
`activated to read the tag ID and essential 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
`c-purse applet 312 of FIG. 3A) in he device.
`Each application security domain of a global platform
`includes three 3DES keys. For example:
`Keyl:
`404142434445464748494a4b4c4c 4e4f
`Key2:
`404142434445464748494a4b4c4c 4e4f
`KeyS:
`404142434445464748494a4b4c4c 4e4f
`A security domain is used to generate session keys for a
`secured session between two entities, such as the card man-
`ager applet and a host application, in which case the host
`application may be either a deskto 3 personalization applica-
`tion or a networked personalization service provided by a
`backend server.
`A default application domain can be installed by a card
`issuer and assigned to various app ication/service providers.
`The respective application owner can change the value of the
`key sets before the personalization process (or at the initial of
`the process). Then the application can use the new set to
`create a security chamiel for performing the personalization
`process.
`With the security channel is established using the applica-
`tion provider’s application security domain, the first set of
`data can be personalized to the purse applet. The second set of
`data can also be personalized with the same channel, too.
`However, ifthe data are in separate SAM, then a new security
`chaimel with the same key set (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 between the new
`e-purse SAM and the 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 FIG. 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
`
`PGR2022-00003
`Apple EX1028 Page 13
`
`
`
`US 8,118,218 B2
`
`10
`
`15
`
`30
`
`35
`
`4O
`
`7
`the e—purse applet (e.g., the e—purse applet 312 of FIG. 3A) in
`the device. At 362, a set of transformed keys is generated
`using the existing, SAM and the 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 emulator is set to a state of “personalized”.
`FIG. 4A and FIG. 4B show together a 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 on an actual application of the present
`invention, the process 400 may be implemented in software,
`hardware or a combination of both.
`A user is assumed to have obtained a portable device (e.g.,
`a cellphone) that is configured to include an e-purse. The user
`desires to fund the e-purse from an account associated with a
`bank. At 402, the user enters a set of personal identification
`numbers (PIN). Assuming the PIN is valid, a purse manger in
`the device is activated and initiates a request (also referred to
`an OTA top off request) at 404. The midlet in the device sends '
`a request to the e-purse applet at 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 composes a 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
`e-purse manager midlet 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 be verified,
`the process 400 moves to 412 where a corresponding account
`at a bank is verified. If the account does exist, a fund transfer
`request is 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
`commands the e—purse at 418. The e—purse verifies the com—
`mands at 420 and, provided they are authorized, send the
`commands to the emulator at 420 and, meanwhile updating a
`transaction log. At 422, a ticket is generated to formulate a
`response (e.g., in APDU fonnat) for payment server. As a
`result, the payment server is updated with a successful status
`message for the midlet, where the APDU response is retained
`for subsequent verification at 424.
`As shown in FIG. 4C, the payment network and server 440
`receives a response from the purse manager midlet 434 and
`verifies that the response is from an authorized e-purse origi-
`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 verify
`the request, authorize the request and return an authorization
`number in some pre-arranged message format. Upon receiv-
`ing the response from ban