Case 6:22-cv-00697-ADA Document 41-5 Filed 08/21/23 Page 1 of 13
`Case 6:22-cv-00697-ADA Document 41-5 Filed 08/21/23 Page 1 of 13
`
`
`
`
`EXHIBIT 3
`EXHIBIT 3
`
`

`

`Case 6:22-cv-00697-ADA Document 41-5 Filed 08/21/23 Page 2 of 13
`
`IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`Liang Seng Koh et al
`Applicant(s):
`Method and apparatus for providing electronic purse
`Title:
`11/534,653
`Serial No.:
`Confirmation No.: 6327
`Filing Date:
`09/24/2006
`Examiner:
`Chris Stanford
`2887
`Group Art Unit:
`RFID-081
`Docket No:
`
`September 7, 2011
`
`Mail Stop: No-Fee Amendments
`Commissioner for Patents
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`Response to 1st OA (RCE)
`
`In response to Office Action dated 05/25/2011, the Applicant respectfully
`requests the Examiner to enter the following amendments before reconsidering the
`above-referenced application:
`
`AMENDMENTS TO THE CLAIMS are reflected in the listing of claims which
`begins on page 2 of this Response.
`
`REMARKS/ARGUMENTS begin on page 7 of this Response.
`
`Page 1 of 12
`
`RFC00001013
`
`

`

`Case 6:22-cv-00697-ADA Document 41-5 Filed 08/21/23 Page 3 of 13
`
`AMENDMENTS TO THE CLAIMS
`
`Please amend Claims 1 and 11 as follows:
`
`1. (Currently amended) A method for providing an e-purse, the method comprising:
`providing a portable device including or communicating with a smart card niodue
`pre-loaded with an emulator configured to execute a request from an e-purse
`applet and rovide_ resp nsethee-purse_applet is confi fredt s_expe °t, the
`portable device including a memory space loaded with a midlet that is configured
`to facilitate communication between
`-thee-purse applet and a payment server
`over a wireless network, wherein t-he_e-curse_@pE)iet is_do-v nioaded_-arid__irlstaiie-d
`t o-n with the payment
`irt_the_ smart _card _ ter the_-mart_c-art__is__ r,_eom
`€nic
`server the portable device further includes a contactless interface that facilitates
`communication between the e-purse applet theron in the smart card and the
`payment server over a wired network;
`personalizing the e-purse applet by reading off data from the smart card to generate
`in the smart_ card_ one or more operation keys that are subsequently used to
`establish a secured channel between the e-purse applet and an e-purse security
`authentication module (SAM) external to the smart card, wherein said
`personalizing the e-purse applet comprises:
`establishing an initial security channel between the smart card and the e-
`purse SAM to install and personalize the e-purse applet in the smart card,
`and
`creating a security channel on top of the initial security channel to protect
`subsequent operations of the smart card with the e-purse SAM, wherein
`any subsequent operation of the emulator is conducted over the security
`channel via the e-purse applet.
`
`2. (Original) The method as recited in claim 1, wherein the operation keys include one
`or more of a load key and a purchase key, default personal identification numbers
`(PINs), administration keys, and passwords.
`
`Page 2 of 12
`
`RFC00001014
`
`

`

`Case 6:22-cv-00697-ADA Document 41-5 Filed 08/21/23 Page 4 of 13
`
`3. (Previously amended) The method as recited in claim 2, wherein at least some of
`the operation keys are used to establish a first secured channel so that various data
`is exchanged between the e-purse applet and the payment server, and at least
`another some of the operation keys are used to establish a second secured channel
`so that various data is exchanged between the e-purse applet and the e-purse SAM
`originally used to issue the e-purse as well as between the emulator and the existing
`SAM.
`
`4. (Original) The method as recited in claim 2, wherein said personalizing the e-purse
`applet is done over a wireless network or a wired network.
`
`5. (Original) The method as recited in claim 4, wherein, when said personalizing the e-
`purse applet is done over a wireless network, the midlet in the portable device is
`configured to facilitate communications between the e-purse and the payment
`server.
`
`6. (Original) The method as recited in claim 5, wherein both of the e-purse applet and
`the emulator are personalized as a result of said personalizing the e-purse applet.
`
`7. (Previously amended) The method as recited in claim 1, further comprising:
`initiating a request from the e-purse after valid personal identification numbers
`are entered and accepted on the portable device;
`sending a request by the midlet to the e-purse applet that is configured to
`compose a response to be sent to the midlet;
`transporting the response to the payment server that is configured to verify that
`the response is from an authenticated e-purse, wherein the payment server
`further communicates with a financial institution to authorize a transaction
`therewith; and
`sending a server response from the payment server to the midlet that is
`configured to process the server response before releasing the server
`response to the e-purse applet.
`
`Page 3 of 12
`
`RFC00001015
`
`

