`
`(12) United States Patent
`Koh et al.
`
`(10) Patent No.:
`(45) Date of Patent:
`
`US 9,189,787 B1
`Nov. 17, 2015
`
`(54)
`
`(71)
`
`(72)
`
`(73)
`
`(*)
`
`(21)
`(22)
`
`(63)
`
`METHOD AND APPARATUS FOR
`CONDUCTING E-COMMENCE AND
`M-COMMENCE
`
`Applicant: RFCyber Corporation, Fremont, CA
`(US)
`Inventors: Liang Seng Koh, Fremont, CA (US);
`Futong Cho, Milpitas, CA (US); Hsin
`Pan, Fremont, CA (US); Fuliang Cho,
`San Jose, CA (US)
`Assignees: Rich House Global Technology Ltd.,
`Shenzhen (CN); RFCyber Corp.,
`Fremont, CA (US)
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 24 days.
`Appl. No.: 13/903,420
`Filed:
`May 28, 2013
`
`Notice:
`
`Related U.S. Application Data
`Continuation of application No. 13/400,038, filed on
`Feb. 18, 2012, now Pat. No. 8,448,855, which is a
`continuation of application No. 1 1/534,653, filed on
`Sep. 24, 2006, now Pat. No. 8,118.218.
`
`(51)
`
`Int. C.
`G06O20/00
`G06O20/36
`
`(2012.01)
`(2012.01)
`
`(52) U.S. Cl.
`CPC .................................. G06O20/3672 (2013.01)
`(58) Field of Classification Search
`CPC ..... G06Q 20/04: G06Q 20/12: G06Q 20/341;
`G06Q 20/32: G06Q 20/382; G06Q 20/3672
`USPC ..................... 235/451, 492: 340/572.1,572.3
`See application file for complete search history.
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`6,031,912 A * 2/2000 Moulart et al. ................. 380, 44
`2005/0222961 A1* 10/2005 Staib et al. ...................... TO5.64
`* cited by examiner
`Primary Examiner — Christopher Stanford
`(74) Attorney, Agent, or Firm — Wuxi Sino IP Agency, Ltd.;
`Joe Zheng
`
`ABSTRACT
`(57)
`Techniques for funding an electronic purse (e-purse) are dis
`closed. According to one aspect of the invention, a mecha
`nism is provided to enable a portable device to conduct trans
`actions 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
`configured to manage various transactions and functions as a
`mechanism to access an e-purse therein. The e-purse is
`funded by interactions among the e-purse manager, a pay
`ment server and a financial institution (its server) that main
`tains an account therefor.
`
`19 Claims, 9 Drawing Sheets
`
`START
`
`Initiate personalization -- 352
`
`Read off a tag ID from the card N-354
`w
`Use application security domain to establish a security channel
`between an new e-purse SAM and an e-purse applet in the device
`
`350
`
`356
`
`s
`Generate e-purse operation keys and pins between the new e-purse SAM
`--- 358
`and an e-purse applet in the device
`
`----- 360
`Use application security domain to establish a security channel
`between an existing transportation SAM and an e-purse applet in the device
`
`Generate transformed keys of an emulator via the existing SAM and the tag ID
`between the existing SAM and the emulator
`
`362
`
`w
`Generate MF passwords via an existing SAM and the tag ID
`between the existing SAM and an e-purse applet in the device
`
`--- 364
`
`Set the e-purse to a state of "personalized"
`
`368
`
`
`
`GOOG-1001
`GOOGLE LLC v. RFCYBER CORP. / Page 1 of 15
`
`
`
`U.S. Patent
`US. Patent
`
`Nov. 17, 2015
`
`Sheet 1 019
`
`US 9,189,787 B1
`US 9,189,787 B1
`
`FIG.1A
`
`102
`
`
`
`Physicalsecurity
`
`104
`
`
`
`E-Pursesecurity
`
`GOOGLE LLC V. RFCYBER CORP. / Page 2 of 15
`
`GOOG-lOOl
`
`>4—:
`"C
`:5
`
`OG
`
`)
`(I)
`
`00||
`100
`
`
`
`0
`
`L 0
`
`)
`CD
`(U
`
`C(
`
`U E'
`
`CL
`(U
`
`GOOG-1001
`GOOGLE LLC v. RFCYBER CORP. / Page 2 of 15
`
`
`
`U.S. Patent
`U.S. Patent
`
`NOV. 17, 2015
`
`Sheet 2 of 9
`
`US 9,189,787 B1
`US 9,189,787 B1
`
`0520
`
`m:
`
`0mm“
`
`ms.OE
`
`0 || ||
`
`o:
`
`065m0So0xm.
`0050M.
`
`cozoce
`
`cozoce00300
`
`
`
`0000000000900:0EE8
`
`Er
`
`L0Q00x
`
`0000
`
`
`
`
`
`Don_<”600:0:00m
`
`
`
`00500E0E0_QE_900:0EEoo
`
`
`
`0050300829000
`
`
`
`0005050.002
`
`NS
`
`00009
`
`0:04
`
`.6_>_<m
`
`£050:
`
`0050-0
`
`0300
`
`GOOGLE LLC V. RFCYBER CORP. / Page 3 of 15
`
`GOOG- 1 001
`
`GOOG-1001
`GOOGLE LLC v. RFCYBER CORP. / Page 3 of 15
`
`
`
`
`
`
`
`
`
`U.S. Patent
`
`US 9,189,787 B1
`
`00Z
`
`
`
`
`
`
`
`ZOZ
`
`GOOG-1001
`GOOGLE LLC v. RFCYBER CORP. / Page 4 of 15
`
`
`
`U.S. Patent
`U.S. Patent
`
`5
`
`US 9,189,787 B1
`1B70079a
`
`
`
` m0:6222,<m2282U:95Cezmozaad‘<mw.momL8938:35:85;85N855-m262
`
`
`
`m.w,Sm.OE............................Uminmm56380mmm58$.
`9"N5669*_mix05M"0231M.m4uuauumm:mgommcmE9.8m
`
`009
`oom
`
`85552
`
`6:820.
`
`
`
`
`
`GOOGLE LLC V. RFCYBER CORP. / Page 5 of 15
`
`GOOG- 1 001
`
`GOOG-1001
`GOOGLE LLC v. RFCYBER CORP. / Page 5 of 15
`
`
`
`U.S. Patent
`
`Nov. 17, 2015
`
`Sheet 5 Of 9
`
`US 9,189,787 B1
`
`9
`
`r= = = = = = = = = = = = = = = = = = = = = = = = = = = =
`
`OZ9
`
`
`
`?InpOWN?InpOWN
`
`GOOG-1001
`GOOGLE LLC v. RFCYBER CORP. / Page 6 of 15
`
`
`
`U.S. Patent
`
`Nov. 17, 2015
`
`Sheet 6 of 9
`
`US 9,189,787 B1
`
`899
`
`0
`99
`
`Z99
`
`
`
`CINE
`
`GOOG-1001
`GOOGLE LLC v. RFCYBER CORP. / Page 7 of 15
`
`
`
`U.S. Patent
`U.S. Patent
`
`N
`
`m7,
`
`7m.h
`
`US 9,189,787 B1
`1B787,
`9,
`
`007
`00%
`
`mmBE?0080quwe.
`
`1LommcmEmqu9:$8892EW.wow
`_o__m>mccficoEtc66::mm_>6289a39:5
`
`H63%093-0950:59a$5856:2
`
`Swow66::m59mmcoammga3.8980mqum
`
`
`
`
`
`
`
`9ImS»GE
`
`mxcmg05So:096qum968m
`
`
`
`
`
`8:29t1choccogoqwm950:69N;55%:3:2m.99:5ucmEsooommgucoamwtoomb_._w>
`
`GOOGLE LLC V. RFCYBER CORP. / Page 8 of 15
`
`GOOG- 1 001
`
`GOOG-1001
`GOOGLE LLC v. RFCYBER CORP. / Page 8 of 15
`
`
`
`U.S. Patent
`
`US 9,189,787 B1
`
`
`
`CINE
`
`GOOG-1001
`GOOGLE LLC v. RFCYBER CORP. / Page 9 of 15
`
`
`
`U.S. Patent
`U.S. Patent
`
`5102n,
`
`ehS
`
`9f09
`
`US 9,189,787 B1
`1B70079900
`1.}9S
`
`UUV.muF‘
`
`a583:5
`
`851
`
`
`
`v.xcmm2058UcmMmEocmcE€050:€083; 5:28
` 0:622
`
`N:03vvv
`
`
`
`_>_<m
`
`GOOGLE LLC V. RFCYBER CORP. / Page 10 of 15
`
`GOOG- 1 001
`
`GOOG-1001
`GOOGLE LLC v. RFCYBER CORP. / Page 10 of 15
`
`
`
`US 9,189,787 B1
`
`1.
`METHOD AND APPARATUS FOR
`CONDUCTING E-COMMENCE AND
`M-COMMENCE
`
`CROSS-REFERENCE TO RELATED
`APPLICATIONS
`
`This application is a continuation of U.S. patent applica
`tion Ser. No. 13/400,038, filed on Feb. 18, 2012, now U.S. Pat.
`No. 8,448,855, which is a continuation of U.S. patent appli
`cation Ser. No. 1 1/534,653, filed on Sep. 24, 2006, now U.S.
`Pat. No. 8,118,218.
`
`BACKGROUND
`
`10
`
`15
`
`25
`
`30
`
`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 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 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.
`MIFARE 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-commerce and m-com
`merce because stored values and transaction information are
`35
`stored in data storage of each tag that is protected by a set of
`keys. The nature of the 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.
`
`40
`
`45
`
`SUMMARY
`
`This section is for the purpose of Summarizing some
`aspects of embodiments of the 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 e-purse manager is configured to manage various trans
`actions and functions as a mechanism to access an emulator
`
`50
`
`55
`
`60
`
`65
`
`2
`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
`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 Milfare). 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 pre-loaded 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 communication 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-commerce in FIG. 2).
`Accordingly one of the objects of the present inventions is
`to provide a mechanism to 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 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:
`
`GOOG-1001
`GOOGLE LLC v. RFCYBER CORP. / Page 11 of 15
`
`
`
`3
`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 hereinase-purse
`personalization by an authorized person as shown in FIG. 2;
`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.
`
`10
`
`15
`
`DETAILED DESCRIPTION OF THE INVENTION
`
`25
`
`In the following description, numerous specific details are
`set forth to provide a thorough understanding of the present
`invention. 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 embodiment' or “an embodi
`ment’ means that a particular feature, structure, or character
`istic described in connection with the embodiment can be
`included in at least one implementation of the 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
`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.
`Embodiments of the 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 of the present invention, the process of how
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`US 9,189,787 B1
`
`4
`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 of keys (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 MAC computation
`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 a
`cross-industry membership organization created to advance
`standards for smart card growth. A GP combines the interests
`of smart card issuers, vendors, industry groups, public entities
`and technology companies to define requirements and tech
`nology 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 inaccordance 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
`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 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 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 operating 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 SmartMX performs
`the card manager functionality.
`
`GOOG-1001
`GOOGLE LLC v. RFCYBER CORP. / Page 12 of 15
`
`
`
`US 9,189,787 B1
`
`10
`
`15
`
`5
`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 Milfare 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 can run Java applets. According to one embodi
`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 Milfare 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 therebetween. 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
`25
`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 an 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 an 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, an APDU 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
`45
`in the cellphone 202. On the other hand, the agent 214 com
`poses network requests (e.g., an HTTP request) and receives
`responses thereto from the payment server 210.
`To personalize the cellphone 202, FIG. 3A shows a block
`diagram 300 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. 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 of the 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 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 (e.g., a load key and
`
`55
`
`6
`a purchase key), default PINs, administration keys (e.g., an
`unblock PIN key and a reload PIN key), and passwords (e.g.,
`from Milfare).
`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
`to personalize the e-purse for a user thereof via an existing
`new e-purse SA module 306 and a 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 Subsequent operations. As a result
`of the personalization process 304, the e-purse applet 312 and
`the emulator 314 are personalized.
`Similarly, as shown in FIG. 3B, a user of an 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 on 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-purse 312 as well as the emulator 314,
`wherein the payment server 324 has the access to the existing
`new e-purse SA module 306 and an 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
`e-purse applet 312 of FIG. 3A) in the device.
`Each application security domain of a global platform
`includes three 3DES keys. For example:
`255/1/DES-ECBf
`Key 1:
`40414243444.5464748494.a4b4c4.d4e4f
`Key2:
`255/2/DES-ECBf
`40414243444.5464748494.a4b4c4.d4e4f
`Key3:
`255/3/DES-ECBf
`40414243444.5464748494.a4b4c4.d4e4f
`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 desktop 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 application/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 channel for performing the personalization
`process.
`With the security channel is established using the applica
`tion provider's application security domain, the first set of
`
`30
`
`35
`
`40
`
`50
`
`60
`
`65
`
`GOOG-1001
`GOOGLE LLC v. RFCYBER CORP. / Page 13 of 15
`
`
`
`10
`
`15
`
`25
`
`30
`
`35
`
`40
`
`7
`data can be personalized to the purse applet. The second set of
`data can also be personalized with the same channel, too.
`However, if the data are in separate SAM, then a new security
`channel with the same key set (or different key sets) can be
`used to personalize the second set of data.
`Via the new purse SAM306, a set of e-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.
`A second security channel is then established at 360
`between an existing SAM (e.g., the SAM308 of FIG.3A) and
`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 offrequest) 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. If the 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 forwards the
`commands the e-purse at 418. The e-purse verifies the com
`60
`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 format) 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.
`
`45
`
`US 9,189,787 B1
`
`8
`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 bank, the server 440 will either reject
`the request or form a network response to be sent to the midlet
`434.
`The e-purse verifies the authenticity (e.g., in APDU for
`mat) and sends commands to the emulator 438 and updates
`the transaction logs. By now, the e-purse finishes the neces
`sary steps and returns a response to the midlet 434 that for
`wards an (APDU) response in a network request to the pay
`ment server 440.
`Although the process 400 is described as funding the
`e-purse. Those skilled in the art can appreciate that the pr