Case 6:21-cv-00916-ADA Document 65 Filed 06/07/22 Page 1 of 13
`
`Plaintiff,
`
`IN THE UNITED STATES DISTRICT COURT
`FOR THE WESTERN DISTRICT OF TEXAS
`WACO DIVISION
`§
`
`§
`Case No. 6:21-cv-00916-ADA
`§
`
`JURY TRIAL DEMANDED
`§
`§
`
`§
`§
`§
`§
`§
`§
`
`
`Defendant.
`
`
`
`
`PLAINTIFF RFCYBER CORP.’S
`SUR-REPLY CLAIM CONSTRUCTION BRIEF
`
`
`RFCYBER CORP.,
`
`
`
`
`v.
`
`
`APPLE INC.,
`
`
`
`
`
`
`
`
`

`

`Case 6:21-cv-00916-ADA Document 65 Filed 06/07/22 Page 2 of 13
`
`
`I.
`
`TABLE OF CONTENTS
`
`Page(s)
`
`DISPUTED TERMS ........................................................................................................... 1
`
`A.
`
`B.
`
`C.
`
`D.
`
`E.
`
`“e-purse” / “electronic purse” (identified by both parties) ..................................... 1
`
`“e-purse applet” (identified by Apple) .................................................................... 3
`
`“payment server” (identified by Apple) .................................................................. 4
`
`“security authentication module” / “SAM” (identified by both) ............................ 5
`
`“application” (identified by Apple) ........................................................................ 7
`
`II.
`
`CONCLUSION ................................................................................................................... 8
`
`
`
`
`i
`
`

`

`Case 6:21-cv-00916-ADA Document 65 Filed 06/07/22 Page 3 of 13
`
`TABLE OF AUTHORITIES
`
`Page(s)
`
`Cases
`
`Cordis Corp. v. Boston Sci. Corp.,
`561 F.3d 1319, 1329 (Fed. Cir. 2009) ......................................................................................... 2
`
`RFCyber Corp. v. Google LLC,
`No. 2:20-CV-274-RG, 2021 WL 5357465, at *8 (E.D. Tex. Nov. 17, 2021)............................. 2
`
`U.S. Surgical Corp. v. Ethicon, Inc.,
` 103 F.3d 1554, 1568 (Fed. Cir. 1997) ........................................................................................ 8
`
`
`
`
`
`
`
`ii
`
`

`

`Case 6:21-cv-00916-ADA Document 65 Filed 06/07/22 Page 4 of 13
`
`I.
`
`DISPUTED TERMS
`
`A.
`
`“e-purse” / “electronic purse” (identified by both parties)
`
`Term
`
`RFCyber’s Construction
`
`Apple’s Construction
`
`“e-purse”
`“electronic purse”
`
`“software that stores electronic
`financial information in a local
`device”
`
`
`
`“software that stores
`electronic financial
`information, including
`electronic value, in a local
`portable device”
`
`On its face, Apple’s construction potentially requires that an e-purse always store electronic
`
`value. Apple now backs away from that position to insist it only seeks to impose a requirement
`
`that an e-purse must be capable of storing electronic value. (Reply at 1.) But as explained in
`
`RFCyber’s Responsive Brief, neither the definition of “e-purse” nor the intrinsic evidence compel
`
`such a requirement.
`
`Apple misreads the prosecution history as requiring the capability of storing electronic
`
`value. (Reply at 2.) As RFCyber explained in its Responsive Brief, during prosecution, the
`
`applicants distinguished the e-purse of the invention from an e-wallet that stored financial
`
`information “at the backend.” (Resp. at 8.) By contrast, the e-purse of the invention “describes
`
`about electronic money in a local portable device.” (Id., quoting Ex. 1 at 9.) According to Apple,
`
`however, “the applicant characterized the e-purse ‘in the instant application’ as one that holds
`
`‘electronic money’—that is, value—in a local portable device.” (Reply at 2.)
`
`The applicants never stated that the e-purse “holds” any “value.” Instead, the applicants
`
`explained that the e-purse “describes about electronic money in a local portable device.” (Ex. 1 at
`
`9.) In other words, the e-purse stores information about electronic money locally. Further,
`
`“electronic money” is not synonymous with “electronic value.” Instead, “electronic money” is a
`
`“generic name for the exchange of money through the internet.” (Ex. D at 188, 191.) Thus,
`
`
`
`

`

`Case 6:21-cv-00916-ADA Document 65 Filed 06/07/22 Page 5 of 13
`
`financial information stored locally meets the applicants’ description of an e-purse as “describ[ing]
`
`about electronic money in a local portable device.” There has been no disclaimer of e-purses that
`
`cannot store electronic value. Cordis Corp. v. Boston Sci. Corp., 561 F.3d 1319, 1329 (Fed. Cir.
`
`2009) (“A disclaimer must be ‘clear and unmistakable,’ and unclear prosecution history cannot be
`
`used to limit claims.”); RFCyber Corp. v. Google LLC, No. 2:20-CV-274-RG, 2021 WL 5357465,
`
`at *8 (E.D. Tex. Nov. 17, 2021) (“This prosecution history therefore does not amount to a
`
`definitive statement by the patentee that the term ‘e-purse’ requires money stored locally.”).
`
`Apple misunderstands RFCyber’s explanation that some e-purses can store electronic value
`
`as an admission that all e-purses must have the capability of storing such value. (Reply at 2.)
`
`RFCyber is not arguing here (or anywhere else) that an e-purse must lack the capability to store
`
`value; however, that capability is not required.
`
`The extrinsic evidence is consistent with RFCyber’s construction. As explained in
`
`RFCyber’s Responsive Brief, the definition of e-purse is a “piece of personalised software . . . that
`
`contains, in coded form, such items as credit card information, digital cash. . . .” (Resp. at 7
`
`(quoting Ex. A).) Apple takes that exemplary list of items that may be contained in an e-purse as
`
`a mandatory list of items that must be storeable in an e-purse. (Reply at 2-3.) By Apple’s logic,
`
`an e-purse of the Asserted Patents could not be an e-purse unless it also included “a digital identity
`
`certificate, and standardised shipping information,” as these are also included as possible contents
`
`of an e-purse. (Ex. A at 101.) There is no evidence that one of skill in the art would understand “e-
`
`purse” to be so limited. Indeed, as explained in RFCyber’s Responsive Brief, the ’046 Patent
`
`contains specific claim elements that include a “balance” relating to electronic value. (Resp. at 10.)
`
`If every e-purse had such a requirement, there would be no need to recite those limitations in the
`
`’046 Patent.
`
`2
`
`

`

`Case 6:21-cv-00916-ADA Document 65 Filed 06/07/22 Page 6 of 13
`
`Despite Apple’s protestations (Reply at 3), its construction is highly similar to the
`
`construction Samsung proposed (and the Court rejected) in the Google case. Just as in that case,
`
`Apple seeks to “limit [e-purse] to a specific feature of particular disclosed embodiments.” Google,
`
`2021 WL 5357465, at *9. The Court should reject Apple’s construction and construe “e-purse” as
`
`“software that stores electronic financial information in a local device.”
`
`B.
`
`“e-purse applet” (identified by Apple)
`
`Term
`
`RFCyber’s Construction
`
`Apple’s Construction
`
`“e-purse applet”
`
`
`No construction necessary other than
`“e-purse”
`
`
`
`“[applet] software that stores
`electronic financial
`information, including
`electronic value, in a local
`portable device”
`
`Apple continues to conflate “e-purse applet” with “e-purse.” As RFCyber explained, the
`
`“e-purse applet” is a component that works with the e-purse. (Resp. at 11.) Apple’s construction
`
`is thus needlessly confusing and imposes the requirement that the component applet perform all
`
`the functions of the whole e-purse. Apple’s alternative construction, proposed in its Reply, “applet
`
`software that stores electronic financial information, including electronic value, in a local portable
`
`device,” suffers from the same problems. (Reply at 3.)
`
`Accordingly, to avoid confusing the jury, the Court should adopt RFCyber’s construction.
`
`In the alternative, RFCyber suggests that the Court construe “e-purse applet” as “applet for use
`
`with an e-purse.”
`
`3
`
`

`

`Case 6:21-cv-00916-ADA Document 65 Filed 06/07/22 Page 7 of 13
`
`C.
`
`“payment server” (identified by Apple)
`
`Term
`
`RFCyber’s Construction
`
`Apple’s Construction
`
`“payment server”
`
`
`
`
`Plain and ordinary meaning
`
`“server for payment
`transactions”
`
`“Payment server” is easily understandable and requires no construction; if the Court feels
`
`construction is warranted, it should construe the term as “server for enabling payments.” (Resp. at
`
`14.) RFCyber’s alternative construction, which Apple did not address in its Reply, obviates
`
`Apple’s concerns about “read[ing] the word “payment” out of the term “payment server.’” (See
`
`Reply at 4.)
`
`Apple’s Reply maintains its attenuated position that the Court should construe the term as
`
`“server for payment transactions” and then further limit that construction to a server “capable of
`
`facilitating or processing payments.” (Reply at 4.) Apple provides no new arguments in support of
`
`its construction. (See id. at 4-5)
`
`Instead, Apple merely argues that RFCyber’s construction would read “payment” out of
`
`the claim term. (Reply at 4.) That is simply not true; as RFCyber explained, the payment server
`
`may enable payments, but need not process the payment itself. (Resp. at 13.) In any event,
`
`RFCyber’s alternative construction (“server for enabling payments”) is consistent with the
`
`specification and captures the role of the payment server. (Resp. at 12-14.) Apple’s construction,
`
`by contrast, introduces “transactions” into the term without support.
`
`Apple states that its construction differs from Samsung’s but does not explain how
`
`“processing a payment” is different from “settling a payment.” (Reply at 5.) In any event, there is
`
`no disclosure or requirement that the payment servers of the Asserted Patents “process” any
`
`payments.
`
`4
`
`

`

`Case 6:21-cv-00916-ADA Document 65 Filed 06/07/22 Page 8 of 13
`
`Accordingly, the Court should reject Apple’s construction and afford this term its plain and
`
`ordinary meaning. Alternatively, the Court should construe it as “server for enabling payments.”
`
`D.
`
`“security authentication module” / “SAM” (identified by both)
`
`Term
`
`RFCyber’s Construction
`
`Apple’s Construction
`
`“security
`authentication
`module” / “SAM”
`
`
`“hardware or software module
`containing data necessary to
`authenticate transactions”
`
`“hardware or software
`module containing data to
`authenticate transactions of
`funds or transfer of funds”
`
`Apple first argues that the Parties are in disagreement as to whether the SAM should
`
`
`
`
`
`contain “data necessary to authenticate transactions” or “data to authenticate transactions.” (Reply
`
`at 5-6.) Apple does not explain, in either its opening or reply briefs, the distinction between the
`
`two. (Opening Br. at 18; Reply at 5-6.) To obviate this unnecessary dispute, RFCyber would agree
`
`to a construction without the word “necessary.”
`
`
`
`The Parties’ real dispute lies in whether every SAM must, as Apple argues, contain data
`
`“to authenticate transactions of funds or transfer of funds.” Apple apparently seeks this
`
`construction as a second attempt to import payment/funding limitations into the claims. (See
`
`discussion of “payment server,” supra.) But the specification explains that certain SAMs are used
`
`for transactions that have nothing to do with funds, such as personalizing the e-purse applet. (Resp.
`
`at 14-15.) Personalization is explicitly described as a data transaction. (Id., quoting the ’218 Patent
`
`at 6:62-65 (“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.” (emphasis added)).
`
`Apple cites to 5:18-22 of the ’218 Patent, but that passage is completely consistent with
`
`RFCyber’s construction. (Reply at 6.) That passage states that “In one application in which a card
`
`5
`
`

`

`Case 6:21-cv-00916-ADA Document 65 Filed 06/07/22 Page 9 of 13
`
`issuer provides a SA module 212 that is used to enable and authenticate any transactions between
`
`a card and a corresponding server (also referred to as a payment server).” (’218 Patent at 5:18-22.)
`
`Nothing in that passage requires the SAM to authenticate fund transactions or transfers; indeed, as
`
`discussed above, the payment server is used to personalize the e-purse applet. Apple candidly
`
`admits that it seeks to require additional functionality within the SAM beyond that required by the
`
`claims. (Reply at 6 (“Apple’s construction would require that a SAM contain data to authenticate
`
`transactions of funds or transfers of funds, in addition to whatever other authentication data or
`
`functionality it may include.” (emphasis added)).)
`
`Similarly, the Court should reject Apple’s citation of the PTAB’s high-level and non-
`
`binding description of the SAM. (See id.) As explained in RFCyber’s Responsive Brief, the Board
`
`simply stated that the SAM is “used to enable and authenticate transactions between a card and a
`
`payment server” without discussing funds at all. (Resp. at 15 (quoting Ex. 9).)
`
`Apple finally justifies its construction by noting that it would not “exclude the
`
`authentication of data transactions”—i.e., it would not exclude the actual claimed functionality of
`
`the SAM. (Reply at 6.) Even if true, that does not justify imposing a limitation into the claims.
`
`Accordingly, the Court should reject Apple’s construction and construe “security
`
`authentication module / SAM” as “hardware or software module containing data necessary to
`
`authenticate transactions.
`
`6
`
`

`

