USOO8448855B1
`
`(12) United States Patent
`Koh et al.
`
`(10) Patent No.:
`(45) Date of Patent:
`
`US 8.448,855 B1
`May 28, 2013
`
`(54) METHOD AND APPARATUS FOR FUNDING
`ANELECTRONIC PURSE
`(75) Inventors: Liang Seng Koh, Fremont, CA (US);
`Eig Cho, Mr. A. f
`an, Fremont,
`; Fuliang Cho,
`San Jose, CA (US)
`
`USPC ............... 235/380: 235/379; 705/64; 705/65;
`705/66; 705/67
`(58) Field of Classification Search
`USPC .......................................... 235/379,380, 492
`See application file for complete search history.
`References Cited
`
`(56)
`
`(73) Assignees: Rich House Global Technology Ltd.,
`Shenzhen (CN); RFCyber Corp.,
`Fremont, CA (US)
`
`(*) Notice:
`
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 0 days.
`21) Appl. No.: 13/400,038
`9
`TNO.
`Feb. 18, 2012
`(22) Filed
`1C
`9
`Related U.S. Application Data
`(63) Continuation of application No. 1 1/534,653, filed on
`Sep. 24, 2006
`p t. No. 8 11 8.218 swa- -s
`ep. Z4,
`, now Fal. No. 8, 11 S.Z. 18.
`(51) Int. Cl
`GoGo 20/00
`G06O20/36
`G06O20/38
`52) U.S. C
`(52) CPC
`
`(2012.01)
`(200 6. 01)
`(200601)
`s
`G06O20/367 (2013.01); G06O20/3672
`(2013.01); G06O20/3674 (2013.01); G06O
`20/38 (2013.01); G06O20/382 (2013.01)
`
`U.S. PATENT DOCUMENTS
`2002/0145632 A1* 10, 2002 Shmueli et al. ............... 345,835
`2003. O145205 A1* 7, 2003 Sarcanin ........
`T13,172
`2005/0222961 A1* 10, 2005 Stab et al.
`705/64
`2006/0171383 A1* 8/2006 Davydov .
`370,389
`* cited by examiner
`Primary Examiner — Thien M Le
`A
`E
`Christopher Stanford
`SSistant Examiner — StOoher Stanfor
`(74) Attorney, Agent, or Firm — Joe Zheng
`(57)
`ABSTRACT
`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.
`17 Claims, 9 Drawing Sheets
`
`
`
`444
`
`440
`Payment network
`and Servers
`
`442
`Financing
`Bank
`
`Case 6:21-cv-00916-ADA Document 18-2 Filed 12/02/21 Page 1 of 15
`
`Purse
`manager
`midlet
`
`
`
`436
`
`e-purse
`applet
`
`438 o
`
`

`

`U.S. Patent
`
`May 28, 2013
`
`Sheet 1 of 9
`
`US 8.448,855 B1
`
`V//,
`
`00||
`
`
`
`Case 6:21-cv-00916-ADA Document 18-2 Filed 12/02/21 Page 2 of 15
`
`
`
`
`
`70|| K??uno?S ?sund-E
`
`

`

`U.S. Patent
`
`May 28, 2013
`
`Sheet 2 of 9
`
`US 8.448,855 B1
`
`0 || ||
`
`?sund-E
`
`se s?oe
`
`pueT
`
`
`
`
`
`
`
`
`
`
`
`Case 6:21-cv-00916-ADA Document 18-2 Filed 12/02/21 Page 3 of 15
`
`

`

`U.S. Patent
`
`US 8.448,855 B1
`
`
`
`
`
`
`
`?InpOW
`
`ZOZ
`
`Case 6:21-cv-00916-ADA Document 18-2 Filed 12/02/21 Page 4 of 15
`
`

`

`U.S. Patent
`
`US 8.448,855 B1
`
`009
`
`
`
`
`
`Case 6:21-cv-00916-ADA Document 18-2 Filed 12/02/21 Page 5 of 15
`
`

`

`U.S. Patent
`
`May 28, 2013
`
`Sheet 5 Of 9
`
`US 8.448,855 B1
`
`OZ9
`
`
`
`r= = = = = = = = = = = = = = = = = = = = = = = = = = = =
`
`Case 6:21-cv-00916-ADA Document 18-2 Filed 12/02/21 Page 6 of 15
`
`?InpOWN
`
`-E WAÐN
`
`9SJne)
`
`\/S
`
`

`

`U.S. Patent
`
`May 28, 2013
`
`Sheet 6 of 9
`
`US 8.448,855 B1
`
`8
`
`09
`
`Z99
`
`
`
`CINE
`
`Case 6:21-cv-00916-ADA Document 18-2 Filed 12/02/21 Page 7 of 15
`
`

`

`U.S. Patent
`
`May 28, 2013
`
`Sheet 7 Of 9
`
`US 8.448,855 B1
`
`007
`
`Z || 7
`
`90
`
`
`
`
`
`
`
`Je6eueu esund e? SS300e O? NICH
`
`Case 6:21-cv-00916-ADA Document 18-2 Filed 12/02/21 Page 8 of 15
`
`

`

