throbber
Trials@uspto.gov
`571-272-7822
`
`Paper 23
`Date: January 19, 2024
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`APPLE INC.,
`Petitioner,
`v.
`RFCYBER CORP.,
`Patent Owner.
`
`IPR2022-01239
`Patent 10,600,046 B2
`
`
`
`
`
`
`
`
`
`Before JOSIAH C. COCKS, PATRICK R. SCANLON, and
`KEVIN W. CHERRY, Administrative Patent Judges.
`SCANLON, Administrative Patent Judge.
`
`JUDGMENT
`Final Written Decision
`Determining All Challenged Claims Unpatentable
`35 U.S.C. § 318(a)
`
`
`
`
`
`
`
`

`

`IPR2022-01239
`Patent 10,600,046 B2
`
`INTRODUCTION
`I.
`Apple Inc. (“Petitioner”) challenges claims 1‒5, 12–14, 17, and 18 of
`U.S. Patent No. 10,600,046 B2 (Ex. 1001, “the ’046 patent”), which is
`assigned to RFCyber Corp. (“Patent Owner”). We have jurisdiction under
`35 U.S.C. § 6, and this Final Written Decision is issued pursuant to
`35 U.S.C. § 318(a) and 37 C.F.R. § 42.73. For the reasons that follow, we
`determine that Petitioner has shown by a preponderance of the evidence that
`claims 1‒5, 12–14, 17, and 18 of the ’046 patent are unpatentable.
`A. Procedural History
`Petitioner filed a Petition (Paper 1, “Pet.”) requesting an inter partes
`review of the challenged claims. Patent Owner filed a Preliminary Response
`(Paper 6, “Prelim. Resp.”).
`We instituted a trial as to all challenged claims. Paper 7 (“Decision
`on Institution” or “Dec. Inst.”).
`After institution, Patent Owner filed a Patent Owner Response
`(Paper 11, “PO Resp.”), Petitioner filed a Reply (Paper 15, “Reply”), and
`Patent Owner filed a Sur-reply (Paper 16, “Sur-reply”).
`Petitioner relies on the Declaration of Gerald W. Smith (Ex. 1003)
`and the Supplemental Declaration of Gerald W. Smith (Ex. 1028) in support
`of its contentions. Patent Owner relies on the Declaration of Alfred C.
`Weaver, Ph.D. (Ex. 2001) in support of its contentions.
`An oral hearing was held on October 24, 2023. A transcript of the
`hearing is included in the record. Paper 22 (“Tr.”).
`B. Real Parties in Interest
`Petitioner identifies itself as the real parties in interest. Pet. 69.
`Patent Owner identifies itself as the real party in interest. Paper 5, 1.
`
`2
`
`

`

`IPR2022-01239
`Patent 10,600,046 B2
`
`C. Related Matters
`The parties identify the following proceedings as related matters
`involving the ’046 patent: RFCyber Corp. v. Apple Inc., Case No. 6:21-cv-
`00916-ADA (W.D. Tex.) (the “District Court Case”); and RFCyber Corp. v.
`Visa U.S.A. Inc., Case No. 6:22-cv-00697 (W.D. Tex.). Pet. 69; Paper 5, 1.
`In addition, Petitioner identifies several other matters involving the ’046
`patent that have been dismissed or terminated. Pet. 69–70.
`D. The ’046 Patent
`The ’046 patent, titled “Method and Apparatus for Mobile Payments,”
`issued March 24, 2020, with claims 1–20, and claims priority to several
`applications dating to September 24, 2006. 1 Ex. 1001, codes (45), (54),
`(60), (63), 1:7–9, 25:20–28:31.
`The ’046 patent relates to electronic commerce and, more particularly,
`to settling payments “using a mobile device reading electronic bills or
`invoices off from another mobile device in a near field communication
`range.” Ex. 1001, 1:16‒21. In general, the invention includes a first mobile
`device that generates an electronic invoice and can be part of a point of sale
`(“POS”) machine. Id. at 1:56–58, 2:1–3. The first mobile device is
`embedded with a secure element and executes a software module. Id.
`at 1:57–58, 2:55–59. When the first mobile device is brought to a consumer
`using a second mobile device, the electronic invoice is read wirelessly into
`the second mobile device. Id. at 1:59–63. The second mobile device is a
`
`1 Nevertheless, Petitioner argues that at least claim 1 has an effective filing
`date after March 16, 2013. Pet. 3–5 (citing Google LLC v. RFCyber Corp.,
`PGR2021-00029, Paper 10 at 3–14 (PTAB Sept. 23, 2021). Patent Owner
`does not dispute this contention. See generally Prelim. Resp.; PO Resp.
`Therefore, for purposes of this proceeding, we agree that at least claim 1 has
`an effective filing date after March 16, 2013.
`
`3
`
`

`

