throbber
Trials@uspto.gov
`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

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