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
`
`GOOGLELLC,
`Petitioner,
`
`V.
`
`PROXENSE, LLC,
`Patent Owner.
`
`IPR2024-00233
`Patent 8,886,954 Bl
`
`Before THU A. DANG, KEVIN F. TURNER, and DAVID C. McKONE,
`Administrative Patent Judges.
`
`MCKONE,Administrative Patent Judge.
`
`DECISION
`Granting Institution of /nter Partes Review
`3S US.C. § 314
`
`

`

`IPR2024-00233
`Patent 8,886,954 Bl
`
`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 (Paper6, “Prelim. Resp.”).
`
`With our authorization, Petitioner filed a Preliminary Reply (Paper7,
`
`“Prelim. Reply’) and Patent Ownerfiled a Preliminary Sur-reply (Paper 9,
`
`“Prelim. Sur-reply”’).
`
`Wehaveauthority to determine whetherto 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 maynotbe instituted
`
`“unless... there is a reasonable likelihood that the petitioner would prevail
`
`with respect to at least 1 of the claims challengedin the petition.” For the
`
`reasons explained below,weinstitute an inter partes review of the ’954
`
`patent.
`
`B. Related Matters
`
`Theparties 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 hasfiled
`
`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 Ownerstates that patents related to
`
`the ’954 patent are the subject of ex parte reexaminations in Application
`
`

`

`IPR2024-00233
`Patent 8,886,954 Bl
`
`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 patentstates 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.” /d. 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.” /d. at
`
`1:36—46. According to the ’954 patent, there was a needin 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.” /d. at 1:52—56.
`
`

`

`IPR2024-00233
`Patent 8,886,954 Bl
`
`Figure 2 of the 954 patent is reproduced below.
`
`RF Communication
`Module
`
`
`
`Biometric Key 100
`
`Biometric Portion
`220
`
`Enrollment
`Module
`£22
`
`Yalidation
`Module
`24
`
`Persistent
`
`oe
`
`Battery
`
`FIG. 2
`
`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 bypersistently storing biometric data associated with the user(e.g.,
`
`a digital image of the retina, fingerprint, or voice sample) in persistent
`
`storage 226.
`
`/d. 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.
`
`/d. at 5:1-5. The codeis stored in persistent
`
`storage 226.
`
`/d. at 5:36-38. “Persistent storage 226 isitself, and stores data
`
`in, a tamper-proof format to prevent any changesto the stored data.” /d. at
`
`5:29-31. “Tamperproofing increasesreliability of authentication becauseit
`
`does not allow any changes to biometric data (i.¢., allows reads of stored
`
`data, but not writes to store new data or modify existing data).” /d. 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
`
`

`

`IPR2024-00233
`Patent 8,886,954 Bl
`
`and comparesthe scanned data to the stored fingerprint to determine whether
`
`the scanned data matchesthe stored data.
`
`/d. at 5:6—15.
`
`The interaction of biometric key 100 with other system componentsis
`
`illustrated in Figure 3, reproduced below.
`
`
`
`Application
`
`
`100
` Biometric Key
`
`Authentication
`Module
`218
`
`
`
`
`Trusted Key
`Authority
`329
`
`FIG. 3
`
`Figure 3 is “a block diagram illustrating a system for providing
`
`authentication information for a biometrically verified user.” /d. 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
`
`

`

`IPR2024-00233
`Patent 8,886,954 Bl
`
`data network such as the Internet).
`
`/d. 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.
`
`/d. 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 messageto application 330 to allow
`
`the user access to the application responsive to a successful authentication
`
`by trusted key authority 320.
`
`/d. 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.” /d. at 6:19-24. Trusted key
`
`authority 320 can be operated by an agent, such as “a governmentofficial, a
`
`notary, and/or an employee of a third party which operates the trusted key
`
`authority, or another form of witness.” /d. 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.” /d. at 7:33-36.
`
`Claim 1, reproduced below, is illustrative of the claimed subject
`
`matter:
`
`' We add bracketed alphanumeric characters corresponding to those
`Petitioner uses in the Petition.
`
`

`

