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 49
`
`GOOGLE EXHIBIT 1015
`
`

`

`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 49
`
`

`

`
`
`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 49
`
`

`

`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 49
`
`

`

`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 49
`
`

`

`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 49
`
`

`

`
`
`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 49
`
`

`

`Exhibit B1
`Exhibit B1
`
`Page 8 of 49
`
`Page 8 of 49
`
`

`

`U.S. Patent Number 9,298,905 – Preliminary Infringement Contentions1
`
`
`Assignee:
`Title:
`Filing Date:
`Publication Date:
`Inventor:
`
`Proxense, LLC
`Biometric personal data key (PDK) authentication
`2014-10-23
`2016-03-29
`Giobbi, John J.
`
`
`
`‘905 Patent Claim2
`1
`A method comprising4:
`
`Accused Instrumentality And Where Each Claim Element Is Found3
`This preamble is not limiting.
`
`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 device 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.
`
`
`Page 9 of 49
`
`

`

`persistently storing biometric
`data of a legitimate user and an
`ID code on an integrated
`device;
`
`
`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 legitimate user
`
`
`Saving cards to their Google Account enables an expedited checkout process when shopping
`online. See PROX_GOOGLE_003232, Overview | Google Pay API | Google for Developers
`(“When a user clicks the Google Pay payment button, they see a payment sheet that displays the
`payment methods saved to their Google Account, as well as optional fields such as a shipping
`address field. Users can quickly select a payment method, add an optional shipping address, or
`add new information.”). Expediting checkout with saved cards, however, requires the user sign
`into their Google Account, which can be accomplished using biometrics persistently stored on
`Android devices.
`
`Starting with Android 10, Google stored biometric data on Android devices includes a
`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”).
`Android Open-Source Project: Fingerprint HIDL,
`https://source.android.com/docs/security/features/authentication/fingerprint-hal
`
`Per Google’s instructions, Android devices store the biometric data of a legitimate user of the
`device.
`
`
`
`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).
`
`Page 10 of 49
`
`