`IPR2022-01239
`Patent 10,600,046 B2
`near field communication (“NFC”) device “configured to execute an
`application that communicates with the software module in the first mobile
`device to read the data off from the first mobile device.” Id. at 2:28–30,
`2:65–3:1.
`The user is then able to verify the amount charged and authorize
`payment, after which the second mobile device “communicates with a
`payment gateway or network for payment that is configured to proceed with
`the payment in accordance with a chosen payment method.” Id. at 1:63–67,
`2:61–64. That is, the gateway receives the payment request from the second
`mobile device, verifies the payment request, and sends a payment response
`to the user of the first mobile device after the payment request is processed.
`Id. at 3:17–31.
`Figure 1A of the ’046 patent is reproduced below.
`
`
`
`4
`
`

`

`IPR2022-01239
`Patent 10,600,046 B2
`Figure 1A shows system configuration 100, which is one embodiment
`of the invention. Ex. 1001, 5:29‒30. System configuration 100 includes
`network 102, which provides services by a financial institution to
`electronically transfer money or settle payments. Id. at 5:30–34. Payment
`gateway 104 comprises one or more servers configured to provide an
`application that may be installed on a user’s mobile device. Id. at 5:52–56.
`The application allows a user to authorize payment of an electronic invoice.
`Id. at 5:60–62.
`System configuration 100 also includes POS device 106 at a point of
`sale. Id. at 6:6–7. POS device 106 generates an electronic bill or invoice
`that is loaded onto portable device 108, such as a contactless card or an NFC
`device, which contacts a user’s NFC device. Id. at 6:10–14. In one
`embodiment, “the POS device is a single device embedded with a secure
`element. The single device may be an NFC device that is used to enter
`information to generate an invoice.” Id. at 6:15–18. This device is brought
`to the customer for authorization and payment. Id. at 6:22–23.
`Alternatively, “the POS device includes a stationary device corresponding to
`106 of FIG. 1A and one or more contactless cards corresponding to 108 of
`FIG. 1A.” Id. at 6:23–26. In this case, “[t]he stationary device is used by
`the cash[i]er to enter charging information to generate an invoice. A
`contactless card is loaded with the electronic invoice and brought to the
`customer for authorization and payment.” Id. at 6:26–30.
`Device 110 is a personal NFC device with wallet software. Id. at
`Fig. 1A. Specifically, device 110 “is configured to function as an electronic
`purse or e-purse that may be used to directly settle a charge being displayed
`on a display screen thereof.” Id. at 8:25–28.
`
`5
`
`

`

`IPR2022-01239
`Patent 10,600,046 B2
`To settle a payment, the merchant, such as a waiter or cashier at a
`restaurant, causes POS device 106 to generate an electronic bill that is
`transported to a contactless card. Id. at 7:19–22. The contactless card is
`then presented to the customer who uses his or her mobile device to read the
`contactless card. Id. at 7:24–26. Upon detecting the contactless card in the
`near field, the application on the user’s mobile device reads data pertaining
`to the electronic bill from the contactless card and subsequently displays the
`electronic bill on a screen of the mobile device for the customer to verify.
`Id. at 7:28–33. The customer then chooses a method for settling the bill,
`such as an e-purse already created in the mobile device, cash, traditional
`credit or debit card, and electronic transfer. Id. at 7:46–53.
`When selecting to pay the bill via the e-purse, the customer enters the
`amount to be paid against the bill; the customer may enter more than what is
`being charged in the bill as a tip or gratuity. Id. at 7:57–61. Once the
`customer has entered the total amount to be paid, the application on the
`user’s mobile device sends a payment request to gateway or server 104 for
`processing. Id. at 7:57–61. “[T]he server 104 receives the payment request
`authorized by the consumer and proceeds with the payment request in
`conjunction with the payment network 102,” and “[o]nce the transaction is
`complete or denied, the server 104 sends a notice to the merchant.” Id.
`at 8:17–24.
`
`6
`
`

