UNITED STATES DISTRICT COURT FOR THE
`WESTERN DISTRICT OF TEXAS
`
`Civil Action No. 6:23-cv-00320-ADA
`
`PROXENSE, LLC,
`
`Plaintiffs,
`
`v.
`
`GOOGLE LLC,
`
`Defendants.
`
`PLAINTIFF’S PRELIMINARY INFRINGMENT CONTENTIONS
`
`Pursuant to this Court’s Standing Order Governing Proceedings in Patent Cases,
`
`Plaintiff Proxense, LLC (“Proxense” or “Plaintiff”), hereby provides its final infringement
`
`contentions concerning Defendant Google LLC, (“Google”, or “Defendant”).
`
`Proxense hereby certifies that it undertook reasonable efforts to prepare its preliminary
`
`infringement contentions and reserves the right to amend them based on material identified
`
`after the invalidity contentions are served and during discovery.
`
`These
`
`infringement contentions are based on Plaintiff’s current knowledge,
`
`understanding, and belief as to the facts and information available to it as of the date of these
`
`disclosures. Proxense has not yet completed its investigation, collection of information,
`
`discovery, or analysis related to this action. The evidence cited in support of the disclosures
`
`herein is necessarily exemplary and is therefore illustrative and not exhaustive. For example,
`
`Proxense anticipates that relevant facts and evidence are uniquely within the possession,
`
`custody, or control of Defendants. As such, Proxense reserves the right to supplement,
`
`amend, or modify the information contained herein and to use and introduce at trial such
`
`information and any subsequently-identified or discovered information.
`
`Page 1 of 61
`
`GOOGLE EXHIBIT 1013
`
`

`

