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-00232
`Patent 8,352,730 B2
`____________
`
`
`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-00232
`Patent 8,352,730 B2
`
`I.
`INTRODUCTION
`A. Background and Summary
`Google LLC (“Petitioner”) filed a Petition (Paper 1, “Pet.”) requesting
`inter partes review of claims 1–6 and 8–17 of U.S. Patent No. 8,352,730 B2
`(Ex. 1001, “the ’730 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 ’730
`patent.
`
`
`B. Related Matters
`The parties advise us that the ’730 patent is involved in four district
`court cases, including Proxense, LLC v. Google LLC, No. 6.23-CV-00320
`(W.D. Tex.) (“the Texas case”). Pet. 75; Paper 4, 2. Petitioner also has filed
`petitions for inter partes review of patents related to the ’730 patent,
`including IPR2024-000233 (challenging U.S. Patent No. 8,886,954 B1 (“the
`’954 patent”)) and IPR2024-00234 (challenging U.S. Patent No. 9,298,905
`B1 (“the ’905 patent”)). The ’730 patent also was the subject of Samsung
`Electronics America, Inc. v. Proxense LLC, IPR2021-01444 (PTAB)
`(institution denied). See Ex. 1007 (IPR2021-01444, Paper 11 (“Samsung
`
`2
`
`

`

`IPR2024-00232
`Patent 8,352,730 B2
`DDI”)). Petitioner states that the ’730 patent is the subject of ex parte
`reexamination in In re Proxense, LLC, Application No. 90/015,052 (filed
`June 8, 2022) (“the ’052 reexam”). Pet. 75. Patent Owner notes two
`additional reexaminations of patents related to the ’730 patent, Application
`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 ’730 Patent
`The ’730 patent discloses systems for “authentication responsive to
`biometric verification of a user being authenticated,” using “a biometric key
`[that] persistently (or permanently) stores a code such as a device identifier
`(ID) and biometric data for a user in a tamper-resistant format.” Ex. 1001,
`1:57–62. The ’730 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:23–32. 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:33–43. According to the ’730 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:49–53.
`
`3
`
`

`

`IPR2024-00232
`Patent 8,352,730 B2
`Figure 2 of the ’730 patent is reproduced below.
`
`
`
`Figure 2 is a block diagram of the functional modules of a biometric key.
`Id. at 2:41–43. 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:4–28. 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 4:8–12. The code is stored in persistent
`storage 226. Id. at 4:43–45. “Persistent storage 226 is itself, and stores data
`in, a tamper-proof format to prevent any changes to the stored data.” Id. at
`4:36–38. “Tamper-proofing 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 4:38–
`41. In a fingerprint embodiment, validation module 224 uses scan pad 120
`(shown in Figure 1) to capture scan data from the user’s fingerprint and
`
`4
`
`

`

`IPR2024-00232
`Patent 8,352,730 B2
`compares the scanned data to the stored fingerprint to determine whether the
`scanned data matches the stored data. Id. at 4:14–23.
`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 2:44–46.
`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-00232
`Patent 8,352,730 B2
`data network such as the Internet). Id. at 5:8–12. 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 5:12–19. 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 5:19–23; see also id. at 5:42–48
`(“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 5:23–26.
`“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 5:28–31. 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 6:35–38. “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 6:38–41.
`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-00232
`Patent 8,352,730 B2
`1.
`A method for verifying a user during
`authentication of an integrated device, comprising the steps of:
`[1ai] persistently storing biometric data of the user and
`[1aii] a plurality of codes and other data values
`comprising a device ID code uniquely identifying
`the integrated device and [1aiii] a secret decryption
`value in a tamper proof format written to a storage
`element on the integrated device that is unable to
`be subsequently altered; [1b] wherein the
`biometric data is selected from a group consisting
`of a palm print, a retinal scan, an iris scan, a hand
`geometry, a facial recognition, a signature
`recognition and a voice recognition;
`[1c] responsive to receiving a request for a biometric
`verification of the user, receiving scan data from a
`biometric scan, [1d] comparing the scan data to the
`biometric data to determine whether the scan data
`matches the biometric data;
`[1e] 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 by an agent
`that is a third-party trusted authority possessing a
`list of device ID codes uniquely identifying
`legitimate integrated devices, wherein the one or
`more codes and other data values includes the
`device ID code; and
`[1f] responsive to authentication of the one or more codes
`and the other data values by the agent, receiving an
`access message from the agent allowing the user
`access to an application, wherein the application is
`selected from a group consisting of a casino
`machine, a keyless lock, a garage door opener, an
`ATM machine, a hard drive, computer software, a
`web site and a file.
`
`
`
`7
`
`

`