`

`IPR2022-01239
`Patent 10,600,046 B2
`Figure 6A of the ’046 patent is reproduced below.
`
`
`Figure 6A “is a diagram showing an exemplary architecture, in which
`a portable device is enabled as a mobile POS conducting e-commerce and
`m-commerce.” Ex. 1001, 4:32‒35. Specifically, exemplary architecture 600
`includes portable device 630 that includes baseband 624 and secured
`element 629. Id. at 18:65–19:3. POS manager 623 is installed in baseband
`623, and POS SAM2 628 is installed in secured element 629 to enable
`portable device 630 to act as a mobile POS. Id. at 19:3–6. This
`configuration allows real time transaction 639 to be conducted between
`
`
`2 A “POS SAM” refers to a mobile POS application applet. Ex. 1001,
`18:13–14. Although the acronym “SAM” is not defined in the ’046 patent, it
`appears to refer to a Security Authentication Module. See Ex. 1016, 2.
`
`7
`
`

`

`IPR2022-01239
`Patent 10,600,046 B2
`portable device 630 and e-token enabled device 636, which can be a single
`functional card or a portable device enabled with an e-purse. Id. at 19:7–10.
`Real time transaction 639 can be conducted without the portable
`device connecting to POS transaction server 613, in which case records of
`accumulated offline transactions are uploaded via secured channel 618 to
`POS transaction server 613 for settlement. Id. at 19:14–16, 9:23–27.
`However, portable device 630 may connect to POS transaction servers 613
`over cellular network 520 in certain instances. Id. at 19:16–18.
`E. Challenged Claims
`Petitioner challenges claims 1‒5, 12–14, 17, and 18, of which claims
`1, 12, and 18 are independent. Claim 1, reproduced below, is illustrative.
`1.
`A method for mobile payment, the method comprising:
`causing a mobile device to capture data directly from a
`tag physically presented thereto, wherein the tag receives the
`data directly from a POS device and allows the mobile device
`to capture the data, the data embedded in the tag includes an
`electronic invoice and settlement information with a merchant
`associated with the POS device;
`extracting the electronic invoice from the captured data
`in the mobile device; displaying the electronic invoice on a
`display of the mobile device to show an amount to be paid by a
`user of the mobile device, wherein the mobile device is
`configured to execute an installed application therein to capture
`the data from the tag;
`receiving an entry by the mobile device, the entry
`including the amount for the invoice and optionally an
`additional amount from the user;
`calculating a total amount by adding the additional
`amount to the amount in the electronic invoice;
`generating a payment request in the mobile device in
`response to the electronic invoice after the user has chosen an
`
`8
`
`