`IPR2024-00233
`Patent 8,886,954 Bl
`
`1.
`
`A method comprising:
`
`[lai] persistently storing biometric data of a user and
`[lati] a plurality of codes and other data values
`comprising a device ID code uniquely identifying
`an integrated device and [laiii] 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 codesand 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 andother data
`values includes the device ID code; and
`
`[le] receiving, at an application, an access message from
`the trusted authority indicating that the trusted
`authority successfully authenticated the one or
`more codes andother data values sent to the third
`party and allowing the user access to the
`application.
`
`D. Evidence
`
`Petitioner relies on the references listed below.
`
`1006
`
`
`
`Mar. 6, 2007 (filed
`Dec.
`11, 2000
`US 2002/0046336 Al|Apr. 18, 2002
`
`US 7,188,110 Bl
`
`

`

`IPR2024-00233
`Patent 8,886,954 Bl
`
`Petitioner also relies on the Declaration of Stephen Gray (Ex. 1003).
`
`ki. The Asserted Grounds
`
`Petitioner asserts the following grounds of unpatentability (Pet. 1):
`
`3,14,17
`
`1,2, 4-7, 10, 12, 13,
`§ 103(a)’
`Ludtke
`15, 16, 18, 19, 22-27
`
`
`Ludtke, Kon
`
`§ 103(a)
`
`Ul. ANALYSIS
`
`A. Claim Construction
`
`Weconstrue 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.
`
`constructions of “device ID code,”
`
`“access message,” and “third-party
`
`/d. Patent Owner requests that we adopt previous
`99 ¢¢
`
`? 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
`AJA,wecite to the pre-AIA version of § 103.
`
`8
`
`

`