`These final infringement contentions are based at least in part upon Proxense’s present
`
`understanding of U.S. Patent No. 8,352,730 (the “730 patent”), U.S. Patent No. 8,886,954 (the
`
`“954 Patent”), U.S. Patent No. 9,298,905 (the “905 patent”), U.S. Patent No. 8,646,042 (the
`
`“042 Patent”), U.S. Patent No. 9,679,289 (the “289 Patent”), U.S. Patent No. 10,073,960 (the
`
`“960 Patent”) and the accused products in the absence of discovery. The 730, 954, 905, 042,
`
`289, and 960 Patents are collectively referred to herein as the “Proxense Patents” or the
`
`“Patents-in-Suit.”
`
`Proxense reserves the right to amend its infringement contentions and asserted claims
`
`based on information Proxense obtains through discovery and otherwise as this case
`
`progresses. Proxense further reserves the right to amend its final infringement contentions and
`
`asserted claims based on any proceedings before the United States Patent and Trademark
`
`
`
`
`
`Office regarding the Proxense Patents.
`
`I.
`
`IDENTIFICATION OF INFRINGED CLAIMS
`
`The asserted claims of the Patents-in-Suit are as follows:
`
`
`730 Patent
`954 Patent
`905 Patent
`042 Patent
`289 Patent
`960 Patent
`
`
`
`Claims
`1-3, 5, 15-17 (Google Passwordless) and 1-2, 5
`(Google Pay)
`1-3, 5-7, 22-27 (Google Passwordless) and 1-2, 5-7
`(Google Pay)
`1-2, 15 (Google Passwordless) and 1, 4-5, 7 (Google
`Pay)
`10
`14, 16
`14, 16
`
`Proxense
`
`identifies
`
`these asserted claims based on
`
`its current, preliminary
`
`understanding and reserves the right to supplement and/or change its identification as discovery
`
`proceeds, including identifying additional claims and withdrawing claims.
`
`II.
`
`IDENTIFICATION OF ACCUSED PRODUCTS, SYSTEMS,
`
`Page 2 of 61
`
`

`

`
`
`METHODS ANDSERVICES
`
`Based on the information currently available, Proxense identifies the following accused
`
`products, systems, and methods, including all reasonably similar products, systems, methods,
`
`and their variants for each of the Patents-in-Suit.
`
`Hereafter, the term “Accused Instrumentalities” or “Accused Products” refers to the
`
`products listed below, (1) Google’s Universal Passwordless Architecture, which includes (a) Android
`
`Operating System (“OS”), (b) Android SafetyNet Authenticator, (c) Chrome browser, and (d) Google
`
`Identity Platform (also known as Google Identity Services or Google Cloud Identity Platform), (2)
`
`Google Pay services (also known as Google Wallet) and all Google devices preloaded with Google
`
`Pay/Wallet.
`
`III. CHARTS SETTING FORTH WHERE IN THE ACCUSED
`PRODUCT(S) EACH ELEMENT OF THE ASSERTED CLAIM(S) ARE
`FOUND
`
`Subject to ongoing discovery and investigation, Proxense provides claim charts
`
`pertaining to the Patents-in-Suit attached hereto as Exhibits A1-A2 for the 730 patent, Exhibits
`
`B1-B2 for the 905 patent, Exhibits C1-C2 for the 989 patent, Exhibit D for the 042 patent,
`
`Exhibit E for the 289 patent, and Exhibit F for the 960 patent. These infringement contentions
`
`serve a notice function and are not required to—and therefore do not—present every possible
`
`permutation or theory of Proxense’s case.
`
`IV.
`
`LITERAL INFRINGEMENT AND INFRINGEMENT UNDER
`THE DOCTRINEOF EQUIVALENTS
`Proxense contends that Google’s products literally infringe the asserted claims of the
`
`Patents-in-Suit as more specifically explained in the attached claim charts. Proxense reserves
`
`the right to assert infringement under the doctrine of equivalents to the extent that the difference
`
`between any component of any product or system, and any step of any service, method, and/or
`
`Page 3 of 61
`
`

`

`claim element is insubstantial.
`
`V.
`
`PRIORITY DATES AND ALL DOCUMENTS EVIDENCING
`CONCEPTION ANDREDUCTION TO PRACTICE FOR EACH
`CLAIMED INVENTION
`
`The 730 patent matured from application number 11/314,199 (“the 199 application”),
`
`which was filed on December 20, 2005. The 905 application claims priority from provisional
`
`patent application 60/637,538 which was filed on December 20, 2004. Documents evidencing
`
`conception and/or reduction to practice for the claimed inventions of the 730 patent are being
`
`collected and will be produced shortly.
`
`The 954 patent matured from application number 13/710,109 (“the 109 application”),
`
`which was filed on December 10, 2012. The 905 application claims priority from provisional
`
`patent application 60/637,538 which was filed on December 20, 2004. Documents evidencing
`
`conception and/or reduction to practice for the claimed inventions of the 954 patent are being
`
`collected and will be produced shortly.
`
`The 905 patent matured from application number 14/521,982 (“the 982 application”),
`
`which was filed on October 23, 2014. The 982 application claims priority from provisional
`
`patent application 60/637,538 which was filed on December 20, 2004. Documents evidencing
`
`conception and/or reduction to practice for the claimed inventions of the 905 patent are being
`
`collected and will be produced shortly.
`
`The 042 patent matured from application number 13/445,825 (“the 825 application”),
`
`which was filed on April 12, 2012. The 825 application claims priority from provisional patent
`
`application 60/992,953 which was filed on December 6, 2007. Documents evidencing
`
`conception and/or reduction to practice for the claimed inventions of the 042 patent are being
`
`collected and will be produced shortly.
`
`The 289 patent matured from application number 14/961,645 (“the 645 application”),
`
`Page 4 of 61
`
`

`

`which was filed on December 7, 2015. The 645 application claims priority from provisional
`
`patent application 60/992,953 which was filed on December 6, 2007. Documents evidencing
`
`conception and/or reduction to practice for the claimed inventions of the 289 patent are being
`
`collected and will be produced shortly.
`
`The 960 patent matured from application number 15/595,739 (“the 739 application”),
`
`which was filed on May 15, 2017. The 739 application claims priority from provisional patent
`
`application 60/992,953 which was filed on December 6, 2007. Documents evidencing
`
`conception and/or reduction to practice for the claimed inventions of the 960 patent are being
`
`collected and will be produced shortly.
`
`VI. A COPY OF THE FILE HISTORY FOR EACH PATENT IN SUIT
`
`A copy of the file history for each of the Patents-in-Suit is submitted herewith. The
`
`file history of the 730 patent bears production numbers PROX_GOOGLE_000001-
`
`PROX_GOOGLE_00805. The file history of the 954 patent bears production numbers
`
`PROX_GOOGLE_00806- PROX_GOOGLE_01392. The file history of the 905 patent bears
`
`production numbers PROX_GOOGLE_001393- PROX_GOOGLE_001936. The file history
`
`of the 042 patent bears production numbers PROX_GOOGLE_001937-
`
`PROX_GOOGLE_002433. The file history of the 289 patent bears production numbers
`
`PROX_GOOGLE_002434- PROX_GOOGLE_002616. The file history of the 960 patent
`
`bears production numbers PROX_GOOGLE_002617- PROX_GOOGLE_002818.
`
`
`
`
`
`
`Dated: July 24, 2023
`
`
`
` Respectfully submitted,
`
`
`
`/s/ David L. Hecht
`David L. Hecht (Co-Lead Counsel)
`dhecht@hechtpartners.com
`
`Page 5 of 61
`
`

`

`Maxim Price (pro hac vice)
`mprice@hechtpartners.com
`Yi Wen Wu (pro hac vice)
`wwu@hechtpartners.com
`HECHT PARTNERS LLP
`125 Park Avenue, 25th Floor
`New York, New York 10017
`Telephone: (212) 851-6821
`
`Brian D. Melton (Co-Lead Counsel)
`bmelton@susmangodfrey.com
`Geoffrey L. Harrison
`gharrison@susmangodfrey.com
`Meng Xi
`mxi@susmangodfrey.com
`Bryce T. Barcelo
`bbarcelo@susmangodfrey.com
`SUSMAN GODFREY L.L.P.
`1000 Louisiana Street, Suite 5100
`Houston, Texas 77002-5096
`Telephone: (713) 653-7807
`Facsimile: (713) 654-6666
`
`Lear Jiang
`ljiang@susmangodfrey.com
`SUSMAN GODFREY L.L.P.
`1900 Avenue of the Stars, Suite 1400
`Los Angeles, California 90067-6029
`Telephone: (310) 789-3100
`Facsimile: (310) 789-3150
`
`Counsel for Plaintiff Proxense, LLC
`
`Attorneys for Plaintiff Proxense, LLC
`
`
`
`
`Page 6 of 61
`
`

`

`
`
`CERTIFICATE OF SERVICE
`
`I hereby certify that on July 24, 2023, the foregoing was served on counsel for Defendant
`
`Google, LLC.
`
`/s/ David L. Hecht
`David L. Hecht
`
`
`
`
`
`Page 7 of 61
`
`

`

`Exhibit Al
`Exhibit A1
`
`Page 8 of 61
`
`Page 8 of 61
`
`

`

`U.S. Patent Number 8,352,730 – Preliminary Infringement Contentions1
`
`
`
`Assignee:
`Title:
`Filing Date:
`Publication Date:
`Inventor:
`
`
`
`Proxense, LLC
`Biometric personal data key (PDK) authentication
`2005-12-20
`2013-01-08
`Giobbi, John J.
`
`‘730 Patent Claim2
`1
` A method for verifying a user
`during authentication of an
`integrated device, comprising the
`steps of4:
`
`Accused Instrumentality And Where Each Claim Element Is Found3
`Google uses, distributes, sells, and/or offers to sell a Universal Passwordless Architecture (“UPA”) (e.g.
`PROX_GOOGLE_003243, https://developers.google.com/identity/passkeys , which includes: (a)
`Android OS, (b) Android SafetyNet Authenticator, (c) Chrome, and (d) Google Identity Platform
`(“GIP”), which together infringe, literally or under the doctrine of equivalents, the claimed limitations as
`presented below.
`
`
`1 The Preliminary Infringement Contentions (PICS) provided herein are based on information obtained to date and may not be exhaustive. Plaintiff’s
`investigation of Defendants’ infringement is ongoing. Plaintiff reserves the right to supplement and/or amend these PICS to identify additional
`instrumentalities and to further identify where each element of each claim is found in each accused instrumentality, including on the basis of
`discovery obtained from Defendants, and from third parties during the course of this litigation, pursuant to ¶2 of the Order Governing Proceedings –
`Patent Cases under Hon. Alan D. Albright.
`
` 2
`
` All PICS set forth herein for any independent patent claims are hereby incorporated by reference into the PICS alleged for any dependent patent
`claims that depend on such independent claims, as if fully set forth therein.
`
` 3
`
` The Accused Instrumentalities and associated exhibits discussed and/or cited for any claim herein are representative in all material respects of all
`other accused instrumentalities identified for that claim (e.g., a specified phone or service may be used as a representative example in these charts
`since the other accused instrumentalities have immaterial differences in their hardware and/or software configuration, the cited references are
`believed to be illustrative of all such accused devices).
`
` 4
`
` Plaintiff’s inclusion of any claim preamble in this claim chart should not be interpreted as an admission that the preamble is limiting. Plaintiff
`reserves the right to take the position that the claim preambles are limiting or not limiting on a claim-by-claim basis.
`
`
`
`1
`
`Page 9 of 61
`
`

`

`‘730 Patent Claim2
`
` Persistently storing biometric data
`of the user and a plurality of codes
`and other data values comprising a
`device ID code uniquely identifying
`the integrated device and 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;
`
`Accused Instrumentality And Where Each Claim Element Is Found3
`Google, through its own actions, and the action of its customers, which Google directs and controls, has
`created and sells5 the use of UPA, including Android/Chrome preloaded6 devices, servers, and software
`supporting and integrating into the UPA architecture. Servers integrating with and supporting the
`architecture include GIP providing FIDO and/or OAuth services. Devices integrating and supporting
`the architecture include devices utilizing the Android OS. Software integrating with and supporting the
`architecture include the Chrome web browser and Android SafetyNet Authenticator.
`
`Persistently storing biometric data of a user … in a tamper proof format written to a storage element on
`the integrated device that is unable to be subsequently altered
`
`
`Utilizing the Android operating system developed and disseminated by Google, Android devices
`store biometric data of the user in a tamper proof format written to a storage element on the
`integrated device that is unable to be subsequently altered. Starting with Android 10, Google
`stored biometric data on Android devices includes fingerprint and facial recognition.
`PROX_GOOGLE_002913,
`https://source.android.com/docs/security/features/biometric#android10 (“Android 10: Introduces
`the BiometricManager class that developers can use to query the availability of biometric
`authentication. Includes fingerprint and face authentication integration for BiometricPrompt”).
`
`As to protecting biometric data, Android’s implementation guidelines require tamper-proof “raw
`fingerprint data or derivatives (for example, templates) must never be accessible from outside the
`sensor driver or TEE” (trusted execution environment) and “fingerprint acquisition, enrollment,
`and recognition must occur inside the TEE”. Android Open-Source Project: Fingerprint HIDL,
`PROX_GOOGLE_003177,
`https://source.android.com/docs/security/features/authentication/fingerprint-hal. Requiring
`acquisition and recognition to occur inside the TEE, fingerprint data never leaves the TEE.
`Android’s TEE, called Trusty, “uses ARM’s TrustzoneTM to virtualize the main processor and
`create a secure trusted exaction environment” isolated from the rest of the system. Android
`Open-Source Project: Trusty TEE, PROX_GOOGLE_003283,
`https://source.android.com/docs/security/features/trusty. Accordingly, fingerprint data, which
`never leaves the TEE, also never leaves the Trustzone housing Trusty. Keeping biometric data
`
`
`5 See e.g. PROX_GOOGLE_003250, https://cloud.google.com/identity-platform/pricing.
`
`6 For the avoidance of doubt, "preloaded" includes devices that ship with Android and other accused software pre-installed or upon which Android
`and other accused software is otherwise installed by Defendant (e.g., through operating system upgrades, updates, initial installation, or otherwise).
`
`
`2
`
`Page 10 of 61
`
`

