throbber
Case 6:23-cv-00320-ADA Document 1 Filed 05/02/23 Page 1 of 57
`
`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 1012
`
`

`

`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

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket