`571-272-7822
`
`Paper 10
`Entered: July 24, 2024
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`GOOGLE LLC,
`Petitioner,
`
`v.
`
`PROXENSE, LLC,
`Patent Owner.
`____________
`
`IPR2024-00233
`Patent 8,886,954 B1
`____________
`
`
`Before THU A. DANG, KEVIN F. TURNER, and DAVID C. McKONE,
`Administrative Patent Judges.
`
`
`MCKONE, Administrative Patent Judge.
`
`
`DECISION
` Granting Institution of Inter Partes Review
`35 U.S.C. § 314
`
`
`
`
`
`
`
`
`
`IPR2024-00233
`Patent 8,886,954 B1
`
`I.
`INTRODUCTION
`A. Background and Summary
`Google LLC (“Petitioner”) filed a Petition (Paper 1, “Pet.”) requesting
`inter partes review of claims 1–7, 10, 12–19, and 22–27 of U.S. Patent
`No. 8,886,954 B1 (Ex. 1001, “the ’954 patent”). Pet. 5. Proxense, LLC
`(“Patent Owner”) filed a Preliminary Response (Paper 6, “Prelim. Resp.”).
`With our authorization, Petitioner filed a Preliminary Reply (Paper 7,
`“Prelim. Reply”) and Patent Owner filed a Preliminary Sur-reply (Paper 9,
`“Prelim. Sur-reply”).
`We have authority to determine whether to institute an inter partes
`review. See 35 U.S.C. § 314 (2016); 37 C.F.R. § 42.4(a) (2020). The
`standard for instituting an inter partes review is set forth in 35 U.S.C.
`§ 314(a), which provides that an inter partes review may not be instituted
`“unless . . . there is a reasonable likelihood that the petitioner would prevail
`with respect to at least 1 of the claims challenged in the petition.” For the
`reasons explained below, we institute an inter partes review of the ’954
`patent.
`
`
`B. Related Matters
`The parties advise us that the ’954 patent is involved in two district
`court cases, including Proxense, LLC v. Google LLC, No. 6.23-CV-00320
`(W.D. Tex.) (“the Texas case”). Pet. 70; Paper 4, 2. Petitioner also has filed
`petitions for inter partes review of patents related to the ’954 patent,
`including IPR2024-000232 (challenging U.S. Patent No. 8,352,730 B2 (“the
`’730 patent”)) and IPR2024-00234 (challenging U.S. Patent No. 9,298,905
`B1 (“the ’905 patent”)). Patent Owner states that patents related to
`the ’954 patent are the subject of ex parte reexaminations in Application
`
`2
`
`
`
`IPR2024-00233
`Patent 8,886,954 B1
`No. 90/015,052, reexamining the ’730 patent, Application No. 90/015,053,
`reexamining the ’905 patent, and Application No. 90/015,054, reexamining
`U.S. Patent No. 10,698,989. Prelim. Resp. 14.
`
`C. The ’954 Patent
`The ’954 patent discloses systems for “authentication responsive to
`biometric verification of a user being authenticated,” using “an integrated
`device [that] includes a persistent storage to persistently store[] a code such
`as a device identifier (ID) and biometric data for a user in a tamper-resistant
`format.” Ex. 1001, 1:60–65. The ’954 patent states that “[c]onventional
`user authentication techniques,” such as requiring input of a password, were
`deficient because they “require[d] the user to memorize or otherwise keep
`track of the credentials” and “it can be quite difficult to keep track of them
`all.” Id. at 1:26–35. Other techniques, such as “provid[ing] the user with an
`access object . . . that the user can present to obtain access,” were inadequate
`because “authentication merely proves that the access object itself is valid; it
`does not verify that the legitimate user is using the access object.” Id. at
`1:36–46. According to the ’954 patent, there was a need in the art for a
`system for “verifying a user that is being authenticated that does not suffer
`from [such] limitations” and “ease[s] authentications by wirelessly providing
`an identification of the user.” Id. at 1:52–56.
`
`3
`
`
`
`IPR2024-00233
`Patent 8,886,954 B1
`Figure 2 of the ’954 patent is reproduced below.
`
`
`
`Figure 2 is a block diagram of the functional modules of a biometric key.
`Id. at 3:28–30. Enrollment module 222 registers a user with biometric
`key 100 by persistently storing biometric data associated with the user (e.g.,
`a digital image of the retina, fingerprint, or voice sample) in persistent
`storage 226. Id. at 4:64–5:21. Enrollment module 222 registers biometric
`key 100 with a trusted authority by providing a code, such as a device ID, to
`the trusted authority or, alternatively, the trusted authority can provide a
`code to biometric key 100. Id. at 5:1–5. The code is stored in persistent
`storage 226. Id. at 5:36–38. “Persistent storage 226 is itself, and stores data
`in, a tamper-proof format to prevent any changes to the stored data.” Id. at
`5:29–31. “Tamperproofing increases reliability of authentication because it
`does not allow any changes to biometric data (i.e., allows reads of stored
`data, but not writes to store new data or modify existing data).” Id. at
`5:31–34. In a fingerprint embodiment, validation module 224 uses scan
`pad 120 (shown in Figure 1) to capture scan data from the user’s fingerprint
`
`4
`
`
`
`IPR2024-00233
`Patent 8,886,954 B1
`and compares the scanned data to the stored fingerprint to determine whether
`the scanned data matches the stored data. Id. at 5:6–15.
`The interaction of biometric key 100 with other system components is
`illustrated in Figure 3, reproduced below.
`
`Figure 3 is “a block diagram illustrating a system for providing
`authentication information for a biometrically verified user.” Id. at 3:31–33.
`Authentication module 310 is coupled to biometric key 100 via line 311 (a
`wireless medium) and with trusted key authority 320 via line 312 (a secure
`
`
`
`5
`
`
`
`IPR2024-00233
`Patent 8,886,954 B1
`data network such as the Internet). Id. at 6:1–5. Authentication module 310
`requires the device ID code (indicating successful biometric verification)
`from biometric key 100 before allowing the user to access application 330.
`Id. at 6:5–11. Authentication module 310 provides the device ID code from
`biometric key 100 to trusted key authority 320 to verify that it belongs to a
`legitimate key. Id. at 6:11–14; see also id. at 6:37–43 (“In one embodiment,
`trusted key authority 320 verifies that a code from a biometric key is
`legitimate. To do so, the trusted key authority 320 stores a list of codes for
`legitimate biometric keys . . . . In one embodiment, trusted key authority
`320 can also store a profile associated with a biometric key.”).
`Authentication module 310 then sends a message to application 330 to allow
`the user access to the application responsive to a successful authentication
`by trusted key authority 320. Id. at 6:15–17.
`“Application 330 can be, for example, a casino machine, a keyless
`lock, a garage door opener, an ATM machine, a hard drive, computer
`software, a web site, a file, . . . and the like.” Id. at 6:19–24. Trusted key
`authority 320 can be operated by an agent, such as “a government official, a
`notary, and/or an employee of a third party which operates the trusted key
`authority, or another form of witness.” Id. at 7:30–33. “The agent can
`follow standardized procedures such as requiring identification based on a
`state issued driver license, or a federally issued passport in order to establish
`a true identity of the user.” Id. at 7:33–36.
`Claim 1, reproduced below,1 is illustrative of the claimed subject
`matter:
`
`
`1 We add bracketed alphanumeric characters corresponding to those
`Petitioner uses in the Petition.
`
`6
`
`
`
`IPR2024-00233
`Patent 8,886,954 B1
`1.
`A method comprising:
`[1ai] persistently storing biometric data of a user and
`[1aii] a plurality of codes and other data values
`comprising a device ID code uniquely identifying
`an integrated device and [1aiii] a secret decryption
`value in a tamper proof format written to a storage
`element on the integrated device that is not capable
`of being subsequently altered;
`[1b] responsive to receiving a request for a biometric
`verification of the user, receiving scan data from a
`biometric scan;
`[1c] comparing the scan data to the biometric data to
`determine whether the scan data matches the
`biometric data;
`[1d] responsive to a determination that the scan data
`matches the biometric data, wirelessly sending one
`or more codes and other values from the plurality
`of codes and other data values for authentication to
`a third party that operates a trusted authority,
`wherein the one or more codes and other data
`values includes the device ID code; and
`[1e] receiving, at an application, an access message from
`the trusted authority indicating that the trusted
`authority successfully authenticated the one or
`more codes and other data values sent to the third
`party and allowing the user access to the
`application.
`
`
`
`D. Evidence
`Petitioner relies on the references listed below.
`Name
`Reference
`Date
`
`Ludtke
`
`Kon
`
`US 7,188,110 B1
`
`Mar. 6, 2007 (filed
`Dec. 11, 2000)
`US 2002/0046336 A1 Apr. 18, 2002
`
`Exhibit
`No.
`1005
`
`1006
`
`7
`
`
`
`IPR2024-00233
`Patent 8,886,954 B1
`Petitioner also relies on the Declaration of Stephen Gray (Ex. 1003).
`
`E. The Asserted Grounds
`Petitioner asserts the following grounds of unpatentability (Pet. 1):
`Reference(s)
`35 U.S.C. §
`Claim(s) Challenged
`1, 2, 4–7, 10, 12, 13,
`15, 16, 18, 19, 22–27
`
`§ 103(a)2
`
`Ludtke
`
`Ludtke, Kon
`
`
`§ 103(a)
`
`3, 14, 17
`
`II. ANALYSIS
`
`A. Claim Construction
`We construe a claim
`using the same claim construction standard that would be used
`to construe the claim in a civil action under 35 U.S.C. 282(b),
`including construing the claim in accordance with the ordinary
`and customary meaning of such claim as understood by one of
`ordinary skill in the art and the prosecution history pertaining to
`the patent.
`37 C.F.R. § 42.100(b) (2019); see also Phillips v. AWH Corp., 415 F.3d
`1303 (Fed. Cir. 2005) (en banc).
`Petitioner observes that “device ID code” and “access message” have
`been construed previously in district court litigation. Pet. 4 (citing Ex. 1009,
`3; Ex. 1010, 15, 20). Nevertheless, Petitioner argues that no claim terms
`need to be construed. Id. Patent Owner requests that we adopt previous
`constructions of “device ID code,” “access message,” and “third-party
`
`
`2 The Leahy-Smith America Invents Act, Pub. L. No. 112-29, 125 Stat. 284
`(2011) (“AIA”), amended 35 U.S.C. § 103. Because the ’954 patent has an
`effective filing date before the effective date of the relevant provision of the
`AIA, we cite to the pre-AIA version of § 103.
`
`8
`
`
`
`IPR2024-00233
`Patent 8,886,954 B1
`trusted authority,” construed by the District Court and by the Board in inter
`partes review institution decisions for related patents. Prelim. Resp. 2–5.
`
`1. Third party that operates a trusted authority
`Independent claims 1, 12, 16, and 22 each recite “a third party that
`operates a trusted authority.” The ’730 patent, a parent of the ’954 patent,
`was the subject of Samsung Electronics America, Inc. v. Proxense LLC,
`IPR2021-01444 (PTAB) (institution denied). See Ex. 1007 (IPR2021-
`01444, Paper 11 (PTAB Feb. 28, 2022) (“Samsung DDI”)). In the Samsung
`DDI, the Board construed “third-party trusted authority” to mean “a trusted
`authority that is an entity separate from the parties to a transaction.”
`Ex. 1007, 15. Patent Owner appears to contend that “third party that
`operates a trusted authority,” recited in the ’954 patent claims, has the same
`meaning as “third-party trusted authority,” recited in the ’730 patent claims.
`Petitioner does not appear to dispute this. For purposes of this Decision, we
`treat these terms as equivalent.
`In the Samsung DDI, the Board found that “[t]he plain meaning of
`‘third-party trusted authority’ suggests an entity or party separate from the
`principal parties to a transaction.” Id. at 14 (citing third party, THE
`AMERICAN HERITAGE COLLEGE DICTIONARY 1433 (4th ed. 2004) (“2. One
`other than the principals involved in a transaction.”) (Ex. 3002 in IPR2021-
`01444)). The Samsung DDI panel further found that the ’730 patent’s
`specification supported its construction, and noted that it included examples
`of “a government official, a notary, and/or an employee of a third party
`which operates the trusted key authority, or another form of witness.” Id. at
`14–15 (quoting the ’730 patent’s equivalent statement found in Ex. 1001,
`7:30–33). The panel further observed that the applicant’s statements during
`
`9
`
`
`
`IPR2024-00233
`Patent 8,886,954 B1
`prosecution were also “consistent with a third-party trusted authority being
`an entity separate from the principal parties to a transaction.” Id. at 15; see
`also Ex. 1002, 84; IPR2024-00232, Ex. 1002, 366–67, 440–42 (prosecution
`history of related ’730 patent).
`Patent Owner contends that the Samsung DDI provided “further
`clarity as to the meaning of its constructions when evaluating the then-
`asserted prior art,” specifically, Lapsley (Exhibit 1007 in IPR2021-01444,
`introduced here as Ex. 3001). Prelim. Resp. 4–5. As we understand Patent
`Owner’s position, Patent Owner contends that the Samsung DDI
`distinguished a third-party trusted authority from an “active participant,” or
`any entity that participates in a transaction, and limited a third-party trusted
`authority to an entity that “takes on a witness role.” Id. at 5.
`In the Samsung DDI, the panel determined that Samsung had not
`explained sufficiently what the component it identified as a third-party
`trusted authority was a third party relative to or what application Lapsley’s
`user was being permitted to access. Ex. 1007, 26–27. As Samsung
`presented it, the resource it identified as the third-party trusted authority
`appeared to be the resource accessed. Id. However, the panel’s preliminary
`evaluation of the evidence in that proceeding did not find expressly that such
`resource was not a third-party trusted authority; rather, it found that
`Samsung’s presentation of evidence was not sufficient to show that it was a
`third-party trusted authority. Id. In any case, the panel did not purport to
`clarify or further construe the term “third-party trusted authority.” Id.
`The Samsung DDI does not provide a basis for further limiting a
`“third-party trusted authority,” or “third party that operates a trusted
`authority,” to exclude any active participant in a transaction. This would
`exclude the trusted key authority of the preferred embodiments of the ’954
`
`10
`
`
`
`IPR2024-00233
`Patent 8,886,954 B1
`patent, which actively participates in a transaction, for example by receiving
`a request for authentication with a code, determining whether the code is
`valid, authenticating the code, and transmitting an access code to the
`requester, which allows a user access to an application. Ex. 1001, 8:5–17,
`Fig. 7. Although the trusted key authority in this example is not a principal
`party to the transaction (here, those parties are the user and the application),
`it is an active participant in facilitating the transaction. In another preferred
`embodiment of the ’954 patent, trusted key authority 320 plays an active role
`in transactions, e.g., verifying to a grocery store that a biometric key
`presented by a customer is legitimate, thereby allowing the transaction to
`proceed. Id. at 6:37–51, Figs. 3–4. However, despite the trusted key
`authority’s active participation, the parties to such a transaction are the
`customer and the grocery store, not trusted key authority 320. The “witness”
`role mentioned in the Specification (Ex. 1001, 7:30–33) refers to an agent’s
`relationship to the principal parties to the transaction, not to the level of
`activity the agent engages in. See id. at 7:27–59, Fig. 5 (describing activities
`of an agent).
`Patent Owner’s proposed clarifications, or modifications, to the
`Samsung DDI’s construction of “third-party trusted authority,” which would
`exclude these embodiments, are presumptively incorrect. See Sequoia Tech.,
`LLC v. Dell, Inc., 66 F.4th 1317, 1327 (Fed. Cir. 2023) (The Federal Circuit
`“recognize[s] that ‘[a] claim construction exclud[ing] a preferred
`embodiment is rarely, if ever correct.’” (quoting Kaufman v. Microsoft
`Corp., 34 F.4th 1360, 1372 (Fed. Cir. 2022) (second and third alterations in
`original)). Indeed, Patent Owner’s view would transform any entity that is
`accessed for any reason in a transaction into a party to that transaction, thus
`excluding it from the scope of a “third party that operates a trusted
`
`11
`
`
`
`IPR2024-00233
`Patent 8,886,954 B1
`authority.” Patent Owner, however, has advanced no persuasive support for
`such a narrow reading of the claims.
`Accordingly, we adopt the Samsung DDI’s construction without
`Patent Owner’s modifications. On the current record, a “third party that
`operates a trusted authority” is “a trusted authority that is an entity separate
`from the parties to a transaction.”
`
`2. Remaining claim terms
`Based on the preliminary record, we do not find it necessary to
`provide express claim constructions for any other terms. See Nidec Motor
`Corp. v. Zhongshan Broad Ocean Motor Co., 868 F.3d 1013, 1017
`(Fed. Cir. 2017) (noting that “we need only construe terms ‘that are in
`controversy, and only to the extent necessary to resolve the controversy’”)
`(quoting Vivid Techs., Inc. v. Am. Sci. & Eng’g, Inc., 200 F.3d 795, 803
`(Fed. Cir. 1999)).
`
`B. Obviousness of Claims 1, 2, 4–7, 10, 12, 13, 15, 16, 18, 19, and 22–
`27 over Ludtke
`Petitioner contends that claims 1, 2, 4–7, 10, 12, 13, 15, 16, 18, 19,
`and 22–27 would have been obvious over Ludtke. Pet. 8–58. For the
`reasons given below, Petitioner has made a sufficient showing.
`A claim is unpatentable under 35 U.S.C. § 103 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.” We resolve the question of obviousness on the basis of
`underlying factual determinations, including (1) the scope and content of the
`
`12
`
`
`
`IPR2024-00233
`Patent 8,886,954 B1
`prior art; (2) any differences between the claimed subject matter and the
`prior art; (3) the level of skill in the art; and (4) if in evidence, objective
`evidence of nonobviousness, i.e., secondary considerations.3 See Graham v.
`John Deere Co., 383 U.S. 1, 17–18 (1966).
`
`1. Level of skill in the art
`Petitioner contends that a person of ordinary skill in the art “would
`have had at least a bachelor’s degree in Computer or Electrical Engineering
`or an equivalent engineering discipline, and at least three years of experience
`in the field of encryption and security, or the equivalent,” and that
`“[a]dditional education could substitute for professional experience, and
`significant work experience could substitute for formal education.” Pet. 4
`(citing Ex. 1003 ¶¶ 31–32, 53–55). Patent Owner does not challenge
`Petitioner’s proposed level of skill or propose an alternative. Petitioner’s
`proposal is consistent with the technology described in the Specification and
`the cited prior art. For purposes of this Decision, we adopt Petitioner’s
`proposed level of skill.
`
`2. Scope and content of the prior art – overview of Ludtke
`Ludtke describes techniques for identifying an authorized user with a
`biometric device and enabling the authorized user to access private
`information over a voice network. Ex. 1005, Abstract. Figure 4 of Ludtke,
`reproduced below, illustrates an example:
`
`
`3 The record does not include allegations or evidence of objective indicia of
`nonobviousness.
`
`13
`
`
`
`IPR2024-00233
`Patent 8,886,954 B1
`
`
`
`Figure 4 is a block diagram of an in-store retail system. Id. at 2:8–9.
`In the retail environment of Figure 4, privacy card 405 interfaces with
`digital wallet 410 and retail point of sale (POS) terminal 415. Id. at 8:53–56.
`User 430 provides privacy card 405 and digital wallet 410 to POS terminal
`415 or legacy retail POS terminal 425. Id. at 8:59–67. Transaction privacy
`clearing house (TPCH) 440 receives user 430’s privacy card identification
`and determines whether the user has sufficient funds to perform the
`transaction. Id. at 9:1–3.
`In one embodiment, the transaction device(s), POS terminals
`and/or TPCH may function to verify the authenticity of each
`other. For example, a privacy card and digital wallet may be
`configured to verify the legitimacy of each other. Similarly, the
`transaction device may be configured to verify the legitimacy of
`the POS terminal and/or TPCH. A variety of verification
`techniques may be used. For example[,] lists of devices with
`
`14
`
`
`
`IPR2024-00233
`Patent 8,886,954 B1
`account and/or access issues may be maintained. For example,
`in one embodiment, the public key infrastructure (PKI) may be
`used to verify legitimacy.
`Id. at 5:11–20. “One means of authentication is some kind of PIN code
`entry. Alternately, authentication may be achieved by using more
`sophisticated technologies such as a biometric solution (e.g., fingerprint
`recognition).” Id. at 4:65–5:1. TPCH 440 interfaces with financial
`processing system 445, vendors 450, and distribution systems 455 to
`complete the transaction. Id. at 9:4–6.
`Figure 16 of Ludtke is reproduced below:
`
`Figure 16 is a flowchart of a process for performing a retail transaction.
`Id. at 2:35–36. A retail clerk triggers a purchase action by scanning a
`package’s bar code (step 1601), the POS terminal displays the transaction
`total (step 1602), and the clerk requests payment from the user (step 1603).
`
`
`
`15
`
`
`
`IPR2024-00233
`Patent 8,886,954 B1
`Id. at 27:17–25. The user presses a fingerprint recognition pad of the digital
`wallet, which verifies the user (steps 1604–1607). Id. at 27:25–34. The
`clerk initiates payment (step 1609), the user uses the digital wallet to select
`an account to use for payment (step 1610), and the magnetic strip of the
`privacy card is programmed with the account number (step 1611). Id. at
`17:44–49. The clerk swipes the card at the POS terminal (steps 1612–1614),
`a magnetic strip reader of the POS terminal reads the privacy card, the POS
`terminal sends a transaction request to the TPCH (step 1615), and the TPCH
`returns a confirmation message to the POS terminal (step 1616). Id. at
`17:50–65. The TPCH then settles funds, transferring an appropriate amount
`into the vendor’s account (step 1619). Id. at 17:66–67.
`Ludtke describes various alternatives for the TPCH’s involvement in
`funds settlement:
`The settlement of funds involves the transfer of the
`appropriate financial credit into the vendor’s account. For the
`purposes of this example, it is assumed that the account is
`managed completely by the TPCH, and thus the funds transfer
`is handled completely inside of the TPCH. The vendor is not
`given any user identity information regarding the transaction;
`rather, the user is represented only by the transaction device
`identification information.
`In an alternative embodiment, the TPCH may issue a
`funds settlement request to a third party financial institution on
`behalf of the user, causing the necessary funds to be transferred
`to the vendor from the user’s account. In yet another alternative
`embodiment, the TPCH may act as a proxy for the user,
`whereby the TPCH takes the funds from the user’s account as
`managed by a third party financial institution, and then issues a
`funds transfer from the TPCH account to the vendor’s account.
`This embodiment further preserves the user’s identity by not
`linking it with the funds transfer into the vendor’s account.
`Id. at 29:35–53.
`
`16
`
`
`
`IPR2024-00233
`Patent 8,886,954 B1
`3. Differences, if any, between claims 1, 2, 4–7, 10, 12, 13, 15, 16,
`18, 19, and 22–27 and Ludtke; reasons to modify
`Regarding claim limitations 1ai, 1aii, and 1aiii, Petitioner argues that
`Ludtke teaches persistently storing, in a user identity/account information
`block of the transaction device, biometric information (e.g., retinal scan,
`voice, DNA, hand profile, face recognition), a plurality of codes and other
`values comprising a device ID code uniquely identifying the transaction
`device (e.g., globally unique silicon ID (GUID), magnetic strip, bar codes),
`and a secret decryption value (e.g., public key infrastructure (PKI) public
`keys and private keys). Pet. 9–21 (citing Ex. 1005, 5:11–20, 8:63–67, 9:18–
`25, 10:64–67, 11:1–5, 13:27–29, 13:39–41, 14:13–21, 19:9–14, 19:29–40,
`23:11–19, 30:18–27, 37:39–45, 38:1–3, 38:9–21, 38:25–29, 38:40–61, 39:7–
`18, 40:5–26, Figs. 7B–7C, 27, 33; Ex. 1003 ¶¶ 73–94). Regarding claim
`limitation 1b, Petitioner argues that Ludtke’s transaction device requests and
`receives a fingerprint sample or other biometric data. Id. at 21–22 (citing
`Ex. 1005, 14:33–42, 14:40–46, 16:47–50; Ex. 1003 ¶¶ 95–96). As to claim
`limitation 1c, Petitioner argues that Ludtke’s transaction device compares
`the fingerprint sample to stored authorized samples to determine a match.
`Id. at 22 (citing Ex. 1005, 14:40–46; Ex. 1003 ¶ 97). Petitioner’s showing as
`to these limitations of claim 1 is sufficient, at this stage of the proceeding.
`Patent Owner does not yet contest Ludtke’s applicability to these aspects of
`claim 1.
`Claim limitation 1d recites:
`responsive to a determination that the scan data matches the
`biometric data, wirelessly sending one or more codes from the
`plurality of codes and the other data values for authentication to
`a third party that operates a trusted authority, wherein the one or
`more codes and other data values includes the device ID code.
`
`17
`
`
`
`IPR2024-00233
`Patent 8,886,954 B1
`Petitioner argues that Ludtke describes the transaction device sending, over a
`wireless network, to the TPCH, a communication including a unique
`transaction device ID. Pet. 22–23 (citing Ex. 1005, 5:63–64, 7:46–48, 9:26–
`30, 9:35–42, 9:51–59, 28:50–29:12, 30:23–27; Ex. 1003 ¶¶ 98–106).
`As to whether Ludtke teaches a determination whether the scan data
`matches the biometric data, Petitioner points to Ludtke’s description of the
`transaction device (digital wallet or privacy card) prompting the user to
`supply a fingerprint recognition sample, comparing the sample to stored
`fingerprints, and determining that the user is authorized if the supplied
`sample is recognized. Id. at 23–25 (citing Ex. 1005, 1:22–31, 1:37–38,
`4:62–5:1, 14:33–46, 18:45–50, 18:52–55, 27:12–13, 28:13–18, 28:26–45,
`28:50–29:12, 34:25–27; Ex. 1003 ¶¶ 99–103). As to whether Ludtke teaches
`wirelessly sending one or more codes for authentication, Petitioner points to
`Ludtke’s description of its transaction device sending the unique transaction
`device ID to the TPCH using wireless or cellular signals. Id. at 25 (citing
`Ex. 1005, 9:26–42; Ex. 1003 ¶ 103). Petitioner’s showing as to these
`aspects of claim limitation 1d is sufficient, at this stage of the proceeding.
`Patent Owner does not yet contest Ludtke’s applicability to these aspects of
`claim limitation 1d.
`As to claim limitation 1e, Petitioner argues that after the TPCH
`authenticates the transaction device ID, a webpage receives from the TPCH
`an indication of an approval of the transaction to be performed, and that the
`indication allows the user to access content or a reference to content on a
`webpage. Pet. 28–29 (citing Ex. 1005, 24:17–32, 28:26–40, 29:15–20,
`29:29–30, 31:41–52; Ex. 1003 ¶¶ 107–114).
`
`
`18
`
`
`
`IPR2024-00233
`Patent 8,886,954 B1
`Petitioner contends that the user and a vendor/service provider are the
`parties to the transactions in Ludtke, and the applications to be accessed are
`the software and services that the user downloads from the providers, such
`as a transaction record or a webpage. Id. at 29–32 (citing Ex. 1005, 19:45–
`50, 28:26–40, 28:50–56, 28:64–67, 29:12–22, 29:29–30, 31:11–52; Ex. 1003
`¶¶ 108–114). In one example of a transaction between a user (with a digital
`wallet) and a vendor,
`[o]nce a transaction has been triggered, the browser
`communicates with the personal POS terminal, requesting it to
`initiate a transaction. The browser provides a transaction
`record, which includes all of the necessary data to support this
`transaction, including a list of items being purchased, unit cost
`and quantity, the vendor who will provide the items, etc.
`Ex. 1005, 28:50–56. In another “example, on a web site the user might click
`a button that causes new functionality to be downloaded to the transaction
`device for access at a future time.” Id. at 31:13–16. “For example, when
`arriving at a new airport, the transaction device might download a new
`service that provides instructions for how to buy a train ticket to certain
`destinations.” Id. at 31:30–33. Or, “if the transaction device finds itself in
`the presence of a service that is managed by an alternate system, it can
`download not only the service software, but also the necessary underlying
`‘transaction system’ software. This might include new security protocols,
`etc.” Id. at 31:35–40. According to Mr. Gray, “Ludtke discloses receiving
`at the downloaded software/functionality (application) a transaction
`confirmation (access message) that allows the user to access the services
`prescribed by the downloaded software/functionality (application).”
`Ex. 1003 ¶ 114. Petitioner’s showing as to claim limitation 1e is sufficient,
`at this stage of the proceeding.
`
`19
`
`
`
`IPR2024-00233
`Patent 8,886,954 B1
`
`
`Returning to claim limitation 1d, the parties dispute whether Ludtke’s
`TPCH is a “third party that operates a trusted authority.” Petitioner contends
`that the TPCH is “an entity separate from the parties to a transaction,” as we
`construe “third party that operates a trusted authority,” because “it is distinct
`from the transaction device, the POS on which the user/transaction device is
`performing a transaction, and the ‘external retailers and vendors’ that
`complete the transaction.” Pet. 25–27 (quoting Ex. 1005, 9:35–39; citing
`Ex. 1005, Fig. 6; Ex. 1003 ¶ 105). Mr. Gray testifies that the fact “[t]hat the
`vendors and transaction device are ‘external’ to the TPCH confirms that the
`TPCH is a third party, and not a party to the transaction itself.” Ex. 1003
`¶ 105. Petitioner argues that “Ludtke expressly identifies the TPCH as
`external to the parties to the transaction, capable only of communication
`with the parties,” and that the TPCH functions “as the middleman of the
`distribution channel.” Id. at 26, 28 (quoting Ex. 1005, 7:44–48; citing
`Ex. 1005, 9:26–30, 9:43–59; Ex. 1003 ¶ 106).
`Patent Owner argues that the TPCH is not a “third party that operates
`a trusted authority” because it “is an active participant in transactions
`between a user and vendor” rather than simply a “witness” to the
`transactions. Prelim. Resp. 6. Patent Owner points to examples in Ludtke
`where the TPCH is “accessing financial accounts to authorize transactions”
`and “processing transactions.” Id. at 6–13 (citing Ex. 1005, 3:38–45, 6:41–
`44, 6:51–55, 7:12–20, 9:28–30, 9:43–51, 21:51–57, 23:50–55, 27:56–58,
`27:60–63, 27:66–67, 28:58–62, 29:6–14, 29:31–39, 29:46–51, Figs. 16–17).
`According to Patent Owner, “[t]he TPCH of Ludtke is . . . accessed by the
`user and the vendor to access a financial account, authorize a transaction,
`and provide payment,” and, thus, “is a very active participant in the
`
`20
`
`
`
`IPR2024-00233
`Patent 8,886,954 B1
`transaction, not merely a witness to it.” Id. at 7; see also id. at 9 (“the TPCH
`becomes an active participant by authorizing the transaction . . . and
`subsequently performing settlement”), 10 (“By authorizing transactions and
`transferring funds into the vendor’s account, the TPCH is a very active
`participant in the transactions—it is being accessed by the vendor to
`authorize a transaction. The TPCH is also accessed by the user to pay the
`vendor. Being accessed by the vendor and user to be an active participant,
`the TPCH cannot be the claimed ‘third-party trusted authority.’”), 11 (“As
`the TPCH is an active participant during retail and web transactions by being
`accessed by the vendor and user, it cannot be the claimed ‘third-party trusted
`authority.’”), 11 (“[T]he TPCH is being accessed to pay the vendor, making
`the TPCH an active participant in the transaction.”), 12 (“[B]y issuing credit
`to the user, the TPCH is an even more active participant than in the previous
`method of settlement.”), 13 (“The TPCH is thus being accessed to access a
`user’s registered account and to pay the vendor.”).
`On the current record, we agree with Petitioner. As Mr. Gray testifies,
`the parties to Ludtke’s transaction a