`IPR2024-00232
`Patent 8,352,730 B2
`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
`
`
`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–6, 8, 9, 11, 12,
`14–17
`
`§ 103(a)2
`
`Ludtke
`
`Ludtke, Kon
`
`
`§ 103(a)
`
`3, 10, 13
`
`
`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 ’730 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-00232
`Patent 8,352,730 B2
`
`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 “third-party trusted authority,” “device ID
`code,” and “access message” have been construed previously, by the Board
`and in district court litigation. Pet. 4 (citing Ex. 1007, 15; 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 “third-party trusted authority,’ “device ID code,” and
`“access message.” Prelim. Resp. 2–5.
`
`1. Third-party trusted authority
`In the Samsung DDI, the Board construed “third-party trusted
`authority,” in claims 1 and 8 of the ’730 patent, to mean “a trusted authority
`that is an entity separate from the parties to a transaction.” Ex. 1007, 15.
`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
`
`9
`
`

`

`IPR2024-00232
`Patent 8,352,730 B2
`DDI panel further found that the Specification supported its construction,
`and noted that the Specification 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
`Ex. 1001, 6:35–38). The panel further observed that the applicant’s
`statements during 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, 366–67, 440–42.
`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.
`
`10
`
`

`

`IPR2024-00232
`Patent 8,352,730 B2
`The Samsung DDI does not provide a basis for further limiting a
`“third-party trusted authority” to exclude any active participant in a
`transaction. This would exclude the trusted key authority of the preferred
`embodiments of the ’730 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, 7:10–22, 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 ’730 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 5:42–56, 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, 6:35–38)
`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 6:32–64, 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
`
`11
`
`

`

`IPR2024-00232
`Patent 8,352,730 B2
`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 trusted 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 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–6, 8, 9, 11, 12, and 14–17 over Ludtke
`Petitioner contends that claims 1, 2, 4–6, 8, 9, 11, 12, and 14–17
`would have been obvious over Ludtke. Pet. 8–59. 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
`
`12
`
`

`

`IPR2024-00232
`Patent 8,352,730 B2
`matter pertains.” We resolve the question of obviousness 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 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. 5
`(citing Ex. 1003 ¶¶ 31–32, 54–56). 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
`
`
`3 The record does not include allegations or evidence of objective indicia of
`nonobviousness.
`
`13
`
`

`

`IPR2024-00232
`Patent 8,352,730 B2
`information over a voice network. Ex. 1005, Abstract. Figure 4 of Ludtke,
`reproduced below, illustrates an example:
`
`
`
`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
`
`14
`
`

`

`IPR2024-00232
`Patent 8,352,730 B2
`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
`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
`
`
`
`15
`
`

`

`IPR2024-00232
`Patent 8,352,730 B2
`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).
`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.
`
`16
`
`

`

`IPR2024-00232
`Patent 8,352,730 B2
`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.
`
`
`3. Differences, if any, between claims 1, 2, 4–6, 8, 9, 11, 12, and 14–
`17 and Ludtke; reasons to modify
`The preamble of claim 1 recites “[a] method for verifying a user
`during authentication of an integrated device.”4 Petitioner contends that
`Ludtke’s privacy card and digital wallet (transaction devices) are examples
`of integrated devices with a unique identifier (ID) and that a user performs
`transactions with an eCommerce system using such a device. Pet. 8–9
`(citing Ex. 1005, 3:32–36; Ex. 1003 ¶¶ 72–74). Regarding claim limitations
`1ai, 1aii, 1aiii, and 1b, 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. 10–
`24 (citing Ex. 1005, 5:11–20, 8:63–67, 9:18–25, 10:64–67, 13:27–29,
`13:39–41, 14:13–21, 19:9–14, 19:29–40, 23:11–19, 30:18–27, 35:61–64,
`37:39–45, 38:1–3, 38:9–21, 38:25–29, 38:40–61, 38:66–39:2, 39:7–18,
`40:5–26, Figs. 7B–7C, 27, 33; Ex. 1003 ¶¶ 75–96). Regarding claim
`limitation 1c, Petitioner argues that Ludtke’s transaction device requests and
`
`
`4 We need not determine, at this stage of the proceeding, whether the
`preamble of claim 1 is limiting, as Petitioner’s evidence shows sufficiently
`that Ludtke teaches the preamble.
`
`17
`
`