`

`Case 6:22-cv-00697-ADA Document 41-5 Filed 08/21/23 Page 5 of 13
`
`8. (Original) The method as recited in claim 7, wherein messages exchanged between
`the midlet and the payment server are in a type of commands encapsulated in
`network messages.
`
`9. (Original) The method as recited in claim 8, wherein the commands are applicable
`for APDU which stands for Application Protocol Data Unit.
`
`10. (Original) The method as recited in claim 1, wherein the e-purse is funded through a
`financial institution that maintains an account for a user being associated with the
`portable device, and the e-purse supports transactions in either e-commerce or m-
`commerce.
`
`11. (Currently amended) A system for providing an e-purse, the system comprising:
`a portable device including or communicating with a smart card pre-loaded with an
`emulator configured to execute a request from and provide_ a_ response an e-
`purse_e_pple_t is_ configured toexpect, the portable device including a memory
`space loaded with a midlet that is configured to facilitate wireless communication
`between a- w--the a-purse applet in the smart card and a payment server over a
`wireless network, the portable device further including a contactless interface that
`facilitates communication between the e-purse applet in the smart card and the
`payment server over a wired network, wherein .the_e-gurse_applet_ is_downlo ded_
`from the payment server when the smart cart is_in communication _with _the
`payment server, and _sad-_ operations o_personalizing the e-purse applet
`comprises:
`establishing an initial security channel between the smart card and the e-
`purse security authentication module (SAM) to install and personalize the
`e-purse applet in the smart card, and
`creating a security channel on top of the initial security channel to protect
`subsequent operations of the smart card with the e-purse SAM, wherein
`any subsequent operation of the emulator is conducted over the security
`channel via the e-purse applet;
`the payment server associated with an issuer authorizing the e-purse applet; and
`
`Page 4 of 12
`
`RFC00001016
`
`

`

`Case 6:22-cv-00697-ADA Document 41-5 Filed 08/21/23 Page 6 of 13
`
`the e-purse SAM configured to enable the e-purse applet, wherein an SAM is behind
`the payment server and in communication with the e-purse applet when the e-
`purse applet is caused to communicate with the payment server via the midlet.
`
`12. (Original) The system as recited in claim 11, wherein both of the e-purse applet and
`emulator are personalized by reading off data from the smart card, the data is then
`used to generate operation keys for the e-purse applet.
`
`13. (Original) The system as recited in claim 12, wherein the operation keys include
`one or more of a load key and a purchase key, default personal identification
`numbers (PINs), administration keys, and passwords.
`
`14. (Previously amended) The system as recited in claim 13, wherein at least some of
`the operation keys are used to establish a first secured channel so that various data
`is exchanged between the e-purse applet and the payment server, and at least
`another some of the operation keys are used to establish a second secured channel
`so that various data is exchanged between the e-purse applet and an existing
`security authentication module (SAM) originally used to issue the e-purse as well as
`between the emulator and the existing SAM.
`
`15. (Previously amended) The system as recited in claim 11, wherein, when the portable
`device is used to have a transaction, there are operations of:
`initiating a request from the e-purse after valid personal identification numbers
`are entered and accepted on the portable device;
`sending a request by the midlet to the e-purse applet that is configured to
`compose a response to be sent to the midlet;
`transporting the response to the payment server that is configured to verify that
`the response is from an authenticated e-purse, wherein the payment server
`further communicates with a financial institution to authorize a transaction
`therewith; and
`
`Page 5 of 12
`
`RFC00001017
`
`

`

`Case 6:22-cv-00697-ADA Document 41-5 Filed 08/21/23 Page 7 of 13
`
`sending a server response from the payment server to the midlet that is
`configured to process the server response before releasing the server
`response to the e-purse applet.
`
`16. (Original) The system as recited in claim 15, wherein messages exchanged between
`the midlet and the payment server are in a type of commands encapsulated in
`network messages.
`
`17. (Original) The system as recited in claim 16, wherein the commands are applicable
`for APDU which stands for Application Protocol Data Unit.
`
`18. (Original) The system as recited in claim 11, wherein the e-purse is funded through a
`financial institution that maintains an account for a user being associated with the
`portable device.
`
`Page 6 of 12
`
`RFC00001018
`
`

`