`IPR2024-00233
`Patent 8,886,954 Bl
`
`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. Thirdparty that operates a trusted authority
`
`Independentclaims 1, 12, 16, and 22 each recite “a third party that
`
`operates a trusted authority.” The ’730 patent, a parent of the °954 patent,
`
`wasthe 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 contendthat “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 purposesof this Decision, we
`
`treat these terms as equivalent.
`
`In the Samsung DDI, the Board foundthat “[t]he plain meaning of
`
`‘third-party trusted authority’ suggests an entity or party separate from the
`
`principal parties to a transaction.” /d. at 14 (citing thirdparty, 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 DDIpanel further found that the ’730 patent’s
`
`specification supported its construction, and noted that it included examples
`
`of “a governmentofficial, a notary, and/or an employee ofa third party
`
`which operates the trusted key authority, or another form of witness.” /d. 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
`
`

`

`IPR2024-00233
`Patent 8,886,954 Bl
`
`prosecution were also “consistent with a third-party trusted authority being
`
`an entity separate from the principal parties to a transaction.” /d. 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.” /d. at 5.
`
`In the Samsung DDI, the panel determined that Samsung had not
`
`explained sufficiently what the componentit identified as a third-party
`
`trusted authority wasa third party relative to or what application Lapsley’s
`
`user was being permitted to access. Ex. 1007, 26-27. As Samsung
`
`presentedit, the resource it identified as the third-party trusted authority
`
`appeared to be the resource accessed.
`
`/d. 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 wasnot sufficient to show that it was a
`
`third-party trusted authority.
`
`/d.
`
`In any case, the panel did not purport to
`
`clarify or further construe the term “third-party trusted authority.” /d.
`
`The Samsung DDI doesnotprovide 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
`
`excludethe trusted key authority of the preferred embodiments of the °954
`
`10
`
`

`

`IPR2024-00233
`Patent 8,886,954 Bl
`
`patent, which actively participates in a transaction, for example by receiving
`
`a request for authentication with a code, determining whether the codeis
`
`valid, authenticating the code, and transmitting an access codeto the
`
`requester, which allowsa user access to an application. Ex. 1001, 8:5-17,
`
`Fig. 7. Although the trusted key authority in this exampleis 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 customeris legitimate, thereby allowing the transaction to
`
`proceed.
`
`/d. 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 proposedclarifications, 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 y. Dell, Inc., 66 F.4th 1317, 1327 (Fed. Cir. 2023) (The Federal Circuit
`
`“recognize[s] that ‘[a] claim construction exclud[ing] a preferred
`299
`
`embodimentis rarely, if ever correct.’”
`
`(quoting Kaufman v. Microsoft
`
`Corp., 34 F Ath 1360, 1372 (Fed. Cir. 2022) (second and third alterations in
`
`original)). Indeed, Patent Owner’s view would transform any entity thatis
`
`accessed for any reason in a transaction into a party to that transaction, thus
`
`excluding it from the scope ofa “third party that operates a trusted
`
`11
`
`

`

`IPR2024-00233
`Patent 8,886,954 Bl
`
`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
`
`Basedon the preliminary record, we do notfind 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 ofClaims 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 obviousat the time the invention
`
`was madeto a person having ordinary skill in the art to which said subject
`
`matter pertains.” We resolve the question of obviousnesson the basis of
`
`underlying factual determinations, including (1) the scope and content of the
`
`12
`
`

`

`IPR2024-00233
`Patent 8,886,954 Bl
`
`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.? See Graham vy.
`
`John Deere Co., 383 U.S. 1, 17-18 (1966).
`
`1. Level ofskill in the art
`
`Petitioner contendsthat a person of ordinary skill in the art “would
`
`have hadat 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
`
`“Ta]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 doesnot challenge
`
`Petitioner’s proposed level of skill or propose an alternative. Petitioner’s
`
`proposalis consistent with the technology described in the Specification and
`
`the cited prior art. For purposes of this Decision, we adopt Petitioner’s
`
`proposedlevel of skill.
`
`2. Scope and content of the prior art — overview ofLudtke
`
`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,
`
`reproducedbelow,illustrates an example:
`
`> The record doesnotinclude allegations or evidence of objective indicia of
`nonobviousness.
`
`13
`
`

`

`IPR2024-00233
`Patent 8,886,954 Bl
`
`IN-STORE RETAIL ENVIRONMENT
`
`sony
`DIGITAL
`WALLET
`
`CLERK'S
`SCREEN &
`KEYBOARD
`
`FINANCIAL
`PROCESSING
`
`} } {i
`
`~
`He
`
`co
`ay
`
`415
`
`ens
`PRIVACYCA
`NEW
`
`RETAR,
`TRANSACTION
`2
`EARL
`aweio
`
`
`| CONSUMERbe-- as CLEARING HGUSE 450
`
`
`
` LEGACY
` RETAIL
`
`POS
`
`TERMINAL
`DEReeaaeaSaARa 8|OISTRIBUTION|
`
`ournertt
`
`iii i 5i ii
`
`436
`
`435
`
`Figure 4 is a block diagram of an in-store retail system.
`
`/d. 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.
`
`/d. at 8:53-56.
`
`User 430 providesprivacy card 405 and digital wallet 410 to POS terminal
`
`415 or legacy retail POS terminal 425.
`
`/d. 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.
`
`/d. 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 configuredto 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 Bl
`
`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 meansof 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).” /d. at 4:65—5:1. TPCH 440 interfaces with financial
`
`processing system 445, vendors 450, and distribution systems 455 to
`
`complete the transaction.
`
`/d. at 9:4—6.
`
`Figure 16 of Ludtke is reproduced below:
`
`DISRLAY CURRENTTOTAL
`
` iq{1i3z }
`
`gg$33}3
`
`DIGHAL
`WALLET
`;
`
`PRIVACY
`CAG
`x
`;
`
`33
`
`i
`
`O18 REAGY TO USE
`
`USER
`
`Erte
`
`onanheanegeeneAon0
`eneeenenonPeon
`
`3
`3
`3
`g
`
`t£
`
`:$ ,$gggt
`
`ended
`
`eneneeeeneeemeneneeeee,
`
`TPOH
`
`RRRBAARORONFOEAOEOEPEOEOOSOePOEPOEOEOOAEAOONDeOtbeNOE
`
`VENDOR
`
`PPeeeereeeteteteteANiste
`
`RETAY P08
`CLERK
`TERMINAL
`380)teRGGERPURCHASE
`¢ reaerennnnneneentennnnnntenne388 request PAYBIENT i
`
`
`
`$804 TRIGGERS04TRIGGERPAYMENTWITH EtCOUP‘ONS
`
`1805AEGLIESTAlAUTHORIZATION & iF ;
`{3608PROVIDE FINGERPRINT, ECOUPONSELECTION
`;
`1 1807 CRSPLAY EfguPGNS
`OLSAYeS
`1608 SCAN BARGODE
`_{sosastanagoes
`
`ee REQUESTCf RO
`MTTSTEPAon
`161% SECURE exchABGE, PROGRARRAKAG STRIPE
`1810 SELECT ACCDUNT
`‘
`3635S REMOVE CARS, RAOTOSLERK
`1614SWIPE CARO
`
`g
`i
`f
`1815 TRANSACTION BEQUEST: PURCHASE RECORD, ASCOUNT INFO
`i
`t
`; 1816, 1817 TRANSACTION CONHAMATION
`oy
`‘
`i
`18419 RETURNICARS & PAPER RECEIPT
`Nett
`:
`isiSerTLe SUINDS, DATA MINING INFO
`t
`g
`,
`f
`1820 ELECTRONIC RECEIPT VIA INTERNET
`'
`
`
`é
`
`OmOneeseLStLee
`
`FIG. | 6
`
`Aeeemeeeaeeeeneoeee
`
`t§4L{{
`
`i
`
`RETAIL TRANGADTION
`
`wnnnnarnennnannrnnnnnnanannannnnnnnnnthnnnnnttedtSenapenntrrtere “
`
`Figure 16 is a flowchart of a process for performinga 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 Bl
`
`Id. at 27:17—25. The user presses a fingerprint recognition pad ofthe digital
`
`wallet, which verifies the user (steps 1604-1607).
`
`/d. at 27:25-34. The
`
`clerk initiates payment(step 1609), the user uses the digital wallet to select
`
`an accountto use for payment(step 1610), and the magnetic strip of the
`
`privacy card is programmedwith the account number(step 1611).
`
`/d. 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
`
`retums a confirmation message to the POS terminal (step 1616).
`
`/d. at
`
`17:50-65. The TPCHthen settles funds, transferring an appropriate amount
`
`into the vendor’s account(step 1619).
`
`/d. at 17:66—67.
`
`Ludtke describes various alternatives for the TPCH’s involvementin
`
`funds settlement:
`
`The settlement of funds involves the transfer of the
`appropriate financial credit into the vendor’s account. For the
`purposesof this example, it is assumed that the accountis
`managed completely by the TPCH, and thus the funds transfer
`is handled completely inside of the TPCH. The vendoris not
`given any user identity information regarding the transaction;
`rather, the user 1s represented only by the transaction device
`identification information.
`
`In an alternative embodiment, the TPCH mayissue 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 mayact as a proxyfor the user,
`whereby the TPCH takes the funds from the user’s account as
`managed bya third party financial institution, and then issues a
`funds transfer from the TPCH accountto the vendor’s account.
`This embodimentfurther preserves the user’s identity by not
`linking it with the funds transfer into the vendor’s account.
`
`Td. at 29:35-53.
`
`16
`
`

`

`IPR2024-00233
`Patent 8,886,954 Bl
`
`3. Differences, ifany, between claims I, 2, 4—7, 10, 12, 13, 15, 16,
`18, 19, and 22—27 and Ludtke; reasons to modify
`
`Regarding claim limitations lai, laii, and laiii, Petitioner argues that
`
`Ludtke teachespersistently 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 4] 73-94). Regarding claim
`
`limitation 1b, Petitioner argues that Ludtke’s transaction device requests and
`
`receives a fingerprint sample or other biometric data.
`
`/d. at 21-22 (citing
`
`Ex. 1005, 14:33-42, 14:40—-46, 16:47—50; Ex. 1003 9] 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 4 97). Petitioner’s showing as
`
`to these limitations of claim 1 is sufficient, at this stage of the proceeding.
`
`Patent Owner doesnot yet contest Ludtke’s applicability to these aspects of
`
`claim 1.
`
`Claim limitation 1d recites:
`
`responsive to a determination that the scan data matchesthe
`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 andother data values includes the device ID code.
`
`17
`
`

`

`IPR2024-00233
`Patent 8,886,954 Bl
`
`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 Ff 98-106).
`
`Asto 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.
`
`/d. 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 wirelessor cellular signals. /d. at 25 (citing
`
`Ex. 1005, 9:26—-42; Ex. 1003 4 103). Petitioner’s showingas to these
`
`aspects of claim limitation 1d is sufficient, at this stage of the proceeding.
`
`Patent Owner doesnot yet contest Ludtke’s applicability to these aspects of
`
`claim limitation 1d.
`
`Asto claim limitation le, Petitioner argues that after the TPCH
`
`authenticates the transaction device ID, a webpagereceives 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 9] 107-114).
`
`18
`
`