`

`IPR2024-00232
`Patent 8,352,730 B2
`receives a fingerprint sample or other biometric data. Id. at 23–24 (citing
`Ex. 1005, 14:33–46, 16: 47–49, 35:61–64; Ex. 1003 ¶¶ 97–98). As to claim
`limitation 1d, Petitioner argues that Ludtke’s transaction device compares
`the fingerprint sample to stored authorized samples to determine a match.
`Id. at 25 (citing Ex. 1005, 14:40–46, 35:61–64; Ex. 1003 ¶ 99). 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 1e 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
`by an agent that is a third-party trusted authority possessing a
`list of device ID codes uniquely identifying legitimate
`integrated devices, wherein the one or more codes and other
`data values includes the device ID code.
`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. 25–26 (citing Ex. 1005, 3:40–43, 4:48–50, 5:63–
`64, 7:46–48, 9:26–30, 9:35–42, 9:51–59, 28:50–29:12, 30:23–27; Ex. 1003
`¶¶ 100–109).
`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 26–28 (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–40,
`28:41–45, 28:50–62, 34:25–27, 35:61–64; Ex. 1003 ¶¶ 103–105). As to
`
`18
`
`

`

`IPR2024-00232
`Patent 8,352,730 B2
`whether Ludtke teaches wirelessly sending one or more codes for
`authentication by an agent, 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 28 (citing Ex. 1005, 9:26–42;
`Ex. 1003 ¶ 106). As to whether Ludtke teaches an agent “possessing a list
`of device ID codes uniquely identifying legitimate integrated devices,
`wherein the one or more codes and other data values includes the device ID
`code,” Petitioner points to Ludtke’s description of the TPCH maintaining a
`copy of unique transaction device ID values. Id. at 31 (citing Ex. 1005,
`30:20–27; Ex. 1003 ¶ 109). Petitioner’s showing as to these aspects of claim
`limitation 1e is sufficient, at this stage of the proceeding. Patent Owner does
`not yet contest Ludtke’s applicability to these aspects of claim limitation 1e.
`As to claim limitation 1f, Petitioner argues that the TPCH uses the
`unique ID of the transaction device to process the transaction and, if the
`selected account has sufficient funds, the TPCH issues a transaction
`confirmation. Pet. 32–33 (citing Ex. 1005, 28:50–29:23; Ex. 1003 ¶ 112).
`As Petitioner observes (Pet. 33, Ex. 1003 ¶ 113), once the transaction is
`authorized, “[s]ecure distribution of physical (or electronic) content to the
`user is performed.” Ex. 1005, 29:29–30. Petitioner also points to other
`examples of services Ludtke’s system provides access to, including voice
`mail, bank balances, dialing cards, credit reports, depositing money,
`accessing stored messages, logging onto computers, and others. Pet. 33
`(citing Ex. 1005, 1:22–31, 1:38–39, 18:52–55, 19:45–50; Ex. 1003 ¶ 114).
`Thus, responsive to the authentication of the unique ID of the transaction
`device by the TPCH, the user is allowed access to an application, wherein
`the application can include at least “computer software, a website and a
`
`19
`
`

`

`IPR2024-00232
`Patent 8,352,730 B2
`file,” as recited in claim limitation 1f. Petitioner’s showing as to claim
`limitation 1f is sufficient, at this stage of the proceeding.
`Returning to claim limitation 1e, the parties dispute whether Ludtke’s
`TPCH is a “third-party trusted authority.” Petitioner contends that the
`TPCH is “an entity separate from the parties to a transaction,” as we
`construe “third-party 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. 28–29 (quoting Ex 1005, 9:35–39; citing
`Ex. 1005, Fig. 6; Ex. 1003 ¶ 107). 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 30–31 (quoting Ex. 1005,
`7:44–48; citing Ex. 1005, 9:26–30, 9:52–59; Ex. 1003 ¶ 108).
`Patent Owner argues that the TPCH is not a “third-party 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: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 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
`
`20
`
`

`

`IPR2024-00232
`Patent 8,352,730 B2
`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. Notably, the TPCH makes the payment, thereby making
`it a party to the transaction.”).
`On the current record, we agree with Petitioner. As Mr. Gray testifies,
`the parties to Ludtke’s transaction are the user and the external retailers and
`vendors. Ex. 1003 ¶ 107; Ex. 1005, 9:35–39. In the example of Figure 17,
`the “user triggers the purchase” and “the vendor . . . will provide the items.”
`Ex. 1005, 28:34–56. The TPCH plays a role in processing or facilitating the
`transaction. However, we agree with Petitioner, that, in general, the fact that
`“the TPCH is capable in certain embodiments of settling funds does not
`make it a ‘pa

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