`Case 6:22-cv-00697-ADA Document 41-5 Filed 08/21/23 Page 8 of 13
`
`Remarks
`
`Claims 1-18 were submitted for examination. In the Office Action dated
`10/01/2010, Claims 1-18 are rejected under 35 USC 103(a) as being unpatentable over
`Shmueli et al (US Publication No.: 20020145632, hereinafter "Shmueli") in view of
`Nystrom (US 2009/0313689 Al; hereinafter Nystrom).
`
`Comments on Examiner's Response to Arguments
`
`The Applicant respectfully disagrees with the comments made by the Examiner
`to the arguments presented in the previous Response dated 12/31/2010. On page 13,
`Examiner contends that there is a two-level security means of communication disclosed
`by Shmueli. The applicant wishes to point out that Shmueli teaches only the
`authentication of the key 10 to the host 12. As shown in FIG. 2A - FIG.2C of Shmueli,
`such a key is inserted to a host that runs a keylet to verify if the key is being used by an
`authorized user. As further described in paragraphs [0035]-[0039] of Shmueli, the
`authentication routine (using password) is the only step Shmueli needs before using the
`key. The Examiner evidently mistakes the steps 102-106 of FIG. 3 as a step before the
`authentication routine. The paragraph [0035] specifically states that "the key 10 is
`identified (block 102) and the communication interface is configured to facilitate
`interaction (block 104)". In contrast, Claim 1 of the instant application recites
`"establishing an initial security channel between the smart card and the e-purse SAM
`..." and "creating a security channel on top of the initial security channel to protect
`subsequent operations of the smart card with the e-purse SAM over the wired network ".
`The applicant respectfully submits that it is a technical mistake to classify the
`identification of a key by a host as establishing an (initial) security channel. Further the
`communication between a key and a host is significantly and operationally different from
`operations of the smart card with the e-purse SAM over a wired network.
`
`Rejections of Claims 1-18 under 35 USC 103(a)
`
`The Applicant respectfully disagrees with the Examiner as it is believed that the
`Examiner seemed to have been mistaken with the architecture aspects and security
`mechanism recited in Claim 1 and those of Shmueli.
`
`Page 7 of 12
`
`RFC00001019
`
`

`

`Case 6:22-cv-00697-ADA Document 41-5 Filed 08/21/23 Page 9 of 13
`
`As amended, Claim 1 explicitly recites:
`providing a portable device including or communicating with a smart card pre-loaded
`with an emulator configured to execute a request from an e-purse applet and
`provide a response the e-purse applet is configured to expect, the portable
`device including a memory space loaded with a midlet that is configured to
`facilitate communication between the e-purse applet and a payment server over
`a wireless network, wherein the e-purse applet is downloaded and installed in the
`smart card when the smart cart is in communication with the payment server, the
`portable device further includes a contactless interface that facilitates
`communication between the e-purse applet in the smart card and the payment
`server over a wired network;
`personalizing the e-purse applet by reading off data from the smart card to generate
`in the smart card one or more operation keys that are subsequently used to
`establish a secured channel between the e-purse applet and an e-purse security
`authentication module (SAM) external to the smart card, wherein said
`personalizing the e-purse applet comprises:
`establishing an initial security channel between the smart card and the e-
`purse SAM to install and personalize the e-purse applet in the smart card,
`and
`creating a security channel on top of the initial security channel to protect
`subsequent operations of the smart card with the e-purse SAM, wherein
`any subsequent operation of the emulator is conducted over the security
`channel via the e-purse applet.
`(emphasis added)
`
`As described in paragraph [0029] and [0031], an emulator (e.g., Mifare emulator
`208 in FIG. 2) is a hardware device or a program that pretends to be another particular
`device or program that other components expect to interact with. In the context of the
`instant invention, the emulator is able to execute a request from an e-purse applet and
`provide a response the e-purse applet is configured to expect. In other words, the smart
`cart recited in Claim 1 that includes the emulator has the necessary computing power to
`execute commands with data. As further amended, the e-purse applet is personalized
`by reading off data from the smart card to generate in the smart card one or more
`operation keys for subsequent operations over a wired network, which again recites
`
`Page 8 of 12
`
`RFC00001020
`
`

`