`

`IPR2024-00233
`Patent 8,886,954 Bl
`
`Petitioner contendsthat the user and a vendor/service providerare the
`
`parties to the transactions in Ludtke, and the applications to be accessed are
`
`the software and servicesthat the user downloads from the providers, such
`
`as a transaction record or a webpage.
`
`/d. 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
`
`4] 108-114). In one exampleof 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 includesall of the necessary data to support this
`transaction, includingalist 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 website the user might click
`
`a button that causes new functionality to be downloadedto the transaction
`
`device for accessat a future time.” /d. at 31:13-16. “For example, when
`
`atriving at a new airport, the transaction device might download a new
`
`service that provides instructions for how to buya train ticket to certain
`
`destinations.” /d. at 31:30—33. Or, “if the transaction device findsitself in
`
`the presence of a service that is managedby 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 4 114. Petitioner’s showing asto claim limitation le is sufficient,
`
`at this stage of the proceeding.
`
`19
`
`

`

`IPR2024-00233
`Patent 8,886,954 Bl
`
`Returning to claim limitation 1d, the parties dispute whether Ludtke’s
`
`TPCHis a “third party that operates a trusted authority.” Petitioner contends
`
`that the TPCH1s “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 whichthe user/transaction device 1s
`
`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 4 105). Mr. Graytestifies that the fact “[t]hat the
`
`vendors and transaction device are ‘external’ to the TPCH confirms that the
`
`TPCHis a third party, and not a party to the transaction itself.” Ex. 1003
`
`4 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 ofthe
`
`distribution channel.” /d. at 26, 28 (quoting Ex. 1005, 7:44—48; citing
`
`Ex. 1005, 9:26—30, 9:43-59; Ex. 1003 4 106).
`
`Patent Ownerargues that the TPCH is not a “third party that operates
`
`a trusted authority” becauseit “is an active participant in transactions
`
`between a user and vendor”rather than simply a “witness”to the
`
`transactions. Prelim. Resp. 6. Patent Ownerpoints to examples in Ludtke
`
`where the TPCHis “accessing financial accounts to authorize transactions”
`
`and “processing transactions.” /d. 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 vendorto 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 Bl
`
`transaction, not merely a witnessto it.” /d. at 7; see also id. at 9 (“the TPCH
`
`becomesan active participant by authorizing the transaction .. . and
`
`subsequently performing settlement’), 10 (“By authorizing transactions and
`
`tran