`

`‘730 Patent Claim2
`
`Accused Instrumentality And Where Each Claim Element Is Found3
`within the Trustzone, Android devices persistently store biometric data in a tamper proof
`format.7
`
`On Android devices, access to biometric hardware is controlled by Fingerprint HIDL. "Android
`uses Fingerprint Hardware Interface Definition Language (HIDL) to connect to a vendor-specific
`library and fingerprint hardware (for example, a fingerprint sensor)." Android Open Source
`Project: Fingerprint HIDL, PROX_GOOGLE_003177,
`https://source.android.com/docs/security/features/authentication/fingerprint-hal. The methods
`enabled by the Fingerprint HIDL do not permit altering biometric data. Id. (providing a listing
`of methods, none of which allows for the alternation of biometric data.). Keeping fingerprint
`and other biometric data within a portion of the Trustzone only accessible by Fingerprint HIDL,
`which lacks a method for altering biometric data, Android devices persistently store biometric
`data of the user in a tamper proof format written to a storage element on the integrated device
`that is unable to be subsequently altered.
`
`Android devices require user consent to enroll a fingerprint. See PROX_GOOGLE_003204,
`How to Add a New Fingerprint to Your Android Device - Technipages (Detailing the process of
`adding a fingerprint to an Android devices by entering a PIN or password for the device before
`adding a fingerprint.). As enrolling fingerprints on Android devices require entering PIN /
`Passcode / Password to evidence user consent, Android devices store biometric data of the user
`in a tamper proof format unable to be subsequently altered.
`
`As Android devices store biometric data in a tamper proof format that is not capable of being
`subsequently altered, Google forces users of the Android OS, exercising control and direction
`over them by controlling every step that the software performs and every prompt for user action,
`to persistently store their biometric data in a tamper proof format written to a storage element on
`an integrated device that is not capable of being subsequently altered.
`
`
`
`
`7 In the alternative, to the extent the TEE and Trustzone are considered to be a different security implementation or if limited alterations are possible
`in limited circumstances and given high levels of security permissions, clearance, or hardware-level permission attribution, the “tamper proof format
`. . . that is unable to be subsequently altered,” limitation is met under the doctrine of equivalents on the grounds that the tamper proofing and
`limitations on alteration utilized in the Trustzone prevent nearly all alteration by nearly all programs that have not been explicitly approved and, at
`least, prevent alteration by all regular-world (non-TEE and non-Trustzone) applications and requires a strict level of physical and/or virtual layers of
`permission to be altered.
`
`
`3
`
`Page 11 of 61
`
`