`Case 6:22-cv-00697-ADA Document 41-5 Filed 08/21/23 Page 10 of 13
`
`clearly that the smart card is not just a memory card, the smart card is a computing
`device (i.e., an active device).
`
`In contrast, Shmueli states explicitly in paragraph [0027] that the key 10 is a
`"passive" device, which means it has no computing power. As described in paragraph
`[0027], the key 10 is primarily includes memory 18 having software 20, where the
`software 20 is running on one of the hosts 12 with data 22. The memory 18 must be
`associated with a key interface 24 to facilitate communication with the hosts 12, where
`the memory 18 emulates a file system on a memory device accessible by the host 12.
`Evidently, anyone skilled in the art would understand the memory 18 is NOT an
`emulator per se in the industry. In fact, from a technical perspective, a file system in a
`storage device is merely to allow a host to locate a file stored in the storage device, it
`does not execute a request neither produce a response, despite the fact the key 10 can
`not computer by itself.
`
`Accordingly, the Applicant respectfully submits that the Examiner interprets
`Shmueli beyond its original scope. Shamueli neither teaches nor suggests "a smart card
`pre-loaded with an emulator execute a request from an e-purse applet and provide a
`response the e-purse applet is configured to expect" and "personalizing the e-purse
`applet by reading off data from the smart card to generate in the smart card one or more
`operation keys" for the reasons stated above.
`
`As supported in paragraph [0037], the e-purse applet is dynamically installed and
`personalized. In other words, the e-purse applet is NOT pre-installed. In contrast, the
`software 20 in the key 10 in Shamueli is pre-installed and must be uploaded to a host
`for execution, see paragraphs [0027] and [0028] of Shamueli. Thus, the Applicant
`submits Shamueli neither teaches nor suggests "the e-purse applet is downloaded and
`installed in the smart card" recited in Claim 1 as amended in the instant application.
`
`Further as described in paragraphs [0007], [0024] — [0027], [0037] and shown in
`FIG. 1A and FIG. 3C, personalizing the e-purse applet requires a type of data
`communication with an e-purse SAM. The data communication includes installing and
`personalizing the e-purse applet in the smart card and creating security means to
`protect subsequent operations of the smart cards with the e-purse SAM over the wired
`network. To do so without a prior security channel, an initial security channel between
`
`Page 9 of 12
`
`RFC00001021
`
`

`

`Case 6:22-cv-00697-ADA Document 41-5 Filed 08/21/23 Page 11 of 13
`
`the smart card and the e-purse SAM module shall be established. For example, such an
`initial security channel is established by using a general security framework of a
`preloaded operating system in a smart card. Once an initial security channel is
`established, a (second) security channel on top of the initial security channel is
`established to protect subsequent operations of the smart card with the e-purse SAM. .
`
`In contrast, Shmueli is silent about establishing a security channel on top of an
`initial security channel (e.g., an industrially recognized framework) to facilitate
`subsequent operations of the e-purse applet with the external e-purse SAM over a
`network. FIG. 1 of Shmueli shows that there are three entities, a key 10, a host 12 and a
`server 14. As pointed above, the key 10, which the Examiner has deemed as a "smart
`card", is a passive device and has no computing power to establish a security channel
`with any other device. Accordingly, Shmueli does not teach nor suggests that the key 10
`needs to be personalized using (two-level) security means. Further Shmueli is silent
`about having an emulator in the key 10 to conduct subsequent operations thereof over
`the security channel established by the e-purse applet to conduct either e-commerce or
`m-commerce.
`
`On page 4 of the Office Action, the Examiner admits that Shmueli does not
`explicitly disclose establishing a security channel on top of an initial security channel to
`install the e-purse applet in the smart card, and then cites Nystrom to teach the same.
`
`The Applicant respectfully contests the combination of Shmueli and Nystrom as it
`is believed that there is no motivation to combine these two references in the manner
`proposed by the Examiner. In order to establish a prima facie case of obviousness
`under 35 USC 103, Graham v. John Deer Co. of Kansas City, 383 US 1 (1966) requires
`determining, respectively, the scope and content of the prior art, the difference between
`the prior art and the claims at issue, and the level of ordinary skilled in the art.
`Rejections on obviousness grounds cannot be sustained by mere conclusory
`statements; instead, there must be some articulated reasoning with some rational
`underpinning, to support the legal conclusion of obviousness. KSR V. Teleflex, No. 04-
`1350 (US Apr. 30, 2007) (citing In re Kahn, 441 F. 3d 977, 988 (Canada Fed. 2006)).
`The suggestion to make the claim combination must be found in the prior art, not in the
`Applicant's disclosure. In re Vaek, 20 USPQ2d 1438 (Fed. Cir. 1991). Moreover, in
`
`Page 10 of 12
`
`RFC00001022
`
`

