Case 6:21-cv-00916-ADA Document 43 Filed 04/19/22 Page 1 of 27
`
`IN THE UNITED STATES DISTRICT COURT
`FOR THE WESTERN DISTRICT OF TEXAS
`WACO DIVISION
`
`RFCYBER CORP.,
`
`v.
`
`APPLE INC.,
`
`Plaintiff,
`
`Defendant.
`
`Civil Action No. 6:21-cv-00916-ADA
`
`JURY TRIAL DEMANDED
`
`DEFENDANT APPLE INC.’S OPENING CLAIM CONSTRUCTION BRIEF
`
`WEST\298299817.1
`
`

`

`Case 6:21-cv-00916-ADA Document 43 Filed 04/19/22 Page 2 of 27
`
`TABLE OF CONTENTS
`
`Page
`
`I.
`II.
`
`III.
`IV.
`
`V.
`
`B.
`
`C.
`
`INTRODUCTION ...............................................................................................................1
`OVERVIEW OF THE ASSERTED PATENTS..................................................................1
`A.
`U.S. Patent Nos. 8,118,218, 8,448,855, and 9,189,787 ...........................................2
`B.
`U.S. Patent Nos. 9,240,009 and 10,600,046 ............................................................4
`C.
`U.S. Patent No. 11,018,724......................................................................................5
`AGREED CONSTRUCTIONS ...........................................................................................7
`DISPUTED CLAIM TERMS ..............................................................................................8
`A.
`“e-purse” / “electronic purse” / “e-purse applet” .....................................................8
`1.
`The Intrinsic Record Confirms That An E-Purse Stores Electronic
`Value. ...........................................................................................................9
`The Extrinsic Evidence, Including RFCyber’s Prior Concessions,
`Confirms That An E-Purse Stores Electronic Value..................................13
`RFCyber’s Newly Minted Position Would Contradict The Intrinsic
`Record And The Extrinsic Evidence. .........................................................14
`“payment server” ...................................................................................................15
`1.
`The Intrinsic Record Confirms That A Payment Server Is A Server
`For Payment Transactions..........................................................................16
`The Extrinsic Evidence, Including RFCyber’s Prior Concessions,
`Confirms That A Payment Server Is A Server For Payment
`Transactions. ..............................................................................................17
`“security authentication module” / “SAM” ...........................................................18
`1.
`The Intrinsic Record Confirms That The Security Authentication
`Module Must Contain Data To Authenticate Transactions Of
`Funds. .........................................................................................................18
`The Extrinsic Evidence Confirms That A Security Authentication
`Module Must Contain Data To Authenticate Transactions Of
`Funds. .........................................................................................................19
`D.
`“application” ..........................................................................................................20
`CONCLUSION ..................................................................................................................22
`
`2.
`
`3.
`
`2.
`
`2.
`
`WEST\298299817.1
`
`i
`
`

`

`Case 6:21-cv-00916-ADA Document 43 Filed 04/19/22 Page 3 of 27
`
`TABLE OF AUTHORITIES
`
`
`
`Page(s)
`
`Cases
`
`Amazon.com, Inc. v. Barnesandnoble.com, Inc.,
`239 F.3d 1343 (Fed. Cir. 2001)................................................................................................14
`
`Aylus Networks, Inc. v. Apple Inc.,
`856 F.3d 1353 (Fed. Cir. 2017)................................................................................................14
`
`CommScope Techs. LLC v. Dali Wireless Inc.,
`10 F.4th 1289 (Fed. Cir. 2021) ................................................................................................14
`
`Groove Digital v. United Bank,
`825 F. App’x 852 (Fed. Cir. 2020) ..........................................................................................17
`
`HTC Corp. v. Cellular Commc’ns Equip., LLC
`701 F. App’x 978 (Fed. Cir. 2017) ............................................................................................9
`
`Profectus Tech. LLC v. Huawei Technologies Co.,
`823 F.3d 1375 (Fed. Cir. 2016)................................................................................................17
`
`SpeedTrack, Inc. v. Amazon.com,
`998 F.3d 1373 (Fed. Cir. 2021)................................................................................................14
`
`Trading Tech. Intl., Inc. v. Open E Cry, LLC,
`728 F.3d 1309 (Fed. Cir. 2013)..................................................................................................8
`
`WEST\298299817.1
`
`i
`
`

`

`Case 6:21-cv-00916-ADA Document 43 Filed 04/19/22 Page 4 of 27
`
`Defendant Apple Inc. submits its Opening Claim Construction Brief for U.S. Patent Nos.
`
`8,118,218 (“the ’218 patent”); 8,448,855 (“the ’855 patent”); 9,189,787 (“the ’787 patent”);
`
`9,240,009 (“the ’009 patent”); 10,600,046 (“the ’046 patent”); and 11,018,724 (“the ’724
`
`patent”) (the “Asserted Patents”).
`
`I.
`
`INTRODUCTION
`
`Apple’s constructions rely on the intrinsic record and statements made during related
`
`proceedings to clarify the handful of disputes between the parties. Regarding the “e-purse”
`
`terms, Apple’s construction holds true to the use of those terms in the claims and specification
`
`and in the relevant extrinsic evidence. While RFCyber proposes a broader construction,
`
`RFCyber disclaimed that scope during prosecution. Apple’s construction of “payment server”
`
`provides useful guidance by explaining that the term refers specifically to servers for payment
`
`transactions, a point RFCyber acknowledged via its proposed construction for the same claim
`
`term in a prior case. Apple has proposed a construction for “security authentication module” that
`
`clarifies the term must contain the data used for authentication rather than merely some portion
`
`of the data. Lastly, regarding “application,” Apple’s proposed construction explains that the
`
`term refers to a complete software program capable of execution, rather than partial or
`
`incomplete software snippets. In each instance, Apple’s constructions address and clarify the
`
`disputed issues based on the use of the same and similar terms in the asserted patents.
`
`II.
`
`OVERVIEW OF THE ASSERTED PATENTS
`
`The six Asserted Patents generally relate to mobile payments, and, in particular, the
`
`personalization, funding, and use of an electronic purse (“e-purse”) on a smart card in a portable
`
`device to conduct secure transactions.
`
`WEST\298299817.1
`
`1
`
`

`

`Case 6:21-cv-00916-ADA Document 43 Filed 04/19/22 Page 5 of 27
`
`A.
`
`U.S. Patent Nos. 8,118,218, 8,448,855, and 9,189,787
`
`The ’218, ’855, and ’787 patents share a common specification and describe an e-purse
`
`on a smart card in a Near Field Communication (“NFC”)-enabled mobile phone or other portable
`
`device, which allows the device to conduct secure payment transactions either over a wireless
`
`network (“m-commerce”) or via an RFID reader (“e-commerce”). ’218 patent at 1:6-22, 1:34-38,
`
`Fig. 2. The patents refer to an e-purse as a “single functional card” having “stored values,” i.e.,
`
`electronic money, for performing “micro payment transactions.” Id. at 1:14-17, 1:23-27, 3:51-55,
`
`3:61-63, 4:2-7, 4:62-64. The patents explain that “[s]ingle functional cards have been
`
`successfully used in enclosed environments such as transportation systems” and highlight the
`
`MIFARE card as a widely used e-purse. Id. at 1:13-22. They assert, however, that “such enclosed
`
`systems are difficult to be expanded into other areas such as e-commerce and m-commerce
`
`because stored values and transaction information are stored” in a way that is “protected by a set
`
`of keys,” and “the keys need to be delivered to the card for authentication before data can be
`
`accessed during a transaction.” Id. at 1:23-29. Thus, there is “a need for a mechanism in devices,
`
`especially 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 security.” Id. at
`
`1:34-38.
`
`The patents’ purported solution is to provide “a mechanism to be embedded” in the
`
`portable device to function as an e-purse and provide the necessary security. Id. at 2:42-46. That
`
`“mechanism” is a smart card. Id. at 2:10-41. The smart card comes with a preloaded operating
`
`system, such as Java Card Open Platform (“JCOP”), which provides “a general security
`
`framework,” such as the GlobalPlatform standard, for “card personalization.” Id. at 4:8-22, 4:41-
`
`46, 4:50-56. The operating system’s security “control[s] the access to the smart card (e.g., an
`
`installation of external applications into the smart card).” Id. at 4:47-50.
`2
`
`WEST\298299817.1
`
`

`