`

`IPR2022-01239
`Patent 10,600,046 B2
`electronic purse (e-purse) maintained locally in the mobile
`device;
`displaying the electronic invoice on the display of the
`mobile device for the user to verify the payment request
`verifying the total amount with a balance in the e-purse,
`wherein said verifying the total amount with a balance in the e-
`purse is performed within the mobile device without sending
`the payment request to a payment gateway;
`displaying a denial of the payment request when the
`balance is less than the total amount;
`sending the payment request from the mobile device to
`the payment gateway, wherein the balance is sufficient to honor
`the payment request, the payment gateway sends a message
`directly to the POS device that a monetary transaction per the
`payment request sent from the mobile device has been
`successfully completed; and
`displaying a confirmation in the mobile device that the
`balance in the e-purse has been reduced by the total amount.
`Ex. 1001, 25:20–63.
`F. Instituted Grounds of Unpatentability
`We instituted inter partes review of the challenged claims based on
`the following grounds of unpatentability asserted by Petitioner:3
`Claim(s) Challenged
`35 U.S.C. §
`Reference(s)/Basis
`1–5, 12–14
`103
`Laracey, 4 Jogu,5
`17
`103
`Laracey, Jogu, Tang6
`
`
`3 The Leahy-Smith America Invents Act, Pub. L. No. 112-29, 125 Stat. 284
`(2011) (“AIA”), amended 35 U.S.C. § 103. Because at least one claim of
`the ’046 patent has an effective filing date after March 16, 2013, as
`discussed above in footnote 1, we apply the AIA version of 35 U.S.C. § 103.
`See AIA § 3(n)(1).
`4 US 2011/0251892, published Oct. 13, 2011 (Ex. 1004).
`5 JP 4901053, published Mar. 21, 2012 (Ex. 1005).
`6 WO 2009/116954 A2, published Sept. 24, 2009 (Ex. 1006).
`
`9
`
`