`U.S. Patent
`
`May 28, 2013
`
`Sheet 8 of 9
`
`US 8.448,855 B1
`
`
`
`Case 6:21-cv-00916-ADA Document 18-2 Filed 12/02/21 Page 9 of 15
`
`CINE
`
`

`

`U.S. Patent
`
`May 28, 2013
`
`Sheet 9 Of 9
`
`US 8.448,855 B1
`
`X?JOM) ºu quêuÁed
`
`SuÐAues pue
`
`
`
`Case 6:21-cv-00916-ADA Document 18-2 Filed 12/02/21 Page 10 of 15
`
`

`

`US 8,448,855 B1
`
`1.
`METHOD AND APPARATUS FOR FUNDING
`AN ELECTRONIC PURSE
`
`CROSS-REFERENCE TO RELATED
`APPLICATIONS
`
`This application is a continuation of U.S. patent applica
`tion Ser. No. 1 1/534,653, filedon Sep. 24, 2006, now U.S. Pat.
`No. 8,118,218.
`
`BACKGROUND
`
`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
`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.
`
`2
`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:
`FIG. 1A shows a three-tier security model based on which
`the present invention is contemplated to operate according to
`one embodiment thereof;
`
`10
`
`15
`
`25
`
`30
`
`35
`
`40
`
`45
`
`Case 6:21-cv-00916-ADA Document 18-2 Filed 12/02/21 Page 11 of 15
`
`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
`therein. The transactions may be conducted over a wired
`network or a wireless network.
`
`50
`
`55
`
`60
`
`65
`
`

`

`3
`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.
`
`DETAILED DESCRIPTION OF THE INVENTION
`
`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
`the keys are configured onto the cards is to be omitted. For
`accessing the data, related keys are delivered to a reader for
`authentication.
`
`Case 6:21-cv-00916-ADA Document 18-2 Filed 12/02/21 Page 12 of 15
`
`US 8,448,855 B1
`
`4
`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.
`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
`
`10
`
`15
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`

`

`US 8,448,855 B1
`
`5
`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
`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
`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
`a purchase key), default PINs, administration keys (e.g., an
`unblock PIN key and a reload PIN key), and passwords (e.g.,
`from Milfare).
`
`6
`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:
`Key 1:
`40414243444.5464748494.a4b4.c4.d4e4f
`Key2:
`40414243444.5464748494.a4b4.c4.d4e4f
`Key3:
`40414243444.5464748494.a4b4.c4.d4e4f
`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
`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
`
`255/1/DES-ECBf
`
`255/2/DES-ECBf
`
`255/3/DES-ECBf
`
`10
`
`15
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`Case 6:21-cv-00916-ADA Document 18-2 Filed 12/02/21 Page 13 of 15
`
`

`

`8
`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 pro
`cess of making purchasing over a network with the e-purse is
`Substantially similar to the process 400, accordingly no sepa
`rate discussion on the process of making purchasing is pro
`vided.
`The invention is preferably implemented by software, but
`can also be implemented in hardware or a combination of
`hardware and software. The invention can also be embodied
`as computer readable code on a computer readable medium.
`The computer readable medium is any data storage device
`that can store data which can thereafter be read by a computer
`system. Examples of the computer readable medium include
`read-only memory, random-access memory, CD-ROMs,
`DVDs, magnetic tape, optical data storage devices, and car
`rier waves. The computer readable medium can also be dis
`tributed over network-coupled computer systems so that the
`computer readable code is stored and executed in a distributed
`fashion.
`The present invention has been described in sufficient
`details with a certain degree of particularity. It is understood
`to those skilled in the art that the present disclosure of
`embodiments has been made by way of examples only and
`that numerous changes in the arrangement and combination
`of parts may be resorted without departing from the spirit and
`Scope of the invention as claimed. Accordingly, the scope of
`the present invention is defined by the appended claims rather
`than the foregoing description of embodiment.
`
`Case 6:21-cv-00916-ADA Document 18-2 Filed 12/02/21 Page 14 of 15
`
`45
`
`50
`
`60
`
`65
`
`We claim:
`1. A method for funding an e-purse, the method compris
`ing:
`receiving a PIN from a user of a portable device, wherein
`the portable device is a near field communication (NFC)
`enabled device that includes a card module:
`initiating a request from a midlet embedded in the portable
`device after the PIN is verified, wherein the midlet sends
`the request to an e-purse applet;
`causing the e-purse applet to compose a response to the
`request:
`sending the response by the e-purse applet over a wireless
`network to a server administrating the e-purse, the server
`configured to verify the response against an account in a
`financial institution across a network, a fund transfer
`request is initiated by the server to the financial institu
`tion when the response is successfully verified;
`receiving commands from the server in responding to the
`fund transfer request; and
`causing an emulator in the portable device to update a
`transaction log after an authenticity of the commands is
`verified by the e-purse applet wherein the e-purse in the
`portable device has been personalized by operations
`including:
`
`US 8,448,855 B1
`
`10
`
`15
`
`30
`
`35
`
`40
`
`25
`
`7
`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