`Case 6:21-cv-00916-ADA Document 43 Filed 04/19/22 Page 6 of 27
`
`The patents explain that “multiple application smart cards” – including the well-known
`
`SmartMX smart card by Philips – can also come “pre-loaded with an emulator,” such as a
`
`MIFARE emulator, allowing the multi-application smart card to mimic (or “emulate”) single
`
`functional cards such as a MIFARE transit card for use with MIFARE readers. Id. at 2:14, 2:27-
`
`28, 3:51-60, 4:62-64, Fig. 2.
`
`The ’218, ’855, and ’787 patents teach that a smart card, including an e-purse applet or
`
`emulator in the smart card, can be personalized using a GlobalPlatform card manager to establish
`
`a secure channel between the e-purse and a server. Id. at 4:11-22, 5:50-54. Personalization
`
`involves loading a specific user’s data into the e-purse, e.g., the user’s account information,
`
`“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).” Id. at 5:54-59.
`
`Smart cards that comply with the GlobalPlatform standard have at least one security domain that
`
`“includes three 3DES keys,” which are encryption keys that are “used to generate session keys
`
`for a secured session between two entities,” i.e., a security channel. Id. at 6:29-47, Fig. 3C. The
`
`security domain and encryption keys are “installed by a card issuer.” Id. at 6:48-54. Another set
`
`of keys can also be generated and distributed to the e-purse applet to secure subsequent
`
`operations. Id. at 6:55-7:9, Fig. 3C.
`
`The ’218, ’855, and ’787 patents also describe a process for funding the e-purse – a
`
`necessary step for using it to conduct transactions. Id. at 7:10-13, 8:7-12, Figs. 4A-4C. After a
`
`valid PIN entry, the midlet initiates an over-the-air (“OTA”) “top off request,” sending a request
`
`to the e-purse applet. Id. at 7:22-28, Fig. 4A. The e-purse applet composes a response to the
`
`request, which is sent via the midlet to “a payment network and server over a wireless network.”
`
`Id. at 7:29-32, Fig. 4A. The response is verified and then a bank account at a financial institution
`
`WEST\298299817.1
`
`3
`
`

`

`Case 6:21-cv-00916-ADA Document 43 Filed 04/19/22 Page 7 of 27
`
`is verified. Id. at 7:35-44, Fig. 4A. A response is then sent back to the midlet after which
`
`commands are extracted from the response and sent to the e-purse. Id. at 7:45-48, Fig. 4B. The e-
`
`purse verifies the commands and then updates the emulator and transaction logs to reflect the
`
`updated stored value. Id. at 7:48-51, Fig. 4B.
`
`B.
`
`U.S. Patent Nos. 9,240,009 and 10,600,046
`
`The ’009 and ’046 patents are continuations-in-part of the ’218 patent and describe
`
`mobile devices with “secure elements” that can securely host “an application such as an
`
`electronic purse” for conducting secured transactions over a network. ’009 patent at 1:18-24. The
`
`’009 and ’046 patents share a common specification that includes the disclosures found in the
`
`’218, ’855, and ’787 patent specifications, as well as additional disclosures and figures.
`
`The ’009 patent states:
`
`[T]here is a need to provide techniques to personalize a secure element in a contactless
`smart card or an NFC-enabled mobile device so that such a device is so secured and
`personalized when it comes to financial applications or secure transactions. With a
`personalized secure element in an NFC-enabled mobile device, various applications
`or services, such as electronic purse or payments, can be realized.
`
`Id. at 2:10-17. The ’009 patent teaches that when a mobile device is obtained, the secure element
`
`(“SE”) “is installed with a set of default keys (e.g., an Issuer Security Domain (ISD) key set by
`
`the SE manufacturer).” Id. at 6:55-58, 8:46-48. “[A] standard-compliant secure element comes
`
`with one issuer security domain (ISD) and an option for one or more supplemental security
`
`domains (SSD). Each of these domains includes a set of keys.” Id. at 7:1-4.
`
`The ’009 patent explains that the “SE 102 needs to go through a personalization process
`
`before it can be used.” Id. at 7:13-14. “The personalization process can be done either physically
`
`in a service center or remotely via a web portal by a TSM server.” Id. at 7:49-51. A “TSM,
`
`standing for Trusted Service Management, is a collection of services” that can “help service
`
`providers securely distribute and manage contactless services for their customers using the
`4
`
`WEST\298299817.1
`
`