`

`IPR2022-01239
`Patent 10,600,046 B2
`Claim(s) Challenged
`
`18
`Dec. Inst. 22; Pet. 8.
`
`35 U.S.C. §
`103
`
`Reference(s)/Basis
`Laracey, Jogu, Dorsey7
`
`II. ANALYSIS
`A. Legal Standards
`To prevail in its challenge, Petitioner must demonstrate by a
`preponderance of the evidence that the claims are unpatentable. 35 U.S.C.
`§ 316(e) (2018); 37 C.F.R. § 42.1(d) (2022). “In an IPR, the petitioner has
`the burden from the onset to show with particularity why the patent it
`challenges is unpatentable.” Harmonic Inc. v. Avid Tech., Inc., 815 F.3d
`1356, 1363 (Fed. Cir. 2016) (citing 35 U.S.C. § 312(a)(3) (2012) (requiring
`inter partes review petitions to identify “with particularity . . . the evidence
`that supports the grounds for the challenge to each claim”)). This burden of
`persuasion never shifts to the patent owner. See Dynamic Drinkware, LLC
`v. Nat’l Graphics, Inc., 800 F.3d 1375, 1378 (Fed. Cir. 2015) (discussing the
`burden of proof in inter partes review).
`A patent claim is unpatentable under 35 U.S.C. § 103(a) if the
`differences between the claimed subject matter and the prior art are such that
`the subject matter, as a whole, would have been obvious at the time the
`invention was made to a person having ordinary skill in the art to which said
`subject matter pertains. KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 406
`(2007). The question of obviousness is resolved on the basis of underlying
`factual determinations including: (1) the scope and content of the prior art;
`(2) any differences between the claimed subject matter and the prior art;
`(3) the level of ordinary skill in the art; and (4) when in evidence, objective
`
`
`7 US 9,916,581 B2, issued Mar. 13, 2018 (Ex. 1007).
`
`10
`
`

`

`IPR2022-01239
`Patent 10,600,046 B2
`indicia of non-obviousness (also called secondary considerations), such as
`commercial success, long-felt but unsolved needs, and failure of others.
`Graham v. John Deere Co., 383 U.S. 1, 17–18 (1966). We analyze grounds
`based on obviousness in accordance with the above-stated principles.8
`B. Level of Ordinary Skill in the Art
`In determining whether an invention would have been obvious at the
`time it was made, 35 U.S.C. § 103 requires us to resolve the level of
`ordinary skill in the pertinent art at the time of the effective filing date of the
`claimed invention. Graham, 383 U.S. at 17. The person of ordinary skill in
`the art is a hypothetical person who is presumed to have known the relevant
`art. In re GPAC, Inc., 57 F.3d 1573, 1579 (Fed. Cir. 1995). Factors that
`may be considered in determining the level of ordinary skill in the art
`include, but are not limited to, the types of problems encountered in the art,
`the sophistication of the technology, and educational level of active workers
`in the field. Id. In a given case, one or more factors may predominate. Id.
`Petitioner contends that a person having ordinary skill in the art
`“would have had at least a bachelor’s degree in computer science, computer
`engineering, or equivalent with at least one year of experience in the field of
`mobile payments,” and “[a]dditional education or experience might
`substitute for the above requirements.” Pet. 6–7 (citing Ex. 1003 ¶¶ 34–35).
`Patent Owner does not address the level of ordinary skill in its Response.
`Based on our review of the record before us, we determine that
`Petitioner’s stated level of ordinary skill in the art is reasonable because it
`appears consistent with the evidence of record, including the asserted prior
`
`
`8 The record does not include any evidence of objective indicia of non-
`obviousness.
`
`11
`
`

`

`IPR2022-01239
`Patent 10,600,046 B2
`art. Accordingly, for the purposes of this Decision, we adopt Petitioner’s
`definition.
`
`C. Claim Construction
`In inter partes reviews, the Board interprets claim language using the
`district-court-type standard, as described in Phillips v. AWH Corp., 415 F.3d
`1303 (Fed. Cir. 2005) (en banc). See 37 C.F.R. § 42.100(b). Under that
`standard, we generally give claim terms their ordinary and customary
`meaning, as would be understood by a person of ordinary skill in the art at
`the time of the invention, in light of the language of the claims, the
`specification, and the prosecution history. See Phillips, 415 F.3d at
`1313–14. Although extrinsic evidence, when available, may also be useful
`when construing claim terms under this standard, extrinsic evidence should
`be considered in the context of the intrinsic evidence. See id. at 1317–19.
`Petitioner contends that, in the District Court Case, the parties have
`agreed to construe the claim term “payment gateway” as a “server or
`collection of servers for settling a payment.” Pet. 9 (citing Ex. 1016, 2).
`Petitioner further contends that the parties are disputing the constructions of
`the claim terms “e-purse,” e-purse applet,” and “application” in the District
`Court Case, but the differences between the proposed constructions need not
`be resolved for this proceeding because its asserted grounds of
`unpatentability satisfy both Patent Owner’s and Petitioner’s proposed
`constructions.9 Id. at 9–10 (citing Ex. 1016, 4–5). Petitioner, however,
`applies its proposed construction in its arguments. See Pet. 29.
`
`
`9 In the District Court Case, Petitioner proposed that “e-purse” should be
`construed as “software that stores electronic financial information, including
`electronic value, in a local portable device,” while Patent Owner proposed
`
`12
`
`

`

`IPR2022-01239
`Patent 10,600,046 B2
`In its Response, Patent Owner contends that its proposed construction
`was adopted in the District Court Case, as well as in another proceeding in
`the Eastern District of Texas. PO Resp. 11 (citing RFCyber Corp. v. Google
`LLC, No. 2:20-cv-274-JRG, 2021 WL 5357465, at *6-*9 (E.D. Tex.
`Nov. 17, 2021); RFCyber Corp. v. Apple Inc., No. 6:21-cv-00916-ADA,
`Dkt. 100 (W.D. Tex. Sep. 13, 2022)). Patent Owner argues that because the
`parties agree that an e-purse must be “software” that “stores financial
`information in a local device,” “[t]he Board need not resolve the distinction
`between the parties’ proposals for this proceeding because Petitioner fails to
`show that Laracey discloses ‘an electronic purse (e-purse) maintained locally
`in the mobile device’ under the agreed portions of the construction.” Id. at
`11–12.
`We agree that the differences between the two proposed constructions
`are minimal. On the full record before us, however, Petitioner does not
`explain sufficiently why the proper construction of “e-purse” requires that
`the stored financial information include electronic value and that the
`software is in a local portable device. Therefore, we adopt the district
`court’s construction of “e-purse” as “software that stores electronic financial
`information in a local device” for purposes of this Decision.
`D. Ground 1: Asserted Obviousness Based on Laracey and Jogu
`Petitioner asserts that claims 1–5 and 12–14 are unpatentable under
`35 U.S.C. § 103 based on Laracey and Jogu. Pet. 10–54. Patent Owner
`provides arguments addressing this asserted ground of unpatentability.
`
`
`that “e-purse” should be construed as “software that stores electronic
`financial information in a local device.” Ex. 1016, 4.
`
`13
`
`

`

`IPR2022-01239
`Patent 10,600,046 B2
`PO Resp. 13–32. We first summarize the references and then address the
`parties’ contentions.
`
`1. Laracey
`Laracey, titled “Mobile Phone Payment Processing Methods and
`Systems,” was published on October 13, 2011. Ex. 1004, codes (54), (43).
`Laracey relates to “using mobile devices to conduct payment transactions at
`merchant locations including brick and mortar locations and remote
`locations as well as for person to person transactions.” Id., code (57).
`Figure 1 of Laracey is reproduced below.
`
`
`Figure 1 is a block diagram depicting payment system 100. Ex. 1004 ¶¶ 7,
`27. A user, referred to as the customer, uses mobile device 102 (such as a
`mobile telephone) to conduct a purchase transaction with merchant 108.
`Id. ¶ 27. For a point-of-sale purchase, merchant 108 totals the items to be
`purchased and prompts the customer to select a payment option, such as the
`mobile payment option disclosed by Laracey. Id. ¶ 28. Alternatively, rather
`
`14
`
`

`