`Case 6:21-cv-00916-ADA Document 65 Filed 06/07/22 Page 10 of 13
`
`E.
`
`“application” (identified by Apple)
`
`Term
`
`“application”
`
`
`
`
`RFCyber’s Construction
`
`Apple’s Construction
`
`Plain and ordinary meaning
`
`“software program suitable
`for being executed on a
`portable device”
`
`The term “application” is well understood and a jury can apply it without construction.
`
`(Resp. at 16.) Apple does not seek to clarify this term, but rather to narrow it to manufacture a non-
`
`infringement defense.1
`
`Apple continues to argue that software cannot be an “application” if it is not entirely
`
`complete and “suitable for being executed.” (Reply at 7-8.) But RFCyber explained in its
`
`Responsive Brief that the ’009 Patent uses the term “application” to describe software that requires
`
`other data to execute or function. (Resp. at 16-17.)
`
`In its Reply Brief, Apple states that “RFCyber’s arguments create a temporal impossibility”
`
`because “the applications ‘cannot execute’ without first obtaining additional data but the
`
`applications cannot obtain said data without first executing.” (Reply at 7.) Apple cites no evidence
`
`to support its point, rendering its response mere attorney argument. (See id.) Moreover, Apple’s
`
`reply ignores the claims of the ’009 Patent which explain that the “module” receives the data that
`
`puts the application into an executable state. (E.g., ’009 Patent, 24:22-36.) As discussed in
`
`RFCyber’s Responsive Brief, the specifications describe “applications” that are not suitable for
`
`
`1 In its Reply, Apple admits that the “on a portable device” portion of its construction imports a
`limitation from other claims into at least claim 1 of the ’787 Patent. (Reply at 8 (“[T]he language
`of claim 1 of the ’787 Patent does not overcome the fact that every other disputed claim explicitly
`requires the application to reside on the portable device.”).) Accordingly, RFCyber understands
`that Apple has withdrawn its request for that portion of its construction. (Id. (“Apple would agree
`to a construction of ‘application’ as ‘software program suitable for being executed.’”) To the extent
`Apple continues to seek its construction, the Court should reject it for the reasons stated in
`RFCyber’s Responsive Brief. (Resp. at 17-18.)
`
`7
`
`

`

`Case 6:21-cv-00916-ADA Document 65 Filed 06/07/22 Page 11 of 13
`
`execution without receiving further data, such as a user interface. (Resp. at 16-17 (citing ’009
`
`Patent at 3:32-46, 14:1-19; ’046 Patent at 11:5-10, 12:9-18).) And the specifications specifically
`
`describe certain applications as “executable.” (E.g., ’009 Patent at 14:66-15:1 (describing midlet
`
`as an “executable application”).)
`
`Accordingly, the Court should reject Apple’s construction and afford this term its plain and
`
`ordinary meaning. See U.S. Surgical Corp. v. Ethicon, Inc., 103 F.3d 1554, 1568 (Fed. Cir.
`
`1997) (“Claim construction is a matter of resolution of disputed meanings and technical scope, to
`
`clarify and when necessary to explain what the patentee covered by the claims, for use in the
`
`determination of infringement. It is not an obligatory exercise in redundancy.”)
`
`II.
`
`CONCLUSION
`
`For the reasons set forth above, the Court should adopt RFCyber’s constructions and reject
`
`Apple’s constructions.
`
`Dated: June 7, 2022
`
`
`
`
`
`Respectfully submitted,
`
` /s/ Richard M. Cowell
`Raymond W. Mort, III
`Texas State Bar No. 00791308
`Email: raymort@austinlaw.com
`THE MORT LAW FIRM, PLLC
`100 Congress Avenue, Suite 2000
`Austin, Texas 78701
`Tel/Fax: 512-865-7950
`
`OF COUNSEL:
`
`Alfred R. Fabricant (Admitted Pro Hac Vice)
`NY Bar No. 2219392
`Email: ffabricant@fabricantllp.com
`Peter Lambrianakos (Admitted Pro Hac Vice)
`NY Bar No. 2894392
`Email: plambrianakos@fabricantllp.com
`Vincent J. Rubino, III (Admitted Pro Hac Vice)
`NY Bar No. 4557435
`Email: vrubino@fabricantllp.com
`
`8
`
`

`

`Case 6:21-cv-00916-ADA Document 65 Filed 06/07/22 Page 12 of 13
`
`Richard M. Cowell (Admitted Pro Hac Vice)
`NY Bar No. 4617759
`Email: rcowell@fabricantllp.com
`FABRICANT LLP
`411 Theodore Fremd Avenue,
`Suite 206 South
`Rye, New York 10580
`Telephone: (212) 257-5797
`Facsimile: (212) 257-5796
`
`ATTORNEYS FOR PLAINTIFF
`RFCYBER CORP.
`
`
`9
`
`

`

`Case 6:21-cv-00916-ADA Document 65 Filed 06/07/22 Page 13 of 13
`
`CERTIFICATE OF SERVICE
`
`I hereby certify that on June 7, 2022, I electronically filed the foregoing with the Clerk of
`
`Court using the CM/ECF system, which will send notification of such filing via electronic mail to
`
`all counsel of record. Any other counsel of record will be served by first class U.S. mail.
`
`
`
` /s/ Richard M. Cowell
` Richard M. Cowell
`
`
`
`