`

`Case 6:21-cv-00916-ADA Document 43 Filed 04/19/22 Page 8 of 27
`
`networks of mobile operators.” Id. at 7:35-39. The default “device information (e.g., ISD) of the
`
`SE” can be used to derive personalized keys to personalize the SE. Id. at 8:57-9:23. “After the
`
`personalization, the SE can only be accessed using the personalized ISD key of the SE issuer.
`
`Depending on the security requirement of each service provider, the TSM can create additional
`
`SSDs for the various providers to personalize their respective applications (e.g., the modules 104
`
`or 106 of FIG. 1A).” Id. at 9:24-29.
`
`The ’009 patent describes “an e-token enabled device,” such as “a single functional card
`
`or a portable device enabled with an e-purse” that “may represent e-money, e-coupons, e-ticket,
`
`e-voucher or any other forms of payment tokens in a device. Id. at 20:44-50. Transactions using
`
`the e-token device may occur in “real time” and “offline (i.e., without the portable device
`
`connecting to a backend POS transaction server.” Id. at 20:51-58; see also id. at Figs. 6A-6D.
`
`Figure 6D depicts “a flowchart illustrating an exemplary process [] of conducting m-commerce
`
`using a portable device.” Id. at 22:48-56, Fig. 6D. The ’009 patent explains that transactions
`
`using the e-purse may be evaluated against the value stored on the e-purse to determine whether
`
`to approve or deny the transaction or to allow the user to “top-up” and attempt re-processing. Id.
`
`at 22:57-23:20, Figs. 6C and 6D.
`
`C.
`
`U.S. Patent No. 11,018,724
`
`The ’724 is a continuation-in-part of the ’218 patent but comprises a different
`
`specification. The ’724 Patent describes an NFC equipped mobile device configured to emulate
`
`multiple different contactless card applications. ’724 patent, Abstract, 1:8-11, 1:33-36, 5:66-6:6.
`
`Depicted below in Fig. 1A, a key focus of the ’724 Patent is secure element 108, which contains
`
`multiple card applications, an emulator, and a Trusted Mifare Service Manager (TMSM) 106 to
`
`support multiple cards in a single device:
`
`WEST\298299817.1
`
`5
`
`

`

`Case 6:21-cv-00916-ADA Document 43 Filed 04/19/22 Page 9 of 27
`
`Id., Fig. 1A, Abstract, 1:54-2:3, 6:17-55.
`
`Applications and their associated security domains are downloaded and installed and
`
`personalized on the secure element by the TMSM 106. Id., 7:1-12, 7:43-47. The TMSM is also
`
`responsible for allowing a user to swap applications into or out of emulator 122, e.g., to use a
`
`different card for an upcoming transaction. Id., 1:61-64, 7:8-47 (noting that one application
`
`should always remain “activated”).
`
`The ’724 Patent describes additional features related to the multi-card mobile device and
`
`swapping applications via the emulator. For example, applications can be locked such that they
`
`may not be swapped into the emulator until they are unlocked. Id., 9:60-64. Additionally, the
`
`’724 Patent contemplates retaining certain data from a first application for use by a second
`
`application (i.e., a partial swap) or simply swapping applications and their data in their entirety
`
`(i.e., a complete swap). Id., 7:29-33, 2:67-3:2. Finally, a counter can be used as an additional
`
`WEST\298299817.1
`
`6
`
`

`

`Case 6:21-cv-00916-ADA Document 43 Filed 04/19/22 Page 10 of 27
`
`layer of security. For example, “[u]pon a successful swapping, [a] counter is incremented by 1”
`
`as a way “to keep track of the [applications/server objects] that are currently swapped out.” Id.,
`
`10:7-65.
`
`III.
`
`AGREED CONSTRUCTIONS
`
`The parties met and conferred on April 8, 2022 and exchanged emails on April 12, 2022,
`
`agreeing to constructions for the following terms:
`
`No. Claim Term
`1.
`“emulator”
`
`’218 patent, claims 1, 3, 6, 11-12, 14
`’855 patent, claims 1-2, 5-6, 9, 11, 14-15
`’787 patent, claims 1, 3, 10-11, 13, 16
`“payment gateway”
`
`’046 patent, claim 1
`“smart card”/“smart card module”/“card
`module”
`
`’218 patent, claims 1, 11-12
`’855 patent, claims 1-3, 9-12
`’787 patent, claims 1, 6, 8-9, 11, 16, 18-19
`“smart card pre-loaded with the emulator”
`
`’218 patent, claims 1, 11
`“midlet”
`
`’218 patent, claims 1, 5, 7-8, 11, 15-16
`’855 patent, claims 1, 9
`’787 patent, claims 1, 10
`“personalization”/”personalizing”
`
`2.
`
`3.
`
`4.
`
`5.
`
`6.
`
`’218 patent, claims 1, 4-6, 11-12
`’855 patent, claims 1, 3, 9, 12
`’787 patent, claims 1-2, 6-7, 11-12, 16-17
`’009 patent, claims 6-7, 17
`“security channel” / “secured channel”
`
`7.
`
`
`
`’218 patent, claims 1, 3, 11, 14
`
`7
`
`WEST\298299817.1
`
`Agreed Construction
`hardware device or program that
`pretends to be another particular
`device or program that other
`components expect to interact with
`
`server or collection of servers for
`settling a payment
`
`No construction necessary; plain and
`ordinary meaning
`
`No construction necessary; plain and
`ordinary meaning
`
`No construction necessary; plain and
`ordinary meaning
`
`No construction necessary; plain and
`ordinary meaning
`
`No construction necessary; plain and
`ordinary meaning
`
`

`

`Case 6:21-cv-00916-ADA Document 43 Filed 04/19/22 Page 11 of 27
`
`No. Claim Term
`’855 patent, claims 1, 4, 9, 13
`’787 patent, claims 1, 2, 6, 11, 12, 16
`’009 patent, claims 1, 4, 14
`’724 patent, claims 1, 8
`“emulator device”
`
`8.
`
`
`
`’724 patent, claims 1, 3, 8
`
`Agreed Construction
`
`hardware device, alone or containing
`software, that pretends to be another
`particular device or program that other
`components expect to interact with
`
`IV.
`
`DISPUTED CLAIM TERMS
`
`A.
`
`“e-purse” / “electronic purse” / “e-purse applet”
`
`Term and Claims
`“e-purse” / “electronic purse” / “e-
`purse applet”
`
`’218 patent, claims 1, 3-7, 10-12,
`14-15, 18
`’855 patent, claims 1, 3-6, 9, 12-15
`’787 patent, claims 1-3, 5-6, 11-13,
`15-16
`’009 patent, claim 3
`’046 patent, claim 1
`
`Apple’s Construction
`software that stores
`electronic financial
`information, including
`electronic value, in a local
`portable device
`
`RFCyber’s Construction
`Regarding “e-purse” and
`“electronic purse”,
`“software that stores
`electronic financial
`information in a local
`device”
`
`Regarding “e-purse applet”,
`Plain and ordinary meaning
`except for the term “e-purse”
`
`The ’218, ’855, ’787, ’009 and ’046 patents (the “e-purse patents”) are directed to
`
`systems for providing and funding e-purses. The e-purse patents are part of the same family, and
`
`each later patent ultimately claims priority back to the ’218 patent. The ’218, ’855, and ’787
`
`patents share the same specification, while the ’009 and ’046 patent specifications include the
`
`same disclosures as the previous three patents, as well as additional disclosures. Because these
`
`patents claim priority to one another, share the same disclosures, and list common inventors, the
`
`use of the disputed terms in each patent informs the proper construction of the “e-purse” terms
`
`across all five e-purse patents. See Trading Tech. Intl., Inc. v. Open E Cry, LLC, 728 F.3d 1309,
`
`1323 (Fed. Cir. 2013) (“[P]rosecution history regarding a particular limitation in one patent is
`
`WEST\298299817.1
`
`8
`
`

`

`Case 6:21-cv-00916-ADA Document 43 Filed 04/19/22 Page 12 of 27
`
`presumed to inform the later use of that same limitation in related patents, ‘unless otherwise
`
`compelled.’”)
`
`The parties do not identify any meaningful distinction among the various “e-purse” terms
`
`in dispute (“e-purse,” “electronic purse,” and “e-purse applet”), so the terms should be
`
`considered together and given the same scope. See HTC Corp. v. Cellular Commc’ns Equip.,
`
`LLC, 701 F. App’x 978, 983 (Fed. Cir. 2017) (system and method claims in a patent had the
`
`same scope where parties did not assert any “meaningful” differences between them).
`
`The dispute regarding the “e-purse” terms centers around whether the electronic
`
`information stored by an e-purse includes but is not limited to electronic value. Apple contends
`
`that an e-purse stores electronic information including electronic value, as the patents describe.
`
`RFCyber takes a much broader view, contending that storage of any electronic financial
`
`information suffices. The parties do not dispute that an e-purse is software or that it stores
`
`electronic financial information in a device. The only dispute is the storage of electronic value.
`
`1.
`
`The Intrinsic Record Confirms That An E-Purse Stores Electronic
`Value.
`
`The plain claim language demonstrates that an e-purse stores “electronic value.” Claims
`
`1 and 9 of the ’855 patent recite “a method for funding an e-purse.” Claim 1 of the ’046 patent
`
`recites “verifying the total amount with a balance in the e-purse” and “displaying a
`
`confirmation in the mobile device that the balance in the e-purse has been reduced.”
`
`Unasserted claims 12 and 18 of the ’046 patent recite a “balance of an electronic purse (e-
`
`purse) maintained locally in the mobile device” where “the balance in the e-purse [is] reduced
`
`by the amount.” Dependent claims 10 and 18 of the ’218 patent recite a system or method
`
`“wherein the e-purse is funded.” The language of these claims informs the meaning of “e-
`
`purse” because there can be no “balance” or ability to “fund” the balance without storing an
`
`WEST\298299817.1
`
`9
`
`

`

`Case 6:21-cv-00916-ADA Document 43 Filed 04/19/22 Page 13 of 27
`
`electronic value. The storage of a balance of funds within the e-purse aligns with Apple’s
`
`construction that the e-purse stores “electronic value.”
`
`Indeed, RFCyber unequivocally disclaimed and distinguished an “e-purse” (which stores
`
`value locally) from an “e-wallet” (which stores card information) during prosecution of the ’218
`
`patent. The applicant asserted that U.S. Patent No. 6,607,136 (“Atsmon”) “describes [sic]
`
`entirely about e-wallet.” Ex. 1 (December 31, 2010 Response to Final Office Action) at 9. The
`
`applicant explained “[i]t is commonly known in the art that e-wallet is not the same as e-purse.”
`
`Id. “An e-wallet system has a user credit-card and personal info at the backend,” whereas “an e-
`
`purse in the instant application describes [] electronic money in a local portable device.” Id. The
`
`Atsmon reference describes an e-wallet as “a convenient application that allows the user to shop
`
`and purchase items … which contains all of his personal information.” Ex. 2 (Atsmon) at 68:53-
`
`67. When used for a purchase, the “e-wallet application would either fill out the form
`
`automatically for the user or deliver equivalent information to the website so that the sales
`
`transaction can be finalized.” Id. The applicant’s statements distinguishing Atsmon clarified
`
`that the claimed e-purse must do more than store credit card and personal information; it must
`
`store electronic money—something of value—in the local device.
`
`During the prosecution of the ’046 patent, the applicant further confirmed the correct
`
`construction of “e-purse.” The applicant explained that “the balance of the e-purse can be used
`
`to determine if the e-purse is sufficient to perform the transaction without verifying with the
`
`server.” Ex. 3 (November 28, 2019 Response to First Office Action) at 9. The applicant
`
`distinguished the prior art that “is clearly meant for credit or debit payment” and “neither teaches
`
`nor suggests the verification of a charge against the balance of a local e-purse.” Id. RFCyber
`
`WEST\298299817.1
`
`10
`
`

`

`Case 6:21-cv-00916-ADA Document 43 Filed 04/19/22 Page 14 of 27
`
`unambiguously disclaimed that an e-purse may include an e-wallet or simply storing any
`
`electronic financial information, but rather requires electronic storage of something of value.
`
`The specifications of the e-purse patents further confirm that the e-purse terms require
`
`storing electronic value. The specifications describe “viewing a purse balance.” ’218 patent at
`
`5:16-18.1 The patents also provide flowcharts describing the process for “financing [or funding]
`
`an e-purse.” ’218 patent at 7:10-18, 8:7-12 (“[P]rocess 400 is described as funding the e-purse”),
`
`Figs. 4A and 4B; ’009 patent at 17:3-5 (adding “or funding” language).2 When a user seeks to
`
`fund an e-purse, she initiates a funding or “top off request” to add to the balance stored within
`
`the e-purse. ’218 patent at 7:19-28. The terms “financing, funding, load or top-up [of] an e-
`
`purse” all refer to the process of adding electronic value to the e-purse. See ’009 patent at 5:10-
`
`12. The ’855 and ’787 patents further disclose “[t]echniques for funding an electronic purse (e-
`
`purse).” ’855 patent at Abstract; ’787 patent at Abstract; see also ’855 patent at Title (“Method
`
`and apparatus for funding an electronic purse.”)
`
`The ’009 and ’046 specifications include further disclosures that support the construction
`
`of storing “electronic value.” Figure 6D of the ’009 and ’046 patents depicts the use of an e-
`
`purse, including determining whether it contains a sufficient balance to complete the transaction.
`
`At step 672, the process sends an initial purchase request to the e-token enabled device, where
`
`the “e-token enabled device” refers to “a multi-functional card or an e-purse enabled cell phone
`
`emulating a multi-functional card.” ’009 patent at 22:57-65. The process next determines
`
`whether there is “[e]nough balance in [the] e-token enabled device” to complete the transaction.
`
`’009 patent at 22:65-23:5; Fig. 6D (shaded in yellow).
`
`1 Apple cites the ’218 patent by way of example, but these citations apply equally to the similar
`disclosures of the other e-purse patents.
`2 Apple’s citations to the ’009 patent apply equally to the similar disclosures in the ’046 patent.
`11
`
`WEST\298299817.1
`
`

`

`Case 6:21-cv-00916-ADA Document 43 Filed 04/19/22 Page 15 of 27
`
`In response to that determination, the system either denies the purchase request when
`
`“there is not enough balance in the e-token enabled device” or approves the transaction “if there
`
`is enough balance in the e-token enabled device.” ’009 patent at 22:65-23:5. “Also when there is
`
`not enough balance in the e-token enabled device, a top-up or funding operation may be
`
`performed using the process 400 illustrated in FIG. 4A and FIG. 4B.” Id. at 23:30-32. After a
`
`purchase completes, the system “deducts or debits the purchase amount from the e-token of the
`
`e-token enabled device.” Id. at 22:8-11, 23:42-45 (“Then e-token (e.g., e-money) is deducted
`
`from the e-purse 724 of the portable device 730 to pay the ticket purchase to a credit/debit
`
`system 714 (e.g., a financial institute, a bank).”). The patents also explain that a point-of-sale
`
`system may interact with the “e-token enabled device” to “check[] the current balance of [the] e-
`
`token device.” Id. at 22:37-47.
`
`WEST\298299817.1
`
`12
`
`

`

`Case 6:21-cv-00916-ADA Document 43 Filed 04/19/22 Page 16 of 27
`
`The claim language, the specifications, and the applicant’s statements during prosecution
`
`confirm the plain meaning of “e-purse” reflected in Apple’s construction, which is software that
`
`stores electronic financial information, including electronic value, in a local portable device.
`
`2.
`
`The Extrinsic Evidence, Including RFCyber’s Prior Concessions,
`Confirms That An E-Purse Stores Electronic Value.
`
`The available extrinsic evidence—including litigation positions taken by RFCyber during
`
`a related lawsuit—confirms that Apple’s construction is correct. During claim construction
`
`proceedings in the Google matter, RFCyber conceded “there is no dispute that an e-purse, like
`
`any purse, can store money.” Ex. 4 (RFCyber Claim Construction Reply in RFCyber v. Google)
`
`(“the Google Reply”). And multiple books and articles describing e-purse technology
`
`demonstrate that the “e-purse” terms store “electronic financial information, including electronic
`
`value.” These include:
`
`
`
`The Smart Card Handbook, which defines “Electronic Purse (e-purse)” as “[a]
`
`card with a chip that must be loaded with an amount of money before it can be used for making
`
`payments.” Ex. 5 at 5961;
`
`
`
`The GSA Smart Card Handbook, which defines “Electronic Purse” as “[a] chip-
`
`based application where cash or value is recorded on a chip and is available for use.” Ex. 6 at
`
`8941;
`
`
`
`A CEP Technical Specification, which defines “Electronic Purse” as “[a]n
`
`electronic purse uses an integrated circuit for the storage and processing of monetary value.” Ex.
`
`7 at 8348 (further defining “Electronic Value” as “[t]he value stored and exchanged in an
`
`electronic purse card system.” Id.
`
`WEST\298299817.1
`
`13
`
`

`

`Case 6:21-cv-00916-ADA Document 43 Filed 04/19/22 Page 17 of 27
`
`
`
`An article entitled “Shopping Without Cash,” which states “[a]n e-purse is a
`
`stored-value payment device that . . . holds electronic monetary value that substitutes for cash.”
`
`Ex. 8 at 10586.
`
`Thus, RFCyber’s prior position and the other extrinsic evidence are uniform in
`
`confirming that an e-purse stores or is capable of storing electronic value. Apple’s construction
`
`therefore reflects the universally plain meaning of that term.
`
`3.
`
`RFCyber’s Newly Minted Position Would Contradict The Intrinsic
`Record And The Extrinsic Evidence.
`
`Contradicting its position in the Google case, RFCyber’s new proposal (“software that
`
`stores electronic financial information in a local device”) would improperly broaden the term to
`
`try to recapture claim scope disclaimed during prosecution. Despite distinguishing the prior art
`
`on this basis during prosecution, and therefore arguing for a narrower construction of “e-purse,”
`
`RFCyber now rejects those earlier assertions in favor of a broader construction that would allow
`
`storage of any electronic financial information within the e-purse to satisfy this term. The
`
`doctrine of prosecution disclaimer exists to ensure that the proper construction of a term cannot
`
`be twisted to first avoid prior art but then later to encompass the same structures under
`
`infringement. See CommScope Techs. LLC v. Dali Wireless Inc., 10 F.4th 1289, 1299 (Fed. Cir.
`
`2021) (applying “the principle that a ‘patent may not, like a nose of wax, be twisted one way to
`
`avoid anticipation and another to find infringement.’”) (quoting Amazon.com, Inc. v.
`
`Barnesandnoble.com, Inc., 239 F.3d 1343, 1351 (Fed. Cir. 2001)); See Aylus Networks, Inc. v.
`
`Apple Inc., 856 F.3d 1353, 1360 (Fed. Cir. 2017) (““Ultimately, the doctrine of prosecution
`
`disclaimer ensures that claims are not ‘construed one way in order to obtain their allowance and
`
`in a different way against accused infringers.’”). Courts have repeatedly acknowledged the
`
`necessity of uniform claim interpretation across both analyses. See SpeedTrack, Inc. v.
`
`WEST\298299817.1
`
`14
`
`

`

`Case 6:21-cv-00916-ADA Document 43 Filed 04/19/22 Page 18 of 27
`
`Amazon.com, 998 F.3d 1373, 1379-80 (Fed. Cir. 2021) (finding prosecution disclaimer arising
`
`from claim amendments and the applicant’s arguments where the earlier arguments contradict
`
`later litigation positions).
`
`Likewise, RFCyber cannot now rewrite its prosecution statements to contradict the very
`
`prior art reference to which they refer. In the related Google case, RFCyber alleged that its
`
`prosecution statements differentiated Atsmon from the ’218 patent because applicant’s inve