`

`
`
`
`
`PROX_GOOGLE_002913,
`https://source.android.com/docs/security/features/biometric#android10
`
`persistently storing … an ID code on an integrated device
`
`
`Saving cards to their Google Account enables an expedited checkout process when shopping
`online. See PROX_GOOGLE_003232, Overview | Google Pay API | Google for Developers
`(“When a user clicks the Google Pay payment button, they see a payment sheet that displays the
`payment methods saved to their Google Account, as well as optional fields such as a shipping
`address field. Users can quickly select a payment method, add an optional shipping address, or
`add new information.”). Expediting checkout with saved cards, however, requires the user sign
`into their Google Account, which can be accomplished using device-bound public keys
`persistently stored on Android devices
`
`The Android OS natively includes the Android SafetyNet Authenticator, which is FIDO certified.
`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
`
`Page 11 of 49
`
`

`

`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 an 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 a 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 id. 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. 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 -
`
`Page 12 of 49
`
`

`

`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. Id. 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 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.” PROX_GOOGLE_003187, Google Online Security Blog: Security of
`Passkeys in the Google Password Manager, October 12, 2022,
`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.
`
`
`
`Google describes the use of Passkeys as a biometric alternative to remembering passwords.
`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 in with a biometric sensor necessarily requires prompting
`a user for a response to an authentication request wherein Google receives scan data from a biometric
`scan. Google utilizes the biometric sensors in smartphones, tablets, and computers to receive data from
`those biometric scans.
`
`responsive to receiving a
`request for a biometric
`verification of a user, receiving
`from a biometric sensor, scan
`data from a biometric scan
`performed by the biometric
`sensor;
`
`Page 13 of 49
`
`

`

`
`
`comparing the scan data to the
`biometric data to determine
`whether the scan data matches
`the biometric data;
`
`
`
`Passwordless login with passkeys | Authentication | Google for Developers
`PROX_GOOGLE_003243, https://developers.google.com/identity/passkeys;
`PROX_GOOGLE_003833, Sign in with a passkey on a phone
`(https://www.youtube.com/watch?v=ywQ8bFla-L8).
`
`
`
`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 in with a biometric
`senssor necessarily requires comparing the scan data to the biometric data to determine whether the scan
`data matches the biometric data.
`
`
`Page 14 of 49
`
`

`

`responsive to a determination
`that the scan data matches the
`biometric data, wirelessly
`sending the ID code for
`comparison by a third-party
`trusted authority against one or
`more previously registered ID
`codes maintained by the third
`party trusted authority
`
`
`
`Passwordless login with passkeys | Authentication | Google for Developers
`PROX_GOOGLE_003243, https://developers.google.com/identity/passkeys;
`PROX_GOOGLE_003833, Sign in with a passkey on a phone
`(https://www.youtube.com/watch?v=ywQ8bFla-L8).
`
`
`responsive to a determination that the scan data matches the biometric data, wirelessly sending
`
`
`As detailed by Google using passkeys to sign into a service or application is a simple as unlocking
`their Android device with fingerprint or facial recognition. PROX_GOOGLE_003192, Google
`Online Security Blog: So long passwords, thanks for all the phish (googleblog.com) (“Passkeys
`are a more convenient and safer alternative to passwords. They work on all major platforms and
`browsers, and allow users to sign in by unlocking their computer or mobile device with their
`fingerprint, face recognition or a local PIN.”); and PROX_GOOGLE_003243, Passwordless login
`with passkeys | Authentication | Google for Developers (“When a user wants to sign in to a
`service that uses passkeys, their browser or operating system will help them select and use the
`right passkey. The experience is similar to how saved passwords work today. To make sure only
`the rightful owner can use a passkey, the system will ask them to unlock their device. This may be
`
`Page 15 of 49
`
`

`

`performed with a biometric sensor (such as a fingerprint or facial recognition), PIN, or pattern.”).
`This ease of access if provided by Google’s FIDO certified SafetyNet Authenticator utilizing the
`FIDO2 API for Android. See PROX_GOOGLE_003775 (“The FIDO2 API allows Android
`applications to create and use strong, attested public key- based credentials for the purpose of
`authenticating users. The API provides a WebAuthn Client implementation, which supports the
`use of BLE, NFC, and USB roaming authenticators (security keys) as well as a platform
`authenticator, which allows the user to authenticate using their fingerprint or screenlock.”) In
`operation, the SafetyNet Authenticator utilizes the native capacities of the Android OS, such as
`the Android Keystore to store the cryptographic public-private key pairs underlying the device-
`bound public key extension. See PROX_GOOGLE_003795 ((“The typical way to develop secure
`authenticator on Android mobile devices (smartphones and tablets) is to use a secured hardware-
`backed operating environment... This includes technology such as TEE (“Trusted Execution
`Environment”) that performs cryptographic and other sensitive operations including digital
`signing and biometric data processing used to support FIDO functionality... Android Keystore
`allows app developers to store cryptographic keys in a container and use them in cryptographic
`operations via APIs. Android also offers protection of the fingerprint sensor data via a TEE, which
`allows for encryption and cryptographic authentication... Adding a small application to
`complement some function that are necessary to perform as UAF 1.1 authenticator enables
`Android Keystore with hardware-backed key attestations and fingerprint sensor to become a
`secure FIDO UAF 1.1 authenticator.”). The Android Keystore securely holds a passkey until it is
`unlocked
`by
`biometric
`verification.
`
`See PROX_GOOGLE_003785;
`also
`see
`PROX_GOOGLE_003177, Fingerprint HIDL | Android Open Source Project (“When generating
`or importing a key into the Android KeyStore, you can specify that the key is only authorized to
`be used if the user has been authenticated. The user is authenticated using a subset of their secure
`lock screen credentials (pattern/PIN/password, biometric credentials).”). Biometric unlocking
`within the Android OS is provided by Fingerprint HIDL. See PROX_GOOGLE_003177,
`Fingerprint HIDL | Android Open Source Project (“On devices with a fingerprint sensor, users
`can enroll one or more fingerprints and use those fingerprints to unlock the device and perform
`other tasks. Android uses the Fingerprint Hardware Interface Definition Language (HIDL) to
`connect to a vendor-specific library and fingerprint hardware (for example, a fingerprint sensor)”).
`Accordingly, by utilizing Fingerprint HIDL in combination with the KeyStore, the Android OS
`releases a passkey after a determination that the scan data matches the biometric data.
`
`As detailed supra, Google utilizes device-bound public key extension, which requires
`concurrently sending a public-key and a signature generated with a device-bound private to be
`verified with the public-key. 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
`
`Page 16 of 49
`
`

`

`proof-of-possession of the device private key by that device.”). As Android devices possess
`cellular and/or Wi-Fi capability, the signature and device bound public key uniquely identifying
`the integrated device sent to Google Identity Platform will be sent wirelessly – either via Wi-Fi
`or a cellular network to the internet.
`
`While the native Android OS authenticator permits the use of passkey in a variety of situations,
`each transmits the device bound public key and corresponding signature over the internet. When
`a user wishes to use a passkey stored on their Android device to access a resource via a browser
`the user is presented with either a QR code or push notification. See PROX_GOOGLE_003236,
`Passkey support on Android and Chrome | Authentication | Google for Developers
`(“Depending on the desktop operating system (e.g. ChromeOS, iOS, MacOS, Windows) users
`may be presented with a QR code to securely use a passkey stored on their mobile device, or a
`notification may be displayed prompting the user to unlock their phone to use the relevant
`passkey.”). In the case of a QR code, the user scans a QR code displayed on the screen of a
`device. PROX_GOOGLE_003192, Google Online Security Blog: So long passwords, thanks
`for all the phish (googleblog.com) (“When you do need to use a passkey from your phone to
`sign in on another device, the first step is usually to scan a QR code displayed by that device.”).
`Proximity between the devices is then verified using Bluetooth. PROX_GOOGLE_003239,
`Passkeys use cases | Authentication | Google for Developers (“The two devices verify that
`they are in proximity with each other using Bluetooth.”). The Bluetooth connection is also
`utilized to establish a secure connection between the devices via the internet.
`PROX_GOOGLE_003192, Google Online Security Blog: So long passwords, thanks for all the
`phish (googleblog.com) (“The device then verifies that your phone is in proximity using a small
`anonymous Bluetooth message and sets up an end-to-end encrypted connection to the phone
`through the internet..”) Utilizing the internet connection, the Android device sends one-time
`passkey signature, including the device-bound public key, to the other device, which is used to
`sign in the user. PROX_GOOGLE_003239, Passkeys use cases | Authentication | Google for
`Developers (“A one-time passkey signature is transferred back to Safari on the Mac, which the
`website then uses to sign the user in.”). Establishing the connection over the internet would
`require utilizing either the device’s wi-fi or cellular capabilities – both of which are wireless
`protocol. Accordingly, responsive to a determination that the scan data matches the biometric
`data, Android devices wirelessly send a passkey signature and accompanying device-bound
`public key uniquely identifying the device.
`
`Push notifications can originate with the “Sign in with Google” button. To receive the benefit of
`quickly and easily managing user authentication utilizing “Sign-in with Google”, the website
`must display a “Sign in with Google” button, which is generated by the Google Identity Services
`JavaScript library, or provide the user the option to sign in with a passkey.
`PROX_GOOGLE_03779 (“Put it another way, the Sign in with Google button must be
`
`Page 17 of 49
`
`

`

`generated by the Google Identity Services JavaScript library now. The button rendering API
`allows you to customize the color, shape, text, and size to meet the branding requirements of
`your website, whereas still stick to Google's guidelines.”); and PROX_G