`
`UNITED STATES DISTRICT COURT
`FOR THE WESTERN DISTRICT OF TEXAS
`
`Civil Action No. 6:23-cv-320
`
`PROXENSE, LLC,
`
`Plaintiffs,
`
`v.
`
`GOOGLE LLC and GOOGLE PAYMENT
`CORP.
`
`JURY TRIAL REQUESTED
`
`Defendants.
`
`COMPLAINT FOR PATENT INFRINGEMENT
`
`Plaintiff Proxense, LLC (“Proxense” or “Plaintiff”) hereby sets forth its Complaint for
`
`patent infringement against Defendants Google LLC and Google Payment Corp. (“Google” or
`
`“Defendant”), and states as follows:
`
`NATURE OF THE CASE
`
`1.
`
`This action is for patent infringement arising under the patent laws of the United
`
`States, 35 U.S.C. §§ 1, et seq. As further stated herein, Proxense alleges that Google infringes one
`
`or more claims of patents owned by Proxense. Accordingly, Proxense seeks monetary damages
`
`and injunctive relief in this action.
`
`THE PARTIES
`
`2.
`
`Plaintiff Proxense, LLC is a Delaware company with its principal place of business
`
`at 689 NW Stonepine Drive, Bend, Oregon 97703.
`
`3.
`
`On information and belief, Google LLC is a Delaware corporation with a physical
`
`address of 500 West Second Street, Austin, Texas, 78601. On information and belief, Google LLC
`
`Page 1 of 57
`
`GOOGLE EXHIBIT 1013
`
`
`
`Case 6:23-cv-00320-ADA Document 1 Filed 05/02/23 Page 2 of 57
`
`also maintains a regular and established place of business at 110 East Houston Street, #300, San
`
`Antonio, Texas 78205. Google LLC is registered to do business in the State of Texas and has been
`
`registered since 2006. Google LLC may be served through its registered agent, the Corporation
`
`Service Company d/b/a CSC – Lawyers Incorporating Service Company, at 211 East Seventh
`
`Street, Suite 620, Austin, Texas, 78701 - 3218.
`
`4.
`
`Google Payment Corp. is a Delaware corporation and maintains its principal place
`
`of business at 1600 Amphitheatre Parkway, Mountain View, California 94043. Google Payment
`
`Corp. is registered to do business in the State of Texas and has been registered since 2005. Google
`
`Payment Corp. may be served with process through its registered agent, Corporation Service
`
`Company d/b/a CSC – Lawyers Incorporating Service Company, at 211 East Seventh Street, Suite
`
`620, Austin, Texas, 78701 - 3218.
`
`JURISDICTION AND VENUE
`
`5.
`
`This Court has exclusive subject matter jurisdiction over this case pursuant to 28
`
`U.S.C. §§ 1331 and 1338(a) on the grounds that this action arises under the Patent Laws of the
`
`United States, 35 U.S.C. § 1 et seq., including, without limitation, 35 U.S.C. §§ 271, 281, 284, and
`
`285.
`
`6.
`
`This Court has personal jurisdiction over Google LLC and Google Payment Corp.
`
`(collectively, “Google”) because Google is a multinational technology company that has a
`
`significant presence in the District through the products and services Google provides residents of
`
`this District. Defendants regularly conduct business and have committed acts of patent
`
`infringement within this Judicial District that give rise to this action and have established minimum
`
`contacts within this forum such that the exercise of jurisdiction over Google would not offend
`
`traditional notions of fair play and substantial justice. Google has committed and continues to
`
`
`
`2
`
`Page 2 of 57
`
`
`
`Case 6:23-cv-00320-ADA Document 1 Filed 05/02/23 Page 3 of 57
`
`commit acts of infringement in this Judicial District, by, among other things, offering to sell,
`
`selling, using, importing, and/or making products and services that infringe the asserted patents.
`
`Google has further induced acts of patent infringement by others in this Judicial District and/or
`
`has contributed to patent infringement by others in this Judicial District, the State of Texas, and
`
`elsewhere in the United States.
`
`7.
`
`On information and belief, Google has authorized retailers in this Judicial District
`
`that offer and sell products on its behalf in this District, including products accused of infringement
`
`herein. On information and belief, these include Best Buy, e.g., at 4627 S. Jack Kultgen Expy.,
`
`Waco, TX 76706; Target, e.g., at 5401 Bosque Blvd., Waco, TX 76710; T-Mobile, e.g., 100 N
`
`New Rd Ste 110, Waco, TX 76710 and 2448 West Loop 340 Suite 24a, TX 76711; and Verizon,
`
`e.g., 1820 S Valley Mills Dr., Waco, TX 76711 and 2812 W Loop 340 Waco, TX, 76711.
`
`8.
`
`Proxense’s causes of action arise directly from Google’s business contacts and
`
`other activities in the State of Texas and this District.
`
`9.
`
`Google has derived substantial revenues from its infringing acts within the State of
`
`Texas and this District.
`
`10.
`
`Venue is proper in this Judicial District pursuant to 28 U.S.C. § 1400(b). Google is
`
`registered to do business in Texas and, upon information and belief, Google has transacted
`
`business in the Western District of Texas and has a regular and established places of business in
`
`this Judicial District.
`
`11.
`
`Joinder of Google LLC and Google Payment Corp. is proper because they are
`
`related entities that are either jointly and severally liable for infringement, or that make, use, sell,
`
`offer to sell, and/or import the same or similar products accused of infringement herein. Further,
`
`upon information and belief, Google LLC and Google Payment Corp. act in concert to provide the
`
`
`
`3
`
`Page 3 of 57
`
`
`
`Case 6:23-cv-00320-ADA Document 1 Filed 05/02/23 Page 4 of 57
`
`software, hardware, infrastructure, and payment networks used by the accused products.
`
`Therefore, the factual question of infringement will substantially overlap between Google LLC
`
`and Google Payment Corp. Additionally, Proxense anticipates there will be substantial overlap
`
`with respect to discovery.
`
`12.
`
`Google also maintains a significant physical presence in this Judicial District and
`
`employs many people in this Judicial District. According to CultureMap Austin, Google already
`
`leases more than 550,000 square feet at three locations in and around downtown Austin: 100
`
`Congress Ave., 901 E. Fifth St., and 500 W. Second St. See John Egan, “Austin’s next iconic high-
`
`rise sails towards opening date with Google as anchor tenant,” CultureMap Austin (March 19,
`
`2021) See Exhibit 7 In addition to its current offices, including its Austin headquarters at 500 W
`
`2nd Street in Austin, Google has leased an entire building down the street at 601 West 2nd Street
`
`that is being built out. Last year, Google announced that it plans to occupy the 37-story building,
`
`which will be Austin’s tallest office tower and contains 814,081 square feet. Id.
`
`13.
`
`Google currently employs approximately 1,100 people in Austin. Among these
`
`employees are people specifically responsible for the infringing technology in this lawsuit. For
`
`example, Nik Bhattacharya, a Senior Software Engineering Manager, who works for Google in
`
`Austin, Texas, describes on his LinkedIn profile that he is “[l]eading the FIDO passkeys effort at
`
`Google.” See Exhibit 8. Aspects of Google’s particular implementation of FIDO are among the
`
`grounds for the claims of patent infringement asserted here.
`
`14.
`
`On Google’s Careers website, careers.google.com, as of December 15, 2022,
`
`Google lists 209 open jobs for its Austin, Texas location. Many of its jobs list multiple potential
`
`locations for the job applicant to work from, because Google employees are able to work
`
`collaboratively from essentially anywhere, on the “cloud,” because all relevant information,
`
`
`
`4
`
`Page 4 of 57
`
`
`
`Case 6:23-cv-00320-ADA Document 1 Filed 05/02/23 Page 5 of 57
`
`including on information and belief documents relevant to this litigation, including documents and
`
`code are decentralized and exist on Google’s intranet that is available from any of its physical
`
`office locations, or even remotely. By way of a non-limiting example, as of December 15, 2022,
`
`Google’s Careers website had a listing for a Senior Product Manager, Core Privacy, Safety, and
`
`Security. The position listed potential in-office locations as Seattle, Washington; Austin, Texas;
`
`and New York City, New York. The position’s responsibilities included: “[l]aunch[ing] new
`
`products and features…”; “[w]ork[ing] collaboratively with engineering, marketing, legal, UX,
`
`and other teams on cutting edge technologies”; and “[d]evelop[ing] solutions to problems by
`
`collaborating as needed across regions, product areas, and functions.”
`
`15.
`
`On information and belief, Google has also committed acts of direct and indirect
`
`infringement in the Western District of Texas. For example, Google sells its Pixel line of phones
`
`to individuals in this Judicial District, which ship with various versions of the Android operating
`
`system (“Android OS” or “Android”). Google also distributes Google Pay, also known as “G
`
`Pay,” “Pay with Google” and “Android Pay” which it describes as a “simple, secure way to pay
`
`and save,” in this Judicial District, both on its Pixel phones and otherwise. See Exhibit 9.
`
`PATENTS-IN-SUIT
`
`16.
`
`On January 8, 2013, the United States Patent and Trademark Office duly and legally
`
`issued U.S. Patent No. 8,352,730 (the “730 Patent”) entitled “Biometric Personal Data Key (PDK)
`
`Authentication.” A true and correct copy of the 730 Patent is attached hereto as Exhibit 1.
`
`17.
`
`On November 11, 2014, the United States Patent and Trademark Office duly and
`
`legally issued U.S. Patent No. 8,886,954 (the “954 Patent”) entitled “Biometric Personal Data Key
`
`(PDK) Authentication.” A true and correct copy of the 954 Patent is attached hereto as Exhibit 2.
`
`
`
`5
`
`Page 5 of 57
`
`
`
`Case 6:23-cv-00320-ADA Document 1 Filed 05/02/23 Page 6 of 57
`
`18.
`
`On March 26, 2016, the United States Patent and Trademark Office duly and legally
`
`issued U.S. Patent No. 9,298,905 (the “905 Patent”) entitled “Biometric Personal Data Key (PDK)
`
`Authentication.” A true and correct copy of the 905 Patent is attached hereto as Exhibit 3.
`
`19.
`
`On February 4, 2014, the United States Patent and Trademark Office duly and
`
`legally issued U.S. Patent No. 8,646,042 (the “042 Patent”) entitled “Hybrid Device Having a
`
`Personal Digital Key and Receiver-Decoder Circuit and Methods of Use.” A true and correct copy
`
`of the 042 Patent is attached hereto as Exhibit 4.
`
`20.
`
`On June 13, 2017, the United States Patent and Trademark Office duly and legally
`
`issued U.S. Patent No. 9,679,289 (the “289 Patent”) entitled “Hybrid Device Having a Personal
`
`Digital Key and Receiver-Decoder Circuit and Methods of Use.” A true and correct copy of the
`
`289 Patent is attached hereto as Exhibit 5.
`
`21.
`
`On September 11, 2018, the United States Patent and Trademark Office duly and
`
`legally issued U.S. Patent No. 10,073,960 (the “960 Patent”) entitled “Hybrid Device Having a
`
`Personal Digital Key and Receiver-Decoder Circuit and Methods of Use.” A true and correct copy
`
`of the 960 Patent is attached hereto as Exhibit 6.
`
`22.
`
`Proxense is the sole and exclusive owner of all right, title, and interest to and in, or
`
`is the exclusive licensee with the right to sue for, the 730, 954, 905, 042, 289, and 960 Patents
`
`(together, the “Patents-in-Suit”), and holds the exclusive right to take all actions necessary to
`
`enforce its rights to the Patents-in-Suit, including the filing of this patent infringement lawsuit.
`
`Proxense also has the right to recover all damages for past, present, and future infringement of the
`
`Patents-in-Suit and to seek injunctive relief as appropriate under the law.
`
`23.
`
`The technologies of the Patents-in-Suit were invented by John Giobbi. The 730
`
`and 905 Patents generally cover systems and methods for an integrated device that persistently
`
`
`
`6
`
`Page 6 of 57
`
`
`
`Case 6:23-cv-00320-ADA Document 1 Filed 05/02/23 Page 7 of 57
`
`stores biometric data for a user in a tamper-resistant format. Subsequently, scan data collected
`
`from a user (e.g., a fingerprint) can be compared against the stored biometric data. Once the user
`
`has been biometrically verified by the integrated device, a code can be wirelessly transmitted for
`
`authentication. The 042, 289, and 960 Patents generally covers systems, devices, and methods of
`
`utilizing personal digital keys for verifying a user in order to enable applications, functions, or
`
`services.
`
`FACTUAL ALLEGATIONS
`
`I.
`
`TECHNOLOGY BACKGROUND
`
`24.
`
`Authentication is the process by which the identity of a user is confirmed on a
`
`device, including computers, tablets, and phones. When a person is authenticated, the goal is to
`
`verify that the credentials presented are authentic. For years, users were authenticated with
`
`usernames and passwords. However, with the amount of sensitive personal and financial
`
`information currently stored on personal devices, and the rise of biometric readers and high-speed
`
`networks, there was a need to implement improved authentication architectures.
`
`25.
`
`One such architecture is “federated authentication” (also known as “federated
`
`identity”), which relies on an external trusted system to authenticate users. In a federated
`
`authentication solution, the system being accessed must request authentication of the user from
`
`the external system that is used to authenticate users. The external system authenticating the user
`
`will then communicate successful authentication back to the system being accessed. Successful
`
`authentication is communicated between the two systems with the issuance security tokens
`
`containing claims about user authentication. Upon successful authentication of a user, the
`
`external system issues a security token which can be exchanged for access to the other system.
`
`One such federated architecture is OpenID Connect.
`
`
`
`7
`
`Page 7 of 57
`
`
`
`Case 6:23-cv-00320-ADA Document 1 Filed 05/02/23 Page 8 of 57
`
`26. While OpenID connect limited the use of passwords, it did not eliminate them.
`
`Authentication protocols geared towards eliminating passwords include WebAuthn and its
`
`derivative, FIDO2, an open authentication standard developed by the FIDO alliance. WebAuthn,
`
`and the derivative protocol FIDO2, utilize an asymmetric key pair to authenticate a device.
`
`Possession and control of the device verifies the identity of the user. The device, referred to as
`
`an authenticator, generates a private/public key pair and a credential ID uniquely identifying the
`
`key pair. The public key and credential ID are sent to the authentication server – called in the
`
`protocol the “relying party”. The private key is held by the authenticator. During authentication,
`
`the authenticator sends a signature generated with its private key and the credential ID
`
`identifying the private key used to generate the signature. The relying party (i.e., authentication
`
`server) uses the credential ID to retrieve the matching public key. The signature is then verified
`
`with the public key. Upon successful verification of the signature, the relying party issues an
`
`authentication response.
`
`27. WebAuthn and federated protocols can be combined. When combined, the
`
`system to be accessed by the user requests authentication by a WebAuthn / FIDO 2 server. The
`
`server issues an authentication request to the user’s authenticator. The authenticator responds by
`
`providing a signature and credential ID to the WebAuthn/FIDO2 server. If the signature is
`
`verified, the WebAuthn/FIDO2 server informs the OpenID connect of successful authentication.
`
`The OpenID connect server then sends a security token to be used to access the system
`
`requesting authentication.
`
`28.
`
`Attempting to eliminate the user of passwords, Google has developed a universal
`
`platform “passwordless” architecture. The architecture is universal in that it works across
`
`platforms, such as iOS, Android, and Windows. It is password-less in that passwords have been
`
`
`
`8
`
`Page 8 of 57
`
`
`
`Case 6:23-cv-00320-ADA Document 1 Filed 05/02/23 Page 9 of 57
`
`replaced with the use of authenticators incorporated into Android OS 9 and higher.
`
`Incorporating OpenID Connect, Google’s architecture relies on the issuance of security tokens.
`
`The hub of Google’s universal platform password-less architecture is Google Identity, which
`
`receives authentication requests from external systems, coordinates the action of authenticators,
`
`and issues security tokens.
`
`29.
`
`Federated authentication is not the only authentication architecture Google has
`
`incorporated into the Android OS. Google has incorporated EMV’s payment tokenization
`
`architecture. As with OpenID Connect, EMV’s payment tokenization utilizes token issued by a
`
`third-party and stored on the phone. The tokens are a surrogate for a credit card, debit card, or
`
`other Primary Account Number (PAN), and can be used anywhere the underlying account is
`
`accepted as payment. As with OpenID Connect tokens, EMV payment tokens indicate a previous
`
`authentication of the user. The tokens differ with respect to authorization claims. OpenID
`
`authenticates the user and obtains the user’s consent before issuing a token. As such, the token
`
`represents authentication of the user and what the user has been authorized. As authorization is
`
`obtained before token issuance, a token can never be used for more than authorization claim it
`
`contains. EMV tokens, on the other hand, contain no claims with respect to authorization.
`
`Authorization, rather, is indicated by release of payment from a device. Unlike OpenID Connect
`
`tokens, payment tokens are locked in a device and can only be released following verification of
`
`the user by the device. As only the legitimate use can be verified, release of an EMV token is
`
`indicative of user consent. Presentation of an EMV payment token, accordingly, is indicative of
`
`user consent to the accompany charge to their account. Regardless of the differences in their
`
`manner of representing authorization and the timing of obtaining authorization, both OpenID
`
`connect tokens and EMV tokens are indicative of user authentication and authorization.
`
`
`
`9
`
`Page 9 of 57
`
`
`
`Case 6:23-cv-00320-ADA Document 1 Filed 05/02/23 Page 10 of 57
`
`30.
`
`As to facilitate the use of EMV’s payment tokenization architecture, Google has
`
`deployed technology to secure payment tokens in connection with its Android OS, Google Pay
`
`(initially and subsequently called Google Wallet, collectively “Google Pay” unless otherwise
`
`specified). Using biometric security features (i.e., the ability to unlock mobile devices through a
`
`fingerprint or facial recognition) available in Android, Google offered biometric authentication of
`
`the Google Pay app, in 2019. See Exhibit 10. Previously, the only Google Pay authentication
`
`option was entering a PIN number, which is guessable and “crackable,” as opposed to more secure
`
`and user-friendly biometrics.
`
`31.
`
`Incorporating authenticators (including Google’s Authenticator) into the Android
`
`OS is, on information and belief, necessary for Google Cloud Services to remain competitive with
`
`Microsoft’s cloud services, which supports the Windows 10/11 integrated authenticator, Windows
`
`Hello, and the iOS/Android authenticator, Microsoft Authenticator. The worldwide public cloud
`
`services market had revenues in 2021 totaling $408.6 billion. Likewise, the ability to secure
`
`Google Pay transactions with biometrics was, on information and belief, important for Google to
`
`remain competitive with Apple Pay and other payment platforms that had implemented the feature.
`
`Global contactless transaction values were estimated at $2 trillion in 2020. By 2024, they may
`
`reach $6 trillion according to forecasts. Mobile payments, or transactions initiated on mobile
`
`devices such as cell phones or tablet computers, have become increasingly popular with the
`
`increasing use of applications like Google Pay (also known as Google Wallet), launched in 2011.
`
`
`
`10
`
`Page 10 of 57
`
`
`
`Case 6:23-cv-00320-ADA Document 1 Filed 05/02/23 Page 11 of 57
`
`II.
`
`PROXENSE AND ITS INNOVATIVE TECHNOLOGIES
`
`32.
`
`Proxense was founded in 2001.1 From approximately 2004-2012, Proxense
`
`developed, inter alia, mobile payment technologies and commercial products, employing over
`
`thirty engineers, and investing many millions of dollars in product development and other research
`
`and development efforts. Foundational capabilities of Proxense’s technologies included a secure
`
`element, biometrics captured and stored thereon, retrieval of biometrics and token passing to a
`
`trusted third party, and completion of a mobile payment transaction.
`
`33.
`
`Proxense also developed sophisticated, proprietary, proximity-based detection,
`
`authentication, and automation technology, built on the concept of wirelessly detecting,
`
`authenticating, and communicating with personal digital keys (“PDKs”). Proxense’s technology
`
`enabled PDKs to run for as long as two years on tiny batteries. “ProxPay” technology also included
`
`biometrically-based user and device authentication options, the ability to conduct biometric-
`
`verified transactions without sending or exposing the underlying biometric data or storing it
`
`anywhere except the PDK, and the incorporation of a registration for maintaining or verifying the
`
`PDK. Significant financial and engineering resources were deployed to make this possible. The
`
`resulting developments became primary differentiators of Proxense’s product line, and significant
`
`elements on which its business was built.
`
`34.
`
`John Giobbi is the founder and CEO of Proxense. He is an experienced product
`
`designer and prolific inventor (a named inventor on approximately 200 patents, including the
`
`asserted patents), with over 35 years of experience as an entrepreneur and product development
`
`executive. For example, Mr. Giobbi was a Senior Vice President at WMS Gaming, and managed
`
`
`1 The company was formally incorporated as an LLC in 2001 under the name Margent
`Development LLC; in 2005, the business was renamed to Proxense LLC.
`11
`
`
`
`Page 11 of 57
`
`
`
`Case 6:23-cv-00320-ADA Document 1 Filed 05/02/23 Page 12 of 57
`
`over 200 staff; in his six-year tenure at that company, its market capitalization soared from
`
`approximately $80 million to about $1 billion. Mr. Giobbi was also the founder and President of
`
`Prelude Technology Corp. and InPen.
`
`35.
`
`The innovative, visionary nature of Proxense’s technology was recognized in the
`
`media, beginning in mid-2008, when, The Bulletin featured a story on Proxense’s mobile payment
`
`technology, titled “A pint-sized virtual wallet.” Andrew Moore, The Bulletin (May 7, 2008),
`
`Exhibit 11. The story describes a future that greatly resembles the present-day, including a
`
`“wireless wallet” and “fingerprint” verification, including the use of such technology to pay for
`
`goods using such wireless methods protected by biometric measures like a fingerprint. In 2009,
`
`Trend Hunter ran a similar story titled “Virtual Biometric Wallets,” featuring Proxense and Mr.
`
`Giobbi. Michael Plishka, Trend Hunter (January 4, 2009), See Exhibit 12.
`
`36.
`
`Another 2009 article, ran in DARKReading, a publication in InformationWeek’s
`
`IT Network, also featured the company and Mr. Giobbi in an article titled “Startup May Just
`
`Digitize Your Wallet.” George V. Hulme, DARKReading (February 8, 2009), See Exhibit 13.
`
`The DARKReading article described that Proxense was “in the process of bringing to market a
`
`proximity-based communications device that aims to provide a way to securely share information
`
`and conduct payments.” Proxense’s Personal Digital Keys (PDKs) were described as “carried by
`
`users, perhaps even within a cell phone, and can security hold data and manage authentication.”
`
`Mr. Giobbi explained that “the data within the PDK also can be protected by additional layers of
`
`authentication, such as biometric…”
`
`37.
`
`It would be years until products like Google Wallet (2011), Apple Pay (2014), and
`
`Samsung Pay (2015) were launched and became mainstream; Apple’s TouchID, which involves
`
`fingerprint recognition technology, for example, was introduced in 2013. It would take Google
`
`
`
`12
`
`Page 12 of 57
`
`
`
`Case 6:23-cv-00320-ADA Document 1 Filed 05/02/23 Page 13 of 57
`
`until 2019 to enable biometric authentication for Android 10 phones and Google Pay.
`
`Accordingly, Proxense’s technology was years ahead of the industry.
`
`38.
`
`After the launch of services like Google Wallet/Pay, and its inextricable link to the
`
`some of the most popular smartphone hardware devices in the United States, and the world,
`
`Proxense would find itself unable to compete with companies like Google, even though Proxense
`
`invented the technology utilized in these solutions.
`
`39.
`
`Today, Proxense holds 80 patents on related technology, including digital content
`
`distribution, digital rights management, personal authentication, biometric data management and
`
`mobile payments. Proxense continues to prosecute new patents on its proprietary technology.
`
`III.
`
`INFRINGEMENT ALLEGATIONS
`
`1.
`
`40.
`
`The Accused Products
`
`Through its own actions, and the actions of its customers and users, which Google
`
`directs and controls, Google has manufactured, used, marketed, sold, offered for sale, and exported
`
`from and imported into the United States a universal platform password-less architecture that
`
`directly and/or indirectly infringes (and literally or via the doctrine of equivalents) the Patents-in-
`
`Suit. Accordingly, the Accused Products include the servers, cloud resources, and software
`
`comprising Google’s password-less architecture and devices including, supporting and integrating
`
`into the architecture, including devices running the Android OS, Chrome OS, and/or Chrome
`
`browser.
`
`41.
`
`Three primary components make up the infringing identity architecture. The first
`
`is Google Identity (also known as Google Identity Services) which coordinates the actions of the
`
`other components by authenticating users and issuing various bearer tokens. See e.g., Exhibit 14.
`
`The second is an authenticator, like Google Authenticator, permitting user verification by Google
`
`
`
`13
`
`Page 13 of 57
`
`
`
`Case 6:23-cv-00320-ADA Document 1 Filed 05/02/23 Page 14 of 57
`
`Identity. During verification, Google Identity issues commands to the authenticators (called
`
`“requests”). The operation of the authenticators, accordingly, is controlled by Google. The third
`
`component of the system is a resource, such as an application, website, or subscription, requesting
`
`authentication of the user. During user login, the resource sends requests to a URL provided by
`
`Google and in a form dictated by Google. The resource then listens for a reply at a callback URL
`
`the resource registered with Google. As with the requests, the callbacks are in the form dictated
`
`by Google. The resources are hosted by device and/or server separate from Google Identity.
`
`Accordingly, the resource and Google Identity are separate and distinct entities and the resource
`
`(not Google Identity) is the system being accessed.
`
`42.
`
`Google utilizes Google Identity to sign users into Gmail, Google Drive, Google Pay
`
`and other services and products offered by Google. Google sells access to Google Identity to
`
`developers, websites, and corporate clients through various subscriptions. Thus, for a fee, Google
`
`Identity becomes an identity provider for applications, businesses, and websites. Selling such
`
`identity and access management (IAM) services and controlling the actions of subscribers and
`
`users, Google directly and/or indirectly infringes (and literally or under the doctrine of equivalents)
`
`the Patents-in-Suit. Furthermore, by utilizing Google Platform for its own product and services,
`
`Google directly and/or indirectly infringes (and literally or via the doctrine of equivalents) the
`
`Patents-in-Suit.
`
`43.
`
`As noted above, Google’s infringing universal platform password-less architecture
`
`includes an authenticator. One authenticator distributed by Google is a native component of
`
`Android OS 9 and higher. Accordingly, since at least August 6, 2018, if not earlier, the Android
`
`OS has enabled password-less sign-in to services and subscriptions offered by Google. See
`
`Exhibit 15. Another authenticator developed by Google is the Titan Security Key that includes
`
`
`
`14
`
`Page 14 of 57
`
`
`
`Case 6:23-cv-00320-ADA Document 1 Filed 05/02/23 Page 15 of 57
`
`the functionality to wirelessly verify a user during authentication of an iOS compatible devices.
`
`Exhibit 16. The current and previous versions of the Android OS and Titan Security Key are non-
`
`limiting instances of authenticators integrated into the Accused Products.
`
`44.
`
`Google Identity, which directs and controls the actions of the authenticator, is also
`
`an element of the Accused Products. Google Identity includes a series of APIs launched on August
`
`3, 2021. See Google Developers Blog: Launching our new Google Identity Services APIs
`
`(googleblog.com), August 3, 2021, Exhibit 17 (“Today we are launching our new family of
`
`Identity APIs called Google Identity Services.”). Google operates and maintains Google Identity.
`
`When combined with authenticators, such the Android OS and Titan Security Key, consumers of
`
`Google’s products and services receive the benefit of password-less biometric authentication
`
`across platforms. For instance, a user may log into and utilize Gmail or Google Pay on their
`
`Windows PC or iOS device. Third party developers can purchase identity and access management
`
`services from Google to integrate their applications with Google Identity in order to offer cross
`
`platform password-less authentication via biometrics and the use of ID and access tokens to their
`
`customers and subscribers. Developers subscribing to Google Identity must register their
`
`application or website with Google, request authentication by sending a request to a URL provided
`
`by Google and in a format dictated by Google, and listen for a callback provided by Google that
`
`contains a message generated by Google in a format controlled by Google.
`
`45.
`
`The Accused Products also include a resource accessed following successful
`
`authentication of the authenticator by Google Identity. As noted above, the resource may be an
`
`application, website, and/or a subscription offered by Google, a subscribing business, or a
`
`subscribing developer. When a user has been authenticated via an authenticator offered by Google,
`
`various bearer tokens are returned by Google to the callback URL registered with Google Identity.
`
`
`
`15
`
`Page 15 of 57
`
`
`
`Case 6:23-cv-00320-ADA Document 1 Filed 05/02/23 Page 16 of 57
`
`The bearer token allows access to the application, and as such is an access message. Regardless
`
`of whether the resource is an application, a subscription, or a service offered by Google or a
`
`subscribing developer or business, the resource is on a system separate and distinct from Google
`
`Identity. Distribution of bearer tokens and other such access messages by Google Identity is thus
`
`necessary for Google Identity to inform the resource that the user has been successfully
`
`authenticated via an authenticator distributed by Google. As the bearer tokens are generated and
`
`distributed by Google Identity, Google controls their form and how they are distributed.
`
`46.
`
`Current and previous versions of Google Identity are non-limiting instances of the
`
`Accused Products.
`
`47.
`
`Another instance of the accused product is Google Wallet (also known as Google
`
`Pay), which includes functionality to biometrically verify a user during authentication of a
`
`smartphone. Google Pay is operable on a range of devices, including, at least all recent
`
`smartphones that run the Android OS, such the Google Pixel line of smartphones. Current and
`
`previous versions of Google Pay, and Google devices such as the Pixel that use Google Pay, alone
`
`and together, are further non-limiting instances of the Accused Products.
`
`48.
`
`The Accused Products practice the claims of the Patents-in-Suit to improve security
`
`and/or the shopping experience of Google’s users, and to improve Google’s position in the market.
`
`49.
`
`Google directly infringes the Patents-in-Suit through the operation of the foregoing
`
`as directed and control by Google. The Accused Products practice the claims of the Patents-in-
`
`Suit to improve the user experience of Google’s customers and those of subscribing developers,
`
`and to improve Google’s position in the market with