`

`Case 6:22-cv-00697-ADA Document 41-5 Filed 08/21/23 Page 12 of 13
`
`accordance with MPEP 2142.02, each prior art reference must be considered in its
`entirety, i.e., as a whole, including portions that would lead away from the claimed
`invention. W.L. Gore & Associates Inc. V. Garlock, Inc. 220 USPQ 303 (Fed. Cir. 1993).
`A third essential requirement for establishing a prima facie case, set forth in MPEP
`2143.01, is that the proposed modification cannot render the prior art unsatisfactory for
`its intended purpose.
`
`Nystrom teaches remote management of secure storages (e.g., smart cards)
`applicable with contactless technology applications. The Examiner states on page 5 of
`the Office Action that Nystrom discloses personalizing the e-purse applet (Reload
`&Update Procedures; para [0111-120]) by reading off data from the smart card to
`generate one or more operation keys ("a reloading of relevant application related code
`sections, i.e. program code and/or user interface definitions") in light of association
`procedures. However, a careful review of Nystrom, specifically these paragraphs para
`[0111-120]), indicates that Nystrom does not need to establish an initial security channel
`to install the e-purse applet or a software element in the smart card. In fact, Nystrom
`uses a SIM card 165 of FIG. 2 to authorize the smart card (including 190 of FIG. 3a) to
`communicate with a carrier's network. It is well known that SIM card, standing for
`subscriber identification module (SIM) card, is an authorized identifier to allow a device
`with a SIM to conduct permitted communication over a carrier's network (no need to
`establish a secure channel). What Nystrom teaches about reloading and update
`procedures is about reactions to the exchange between different terminal devices
`having different processing capabilities and functionalities and underlying different
`constraints. The Applicant respectfully submits the Examiner interprets Nystrom beyond
`its original intent. Nystrom neither teaches nor suggests about establishing a two-level
`security channel to protect subsequent operations over a wired network. In one
`perspective, Nystrom teaches away from Claim 1 by using a SIM card thus avoiding to
`personalize the e-purse applet in the smart card.
`
`The Applicant further submits that the key 10 in Shmueli could not be modified by
`the SIM card or the smart card in Nystrom because Shmueli specifically states that an
`application must be uploaded to a host to be executed while a smart card is able to
`execute an application in the care itself. Accordingly, the combination of Shmueli and
`
`Page 11 of 12
`
`RFC00001023
`
`

`

`Case 6:22-cv-00697-ADA Document 41-5 Filed 08/21/23 Page 13 of 13
`
`Nystrom neither teaches nor suggests Claim 1, and Claim shall be allowable over
`Shmueli and Nystrom. Reconsideration of Claims 1-10 is kindly requested.
`
`Claim 11 has been amended to include similar limitations recited in Claim 1. The
`Applicant wishes to rely on the above arguments to support once-amended Claim 11,
`and respectfully submits Claim 11, as amended, is neither taught nor suggested by
`Shmueli and Nystrom, viewed alone or in combination, and shall be allowable over
`Shmueli and Nystrom. Reconsideration of Claims 11 - 18 is kindly requested.
`
`In view of the above amendments and remarks, the Applicant believes that
`Claims 1 - 18 shall be in condition for allowance over the cited references. Early and
`favorable action is being respectfully solicited.
`
`If there are any issues remaining which the Examiner believes could be resolved
`through either a Supplementary Response or an Examiner's Amendment, the Examiner
`is respectfully requested to contact the undersigned at (408)777-8873.
`
`I hereby certify that this correspondence is
`being deposited with the United States Postal
`Service as first class mail in an envelope
`addressed to " Box: Non-Fee Amendment
`Commissioner of Patents and Trademarks
`P.O. Box 1450, Alexandria, VA 22313-1450",
`on Sep. 7, 2010.
`
`Name: Joe Zheng
`
`Signature:
`
`/ b e zheng /
`
`Respectfully submitted,
`
`/joe zheng /
`Joe Zheng
`Reg. No.: 39,450
`
`Page 12 of 12
`
`RFC00001024
`
`