`IPR2022-01239
`Patent 10,600,046 B2
`than requiring the customer to select the mobile payment option, the choice
`can be made by the customer scanning, capturing, or entering a checkout
`identifier. Id. ¶ 29. When the mobile payment option is selected, merchant
`108 transmits a merchant payment authorization request message to
`transaction management system 130 via path 116. Id. ¶ 30. This message
`may include a merchant identifier, the amount due, and a unique checkout
`token. Id.
`The customer, either before or after selecting the mobile payment
`option, performs an authentication process to confirm their identity and
`authority to conduct transaction via the mobile payment process. Id. ¶ 33.
`“After a successful authentication process, the customer is prompted to scan,
`capture (or otherwise enter) a checkout token from a device associated with
`the merchant 108 (shown as interaction 112 between the mobile device 102
`and the merchant 108).” Id. ¶ 35. Mobile device 102 then transmits the
`checkout token to transaction management system 130 in a customer
`transaction lookup request message via path 114. Id. The checkout token
`can be either a static or dynamic token. Id. ¶ 36.
`When a static token is used, transaction management system 130
`matches information in the customer transaction lookup request with
`information in the merchant payment authorization request. Id. Upon
`finding a match, transaction management system 130 transmits a transaction
`detail message to mobile device 102 via path 114 that provides the customer
`with details about the transaction. Id. When a dynamic token is used,
`checkout processing may proceed without a customer transaction lookup
`request message being transmitted to transaction management system 130.
`Id. ¶ 38.
`
`15
`
`

`

`IPR2022-01239
`Patent 10,600,046 B2
`Next, the customer causes a customer payment authorization request
`message to be submitted from mobile device 102 to transaction management
`system 130. Id. ¶ 39. Transaction management system 130 then sends an
`authorization approval request message to one or more payment processing
`networks for the authorization, clearing, and settlement of funds for the
`transaction. Id. ¶ 40.
`
`2. Jogu
`Jogu relates to a payment method using a mobile phone, and, more
`specifically, a service that mediates payments at virtual stores and brick-and-
`mortar stores on the Internet. Ex. 1005, 3. In one embodiment, a user orders
`a product or service from virtual store 24 using mobile phone 13 and selects
`the mobile phone payment method. Id. at 5, Fig. 5. Upon receiving the
`billing request, mobile phone company 10 either notifies virtual store 24 that
`the service cannot be used if there is a problem with the user’s status, or
`sends an electronic invoice to mobile phone 13 if there is no problem with
`the user’s status. Id. at 5–6. When the user approves payment of the
`invoice, mobile phone 13 verifies the prepaid balance and, if the prepaid
`balance is less than the payment amount, notifies mobile phone company 10
`that the payment cannot be made due to insufficient balance. Id. at 6. On
`the other hand, if the prepaid balance is more than the payment amount,
`mobile phone company 10 is notified that the payment is approved. Id.
`3. Independent Claims 1 and 12
`Petitioner contends that the proposed combination of Laracey and
`Jogu discloses each limitation of claims 1 and 12. Pet. 14–47, 52–54. To
`support its arguments, Petitioner identifies certain passages in the cited
`references and explains the significance of each passage with respect to the
`corresponding claim limitation. Id. Petitioner also articulates reasons that
`
`16
`
`

`