`

`‘730 Patent Claim2
`
`Accused Instrumentality And Where Each Claim Element Is Found3
`persistently storing … a plurality of codes and other data values comprising a device ID code uniquely
`identifying the integrated device … in a tamper proof format written to a storage element on the
`integrated device that is unable to be subsequently altered
`
`
`The Android OS natively includes the Android SafetyNet Authenticator, which is FIDO certified
`and accessible via the FIDO2 API for Android. See PROX_GOOGLE_003793, FIDO®
`Certified - FIDO Alliance. In operation, authenticators store and access the cryptographic
`material underlying FIDO Passkeys. See PROX_GOOGLE_002819,
`AccountManager | Android Developers (“Authenticators (which may be written by third
`parties) handle the actual details of validating account credentials and storing account
`information. For example, Google, Facebook, and Microsoft Exchange each have their own
`authenticator.”); PROX_GOOGLE_003088, FIDO Technical Glossary (fidoalliance.org)
`(Defining a FIDO Authenticator as "responsible for user verification, and maintaining the
`cryptographic material required for the relying party authentication.”); and
`PROX_GOOGLE_003439, Web Authentication: An API for accessing Public Key Credentials -
`Level 3 (w3.org) (Defining an authenticator as “A cryptographic entity, existing in hardware or
`software, that can register a user with a given Relying Party and later assert possession of the
`registered public key credential, and optionally verify the user, when requested by the Relying
`Party.”).
`
`Having a native authenticator, Android devices support the use of FIDO Passkeys. See
`PROX_GOOGLE_003187, Google Online Security Blog: Security of Passkeys in the Google
`Password Manager (googleblog.com) (“Passkeys are the result of an industry-wide effort. They
`combine secure authentication standards created within the FIDO Alliance and the W3C Web
`Authentication working group with common terminology and user experience across different
`platforms, recoverability against device loss, and a common integration path for developers.
`Passkeys are supported in Android and other leading industry client OS platforms.").
`Accordingly, instead of the traditional username and password combination, users of Android
`devices may utilize a passkey to access their Google Account. See PROX_GOOGLE_003192,
`Google Online Security Blog: So long passwords, thanks for all the phish (googleblog.com)
`(“Starting today, you can create and use passkeys on your personal Google Account.”). Not only
`does the Android OS support the use of Passkeys, but Google also helped to create the standards
`upon which they are based. See PROX_GOOGLE_003192, Google Online Security Blog: So
`long passwords, thanks for all the phish (googleblog.com) (“Passkeys are built on the protocols
`and standards Google helped create in the FIDO Alliance and W3C WebAuthn working group.
`
`
`
`4
`
`Page 12 of 61
`
`

`

`‘730 Patent Claim2
`
`Accused Instrumentality And Where Each Claim Element Is Found3
`This means Passkey support works across all platforms and browsers that adopt these standards.
`You can store the passkeys for your Google Account on any compatible device or service.”). As
`the Android OS natively includes a FIDO certified authenticator and supports use the passkeys,
`Android devices must persistently store passkeys on the integrated device.
`
`The specific variant of passkeys stored by the native Android OS authenticator includes a device
`ID code uniquely identifying an integrated device. “[P]asskeys on Android support the proposed
`Device-bound Public Key WebAuthn extension (devicePubKey). If this extension is requested
`when creating or using passkeys on Android, relying parties will receive two signatures in the
`result: One from the passkey private key, which may exist on multiple devices, and an additional
`signature from a second private key that only exists on the current device.”
`PROX_GOOGLE_003187, Google Online Security Blog: Security of Passkeys in the Google
`Password Manager (googleblog.com). The second private key is part of a key pair.
`PROX_GOOGLE_003439, Web Authentication: An API for accessing Public Key Credentials -
`Level (pr-preview.s3.amazonaws.com) (“This authenticator registration extension and
`authentication extension provides a Relying Party with a "device continuity" signal for backup
`eligible credentials. This is done by creating a user credential-specific hardware-bound device
`key pair on the authenticator, if such a key pair does not already exist for the user credential
`being created or exercised, and returning the device public key along with a signature by the
`device private key to the Relying Party.”). The key pair provided by the Device-Bound Public
`Key extension is unique to each Android device. PROX_GOOGLE_003439, Web
`Authentication: An API for accessing Public Key Credentials - Level (pr-
`preview.s3.amazonaws.com) (“The hardware-bound device key pair is not on its own a user
`credential and does not have its own credential ID. Instead, the returned device public key is a
`device-specific contextual attribute of its associated user credential.”). As the key-pair is unique,
`each key of the pair is a unique device ID. However, only the public key is sent to uniquely
`identify an Android device. PROX_GOOGLE_003187, Google Online Security Blog: Security
`of Passkeys in the Google Password Manager (googleblog.com) (“This device-bound private key
`is unique to the passkey in question, and each response includes a copy of the corresponding
`device-bound public key.”); and PROX_GOOGLE_003439, Web Authentication: An API for
`accessing Public Key Credentials - Level (pr-preview.s3.amazonaws.com) (“That is, when that
`user credential is used—along with the devicePubKey extension—on a particular authenticator, a
`particular device public key is returned by the extension, along with a signature demonstrating
`proof-of-possession of the device private key by that device.”). Because device bound-public
`keys are not synced, "observing two passkey signatures with the same device-bound public key
`
`
`
`5
`
`Page 13 of 61
`
`

`

`‘730 Patent Claim2
`
`Accused Instrumentality And Where Each Claim Element Is Found3
`is a strong signal that the signatures are generated by the same device. On the other hand, if a
`relying party observes a device-bound public key it has not seen before, this may indicate that
`the passkeys has been synced to a new device." Google Online Security Blog: Security of
`Passkeys in the Google Password Manager, October 12, 2022, PROX_GOOGLE_003187,
`https://security.googleblog.com/2022/10/SecurityofPasskeysintheGooglePasswordManager.html.
`Providing an indication of the integrated device generating a signature, the public key of the
`Device-Bound Public Key extensions key-pair is a device ID code uniquely identifying the
`integrated device.
`
`When a Device Bound Public Key is present, the integrated authenticator within the Android OS
`causes the device to store a private key bound to the device. PROX_GOOGLE_003439 at §
`10.2.2.2 (Defining making a credential with a device bound public key as including “5. Let dpk
`be the newly created or existing device public key, in COSE_Key format in the same fashion as
`for the user credential’s credentialPublicKey when the latter is conveyed in attested credential
`data. 6. Let devicePrivateKey be the newly created or existing device private key.”)) The public
`key corresponding to the private key is returned to the relying party and saved.
`PROX_GOOGLE_003439 at § 10.2.2.3.1 (Stating registration at the relying party includes step
`“6. Create a new device-bound key record … add this device-bound key record to the
`devicePubKeys member of the new credential record.”).) When processing an authentication
`request received from Google Identity, the native Android OS SafetyNet authenticator creates a
`signature with the private key associated with the device-bound public key and then sends the
`signature and the device-bound public key back to Google Identity for verification. Id. at §
`10.2.2.2 (Defining authentication as including “9. Let dpkSig be the result of signing the
`assertion signature input with devicePrivateKey. 10. Output dpkSig as the extension’s unsigned
`extension output.”).) Upon receipt of the authentication response, Google Identity extracts the
`device bound public key from the response and uses it to verify the signature. Id. at § 10.2.2.3.2
`(Defining Relying Party verification of the authentication assertion as including “3. Extract the
`contained fields from attObjForDevicePublicKey: aaguid, dpk, scope, nonce, fmt, attStmt. 4.
`Verify that signature is a valid signature over the assertion signature input (i.e., authData and
`hash) by the device public key dpk.”)) If the device bound public key were changed at any time,
`Google Identity would not be able to verify the signature as it would no longer correspond to the
`authenticator’s device bound private key. Accordingly, by being part of a key pair, the device
`bound public key is in a format unable to be subsequently altered.
`
`
`
`
`6
`
`Page 14 of 61
`
`

`

`‘730 Patent Claim2
`
`Accused Instrumentality And Where Each Claim Element Is Found3
`Of course, if both the private key and public key were altered, then the signature could be
`nominally verified. In such a situation, however, the altered device-bound public key would not
`match any of the device-bound public keys stored by the Relying Party (i.e., Microsoft and
`Google). See Id. at § 10.2.2.3.2 (Steps 5 and 6 detailing, during an authentication ceremony,
`comparing the received device-bound public key to a list of stored device-bound public keys,
`where the lack of a match indicates a new device.). The Relying Party, accordingly, would treat
`the altered device-bound public key as representing a new device and not allow the request
`absent further user verification. Accordingly, by being recorded by the relying party, device-
`bound public keys are further placed in a format unable to be subsequently altered.8
`
`As Google controls the protocol utilized by its Identity platform, including the ability to sync
`passkeys across devices, users wanting the benefit of biometric authentication via passkeys have
`no choice but to store on their device a pair of keys generated by the device bound public key
`extension that uniquely identifies the integrated device in a tamper proof format written to a
`storage element on the integrated device that is unable to be subsequently altered.
`
`
`persistently storing … 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;
`
`
`Passkeys in the Google Password Manager are always end-to-end encrypted. See
`PROX_GOOGLE_003187. When a passkey is backed up, its private key is uploaded only in its
`encrypted form using an encryption key that is only accessible on the user’s own devices. Id.
`Without access to the private key, such an attacker cannot use the passkey to sign into its
`corresponding online account. Id. Accordingly, Android devices must contain a secret decryption
`value (i.e., the encryption key only accessible on the user's own device) to decrypt and use
`synced and backed-up passkeys. The decryption values are inherently in a tamper proof format
`as any alteration would prevent correct decryption of the encrypted passkey and thus render the
`passkey unusable. As such, Android devices contain a secret decryption value in a tamper proof
`format unable to be subsequently altered.
`
`As such encryption is dictated by Google and implemented natively in the Android OS, users
`wanting the benefit of biometric authentication via passkeys have no choice but to store on their
`
`
`
`
`8 In the alternative, the device-bound key pair performs the same function in the same way and achieves the same result as storage in a format that is unable to be subsequently
`altered in that alterations are rendered impossible because alterations break the key pair connection and thus would infringe under the doctrine of equivalents as well.
`
`
`7
`
`Page 15 of 61
`
`

`

`‘730 Patent Claim2
`
` 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;
` responsive to receiving a request for
`a biometric verification of the user,
`receiving scan data from a biometric
`scan;
`
` comparing the scan data to the
`biometric data to determine whether
`the scan data matches the biometric
`data;
`
` 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
`
`
`
`Accused Instrumentality And Where Each Claim Element Is Found3
`device 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.
`
`
`Android’s development documentation describes that biometric data may include, for example, face
`recognition or a fingerprint (a subset of a palm print): “One method of protecting sensitive information
`or premium content within your app is to request biometric authentication, such as using face
`recognition or fingerprint recognition. This guide explains how to support biometric login flows in your
`app.” PROX_GOOGLE_003271, https://developer.android.com/training/sign-in/biometric-auth
`
`Google describes the use of Passkeys as a biometric alternative to remembering passwords.
`PROX_GOOGLE_003243, Passwordless login with passkeys | Authentication | Google for
`Developers (“Passkeys are a safer and easier alternative to passwords. With passkeys, users can sign in
`to apps and websites with a biometric sensor (such as a fingerprint or facial recognition), PIN, or
`pattern, freeing them from having to remember and manage passwords.”) Signing