`IPR2022-01239
`Patent 10,600,046 B2
`one of ordinary skill in the art allegedly would have been motivated to
`implement Jogu’s balance check and update processes in Laracey’s mobile
`device with a reasonable expectation of success. Id. at 40–42, 53; see also
`id. at 46–47 (asserting reasons to modify Laracey to display a confirmation
`of a balance reduction on the mobile device as taught by Jogu).
`Patent Owner argues that Laracey does not disclose or render obvious
`an “e-purse” that is “maintained locally in the mobile device” as required by
`claims 1 and 12. PO Resp. 13–28. Patent Owner also argues that the
`proposed combination fails to satisfy verifying the e-purse balance, as
`required by claims 1 and 12, because one of ordinary skill in the art would
`not combine Laracey and Jogu in the manner proposed. Id. at 28–32.
`The “E-purse” Limitation
`a)
`Claims 1 and 12 both recite “an electronic purse (e-purse) maintained
`locally in the mobile device.” Ex. 1001, 25:42–43, 27:1–3. In addressing
`this limitation, Petitioner argues that Laracey discloses a mobile device
`equipped with software that satisfies Petitioner’s construction of “e-purse.”10
`Pet. 29 (citing Ex. 1004 ¶ 16). More specifically, Petitioner argues that one
`of ordinary skill in the art “would have understood that Laracey’s ‘stored
`value’ account is an e-purse that stores electronic financial information,
`including electronic value, as claimed.” Id. at 29–30 (citing Ex. 1003 ¶¶ 98–
`101). Petitioner argues further that Laracey also discloses displaying stored
`value account balances on the mobile device. Id. at 30–31 (citing Ex. 1004
`¶¶ 93, 165, Fig. 8B; Ex. 1003 ¶ 101).
`
`
`10 Mr. Smith testifies that Petitioner’s analysis satisfies both Patent Owner’s
`and Petitioner’s constructions of “e-purse.” Ex. 1003 ¶ 98.
`
`17
`
`

`

`IPR2022-01239
`Patent 10,600,046 B2
`Mr. Smith testifies that “a stored value account was well known prior
`to the ’046 patent and was commonly stored in a form of secured memory
`and contained data representing an amount of money (i.e., electronic value)
`that could be used for a purchase transaction and funded.” Ex. 1003 ¶ 100;
`see also id. ¶¶ 50–60 (describing background technology relating to mobile
`payments and stored value accounts). In addition, Mr. Smith testifies that
`“Laracey’s stored value account would have been understood to be software
`located in memory within a mobile device that contained financial
`information including data representing an amount of money (e.g., a
`balance) useable for purchases.” Id. ¶ 100.
`As discussed above, we construe “e-purse” for purposes of this
`Decision as “software that stores electronic financial information in a local
`device.” See supra § II.C. Patent Owner contends that Laracey does not
`disclose an e-purse satisfying this construction for two reasons. First, Patent
`Owner argues that neither Petitioner nor Mr. Smith have shown that
`Laracey’s stored value account, particularly the “PetPlace…3518” account
`depicted in Figure 8B, is software. PO Resp. 14 (citing Pet. 29–31;
`Ex. 1003 ¶ 101; Ex. 2003, 67:11–68:12). Instead, relying on the testimony
`of Dr. Weaver, Patent Owner asserts that a customer account “is simply a
`visualization of a collection of information,” and one of ordinary skill in the
`art would not recognize it as software. Id. (citing Ex. 2001 ¶ 56); see also
`Sur-reply 2 (making the same argument). Patent Owner also argues that “the
`concept of a stored value account is not software either.” PO Resp. 15
`(citing Ex. 2001 ¶ 56).
`In the Reply, Petitioner contends that neither Patent Owner nor
`Dr. Weaver disputes that Laracey’s mobile device uses software for its
`transaction functionality. Reply 20 (citing Ex. 1029, 60:19–24). Patent
`
`18
`
`

`

`IPR2022-01239
`Patent 10,600,046 B2
`Owner responds by arguing that the Petition identifies Laracey’s stored
`value account—not its transaction functionality—as the claimed e-purse.
`Sur-reply 1 (citing Pet. 29; PO Resp. 14). Patent Owner asserts that
`“Petitioner’s late attempt to backfill its Petition” should be rejected. Id.
`at 1–2 (citing MModal LLC v. Nuance Commc’ns, 846 F. App’x 900, 906-07
`(Fed. Cir. 2021); Apple Inc. v. UUSI, LLC, No. 2021-1035, 2023 WL
`3071643, at *3 (Fed. Cir. Apr. 25, 2023)).
`We agree with Petitioner that the Petition does “not rely solely and
`exclusively on the account balance in isolation.” See Tr. 11:17–20.
`Specifically, the Petition asserts that “Laracey teaches that its mobile device
`is equipped with software that satisfies [Petitioner’s] construction. Namely,
`Laracey’s ‘mobile device can be used to initiate and conduct payment
`transactions involving a number of different payment accounts, including,
`for example, credit, debit, deposit, stored value, checking and other
`accounts.’” Pet. 29 (quoting Ex. 1004 ¶ 16). Thus, Petitioner relies not
`only on Laracey’s disclosure of a stored value account, but also on Laracey’s
`disclosure of using a mobile device to initiate and conduct payment
`transactions. As for the subsequent assertion on page 29 of the Petition that
`one of ordinary skill in the art “would have understood that Laracey’s
`‘stored value’ account is an e-purse that stores electronic financial
`information, including electronic value,” we agree with Petitioner that this
`assertion is intended to show that Laracey’s software satisfies the portion of
`the claim construction that requires storing financial information. See
`Tr. 12:1–5. We are not persuaded that this assertion is intended to identify
`Laracey’s stored value account solely as the claimed e-purse. For these
`reasons, we disagree with Patent Owner’s assertion that Petitioner
`improperly raises a new argument in its Reply.
`
`19
`
`

`

`IPR2022-01239
`Patent 10,600,046 B2
`Furthermore, we agree that Laracey discloses mobile devices that use
`software to conduct payment transactions. See Pet. 29 (Petitioner asserting
`Laracey’s mobile device is equipped with software for initiating and
`conducting payment transactions); see also Ex. 1029, 60:19–24 (Dr. Weaver
`agreeing that Laracey’s mobile device executes software to perform its
`transaction functionality). For instance, Laracey discloses that its invention
`relates to “systems, methods, processes, computer program code, and means
`for using mobile devices to conduct payment transactions.” Ex. 1004 ¶ 16
`(emphasis added); see also id. ¶ 17 (describing providing computer program
`code for conducting payment transactions). Laracey also discloses one
`example of mobile phone that has a web browser for accessing and using the
`payment system and another example of mobile phone that accesses and
`uses the payment system via “an iPhone® application (or ‘app’) configured
`to facilitate payment transactions” that has been downloaded to the phone.
`Id. ¶ 24. In addition, Laracey discloses that “mobile device 202 may operate
`a payment application allowing mobile device 202 to operate as a payment
`device” and “[t]he mobile payment application may be an ‘app’ or computer
`program code stored on the mobile device 202.” Id. ¶¶ 46, 91. In view of
`these disclosures, we determine that Laracey discloses using software stored
`on a mobile device for conducting payment transactions with the mobile
`device.
`Moreover, even if assuming for the sake of argument that the Petition
`does rely on Laracey’s stored value account alone as the claimed e-purse, we
`disagree that Petitioner has not shown sufficiently that Laracey’s stored
`value account is software. As noted above, Mr. Smith testifies that “a stored

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket