UNITED STATES DISTRICT COURT
`FOR THE WESTERN DISTRICT OF TEXAS
`
`Civil Action No. 6:23-cv-00319
`
`PROXENSE, LLC,
`
`Plaintiffs,
`
`v.
`
`MICROSOFT CORPORATION,
`
`JURY TRIAL REQUESTED
`
`Defendants.
`
`COMPLAINT FOR PATENT INFRINGEMENT
`
`Plaintiff Proxense, LLC (“Proxense” or “Plaintiff”) hereby sets forth its Complaint for
`
`patent infringement against Defendant Microsoft Corporation (“Microsoft” 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 Microsoft 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, Microsoft is a corporation organized and existing
`
`under the laws of the State of Washington, with a principal place of business in this district
`
`located at 10900 Stonelake Boulevard, Suite 225, Austin, Texas 78759.
`
`1
`
`MICROSOFT 1004
`
`

`

`JURISDICTION AND VENUE
`
`4.
`
`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.
`
`5.
`
`This Court has personal jurisdiction over Microsoft because it has conducted and
`
`continues to regularly conduct business within the State of Texas and this District. Microsoft has
`
`purposefully and voluntarily availed itself of the privileges of conducting business in the United
`
`States, the State of Texas, and this District by continuously and systematically placing goods into
`
`the stream of commerce through an established distribution channel with the expectation that they
`
`will be purchased by consumers in this District. Microsoft directly and/or through intermediaries
`
`(including distributors, sales agents, and others), ships, distributes, sells, offers to sell, imports,
`
`advertises, makes, and/or uses its products (including but not limited to the products accused of
`
`infringement herein) in the United States, the State of Texas, and this District.
`
`6.
`
`Upon information and belief, Microsoft conducts business within the State of Texas
`
`and in this district, and has designated Corporation Service Company d/b/a CSC − Lawyers
`
`Incorporating Service Company, 211 E. 7th Street, STE 620, Austin, Texas 78701-3218, as its
`
`agent for service of process in this district.
`
`7.
`
`On information and belief, Microsoft has been registered to do business within the
`
`State of Texas under Texas Secretary of State File Number 0010404606 since about March 1987.
`
`8.
`
`On information and belief, Microsoft employs one or more of its data centers in
`
`this district in furtherance of infringing acts in this district since at least 2008. For example,
`
`Microsoft maintains data centers in this district, located at: 5150 Rogers Road, San Antonio,
`
`
`
`2
`
`

`

`Texas 78251, 5200 Rogers Road, San Antonio, Texas 78251,1 and 3823 Wiseman Boulevard,
`
`San Antonio, Texas 78251.2
`
`9.
`
`On information and belief, Microsoft has operated data centers supporting
`
`Microsoft products and services within the State of Texas, and within this district, since at least
`
`2008. Microsoft is building at least three additional data centers in this district, including two
`
`data centers located at: 3545 Wiseman Boulevard, San Antonio, Texas 78251, and another data
`
`center located at 15000 Block Lambda Drive, San Antonio, Texas 78245. Upon information and
`
`belief, Microsoft’s data centers, including those in this district, include computer hardware (e.g.,
`
`memory and processors) that store and execute software that performs some of the actions that
`
`infringe on the patents in the lawsuit. On information and belief, Microsoft has employed, is
`
`employing, and is offering to employ individuals in this district in furtherance of infringing acts
`
`in this district. On information and belief, these employees have direct personal knowledge
`
`about the accused products and Microsoft’s infringing activities. For example, Justin Santos,
`
`Senior Cloud Security Architect, purporting according to his LinkedIn profile to be working at
`
`Microsoft in Austin, Texas, describes that he “[d]rive[s] the use and consumption of Microsoft’s
`
`… Identity products and services in highly regulated industries – Financial, Healthcare, Federal,
`
`and State and Local Government across the US as a part of Microsoft’s new Security Solution
`
`Area within Customer Success United (CSU).” These data centers which Microsoft operates
`
`constitute a regular and established physical presence in the district, including, but not limited to,
`
`ownership of or control over property, inventory, or infrastructure.
`
`
`1 See https://www.datacenterhawk.com/providers/microsoft-azure (last accessed April 28, 2023).
`2 See https://www.virtualbx.com/industry-news/san-antonio-microsoft-reaches-mid-point-on-
`86m-expansion-in-westover-hills/ (last accessed April 28, 2023).
`3
`
`
`
`

`

`10.
`
`On information and belief, Microsoft has operated permanent office facilities
`
`within the State of Texas, and within this district, since at least 2000. The offices Microsoft
`
`maintains in this district include locations at 10900 Stonelake Boulevard, Suite 225, Austin,
`
`Texas 787593 and Concord Park II, 401 East Sonterra Boulevard, Suite 300, San Antonio, Texas
`
`78258.
`
`11. Microsoft operates offices in Austin, Texas for the purpose of selling, promoting,
`
`maintaining, and providing support for a suite of products, including the accused products.
`
`12.
`
`On information and belief, Microsoft maintains a “Corporate Sales Offices” in
`
`Austin, Texas at the following address: 10900 Stonelake Boulevard, Suite 225 Austin, TX,
`
`78759; and Microsoft maintains a “Corporate Sales Office” in San Antonio, Texas at the
`
`following address: Concord Park II 401 East Sonterra Boulevard, Suite 300, San Antonio, TX,
`
`78258.
`
`13.
`
`On information and belief, one or more of the Accused Products are used, offered
`
`for sale, and sold in this district, including by Microsoft and by “Microsoft-certified resellers”
`
`(e.g., Heart of Texas Network Consultants, located at 703 Willow Grove Rd., Waco, Texas
`
`76712).
`
`14.
`
`On information and belief, Microsoft operated at least ten physical stores
`
`throughout Texas, some of which were in this district, from 2009 until they were all closed in
`
`2020. During that time period, Microsoft had physical stores that sold Microsoft’s products at
`
`least at the following addresses: (a) 3309 Esperanza Crossing, Austin, TX 78758 and (b) 15900
`
`La Cantera Parkway The Shops at La Cantera San Antonio, TX 78256.
`
`
`3 See https://news.microsoft.com/2000/01/05/microsoft-opens-austin-texas-facility/ (last accessed
`April 28, 2023).
`
`
`
`4
`
`

`

`15.
`
`Proxense’s causes of action arise directly from Microsoft’s business contacts and
`
`other activities in the State of Texas and this District.
`
`16. Microsoft has derived substantial revenues from its infringing acts within the State
`
`of Texas and this District.
`
`17.
`
`In other recent actions, Microsoft has either admitted or not contested that this
`
`federal judicial district is a proper venue for patent infringement actions against it. See, e.g.,
`
`Thompson v. Microsoft Corp., No. 1:19-cv-00680-RP, Dkt. No. 6; Panther Innovations v.
`
`Microsoft Corp., No. 6-20-cv-01071, Dkt. No. 14; Exafer Ltd. v. Microsoft Corp., No 1-20-cv-
`
`00131, Dkt. No. 15; WSOU Investments, LLC v. Microsoft Corp., No. 20-cv-00464, Dkt. No. 20;
`
`Zeroclick, LLC v. Microsoft Corp., No. 20-cv-00272, Dkt. No. 14; and California Institute of
`
`Technology v. Microsoft Corp., No. 21-cv-00276, Dkt. No. 22.
`
`18.
`
`Venue is proper in the Western District of Texas pursuant to 28 U.S.C. §§ 1391
`
`and 1400(b) because Microsoft maintains regular and established places of business in this
`
`district and has committed acts of infringement within this district giving rise to this action.
`
`19. Microsoft has committed acts of infringement in this District and does business in
`
`this District, including making sales and/or providing service and support for customers and/or
`
`end-users in this District. Microsoft purposefully and voluntarily sold one or more infringing
`
`products with the expectation they would be purchased in this District. These infringing products
`
`have been and continue to be purchased in this District. Thus, Microsoft has committed acts of
`
`infringement within the United States, the State of Texas, and this District.
`
`20.
`
`Furthermore, Microsoft maintains corporate sales offices in this district, which, on
`
`information and belief, provide sales and support for the infringing products.
`
`
`
`5
`
`

`

`PATENTS-IN-SUIT
`
`21.
`
`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.
`
`22.
`
`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.
`
`23.
`
`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.
`
`24.
`
`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.
`
`25.
`
`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.
`
`26.
`
`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.
`
`6
`
`

`

`27.
`
`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.
`
`28.
`
`The technologies of the Patents-in-Suit were invented by John Giobbi and, for some
`
`of the patents, David Brown. The 730, 954, 905, and 989 Patents generally cover systems, devices,
`
`and methods for an integrated device that persistently 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 cover 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
`
`29.
`
`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 growing number of devices and services
`
`that people use on a regular basis and that require regular authentication, and the rise of
`
`biometric readers and high-speed networks, there was a need to implement improved
`
`7
`
`

`

`authentication architectures. The Username and password method is not an ideal authentication
`
`mechanisms because people tend to pick low security passwords that are easy to remember, they
`
`tend to reuse the same password across multiple devices and services, they tend not the change
`
`the password, and they sometimes write the password down on paper or type out the password in
`
`public where their device screen can be seen by those around them. This method is also time
`
`consuming and inconvenient from a user experience perspective, especially when a user needs to
`
`try several passwords or needs to type out a high security (long and complex) password on the
`
`small keyboard of a portable device. For all of these reasons and many more, a better architecture
`
`is one that relies less on the users’ memory.
`
`30.
`
`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. This method relies less on user memory
`
`because they need to use their username and password significantly less often.
`
`31. 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.
`
`8
`
`

`

`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.
`
`32. 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.
`
`33.
`
`Attempting to eliminate the use of passwords, Microsoft has developed a
`
`universal platform “password-less” architecture. The architecture is universal in that it works
`
`across platforms, such as iOS, Android, Windows, and Xbox. It is password-less in that
`
`passwords have been replaced with the use of authenticators approved or provided by Microsoft.
`
`Incorporating OpenID Connect, Microsoft’s architecture relies on the issuance of security
`
`tokens. The hub of Microsoft’s universal platform password-less architecture is Microsoft
`
`Identity Platform, which is the evolution of Azure Active Directory. The Microsoft Identity
`
`9
`
`

`

`Platform receives authentication requests from external systems, coordinates the action of
`
`authenticators, and issues security tokens.
`
`II.
`
`PROXENSE AND ITS INNOVATIVE TECHNOLOGIES
`
`34.
`
`Proxense was founded in 2001.4 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.
`
`35.
`
`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.
`
`36.
`
`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
`
`4 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.
`10
`
`

`

`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
`
`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.
`
`37.
`
`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 7. 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), Exhibit 8.
`
`38.
`
`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), Exhibit 9. 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…”
`
`11
`
`

`

`39.
`
`It would be years until products like Azure Active Directory and Microsoft Identity
`
`launched, and accordingly Proxense’s technology was years ahead of the industry.
`
`40.
`
`Today, Proxense holds at least 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.
`
`41.
`
`Proxense’s Interactions with Microsoft
`
`In 2010, Proxense engaged in discussions with Microsoft for the purpose of
`
`potentially integrating Proxense’s proprietary secure authentication technology utilizing biometric
`
`authentication into Microsoft products.
`
`42.
`
`On July 29, 2016, counsel for Proxense sent a letter to Microsoft, advising it as to
`
`Proxense’s “over 30 patents” included as an attachment, including the Patents-in-Suit, and further
`
`advising of “another 20+ US patent applications pending.” A copy of the letter and list of patents
`
`attached thereto is attached as Exhibit 10.
`
`43.
`
`Since at least that time, i.e. on or about July 29, 2016, Microsoft has had actual
`
`notice of the Patents-in-Suit and the scope of their claims as of at least their dates of issue.
`
`44. Microsoft has also had knowledge of the infringing nature of its activities, or at
`
`least a willful blindness regarding the infringing nature of its activities, since at least Proxense’s
`
`making Microsoft aware of the Patents-in-Suit as early as 2016, but at least as of the public filing
`
`of this Complaint. This follows where Proxense included with its July 29, 2016 correspondence a
`
`written comparison between Proxense’s claimed inventions and Microsoft’s products, including
`
`details of Microsoft’s infringing activity. Microsoft was also aware of Proxense’s proprietary
`
`12
`
`

`

`technology at least as early as 2010, when Proxense disclosed details of these technologies during
`
`discussions with Microsoft at that time.
`
`45.
`
`Despite Microsoft’s knowledge of the Patents-in-Suit, detailed knowledge of
`
`Proxense’s proprietary technology, and Microsoft’s knowledge that it infringed the Patents-in-
`
`Suit, or, at the very least a willful blindness to the fact that Microsoft infringes Proxense’s patents,
`
`Microsoft continued to infringe the claims of the Patents-in-Suit. Microsoft’s infringement has
`
`been and continues to be willful since at least 2016. Microsoft released the Azure Active Directory
`
`platform and its evolution into the Microsoft Identity platform with the intent they would be used
`
`to infringe the Patents-in-Suit.
`
`2.
`
`46.
`
`The Accused Products
`
`Through its own actions, and the actions of its customers and user, which Microsoft
`
`directs and controls, Microsoft 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 (literally or via the doctrine of equivalents) the Patents-in-
`
`Suit.
`
`47.
`
`Three primary components make up the infringing architecture. The first is the
`
`Microsoft Identity Platform (also known as Azure Active Directory), which coordinates the actions
`
`of the other components by authenticating users and issuing various bearer tokens. The second is
`
`an authenticator permitting user verification by Microsoft Identity Platform. During verification,
`
`Microsoft Identity Platform issues commands to the authenticator (called “requests”). Operation
`
`of the authenticator, accordingly, is controlled by Microsoft Identity Platform. 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
`
`13
`
`

`

`Microsoft and in a form dictated by Microsoft. The resource then listens for a reply at a callback
`
`URL the resource registered with Microsoft. As with the requests, the callbacks are in the form
`
`dictated by Microsoft. The resources are hosted by devices and/or servers separate from Microsoft
`
`Identity Platform. Accordingly, the resource and Microsoft Identity Platform are separate and
`
`distinct entities and the resource, which is not Microsoft Identity Platform, is the system being
`
`accessed.
`
`48. Microsoft utilizes the Microsoft Identity Platform to sign users into Windows
`
`10/11, Xbox consoles, Xbox Game Pass, Office 365, Microsoft Family, and other services and
`
`products offered by Microsoft. Microsoft sells access to Microsoft Identity Platform to developers,
`
`websites, and corporate clients through various subscriptions. Thus, for a fee, Microsoft Identity
`
`Platform 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, Microsoft directly and/or indirectly infringes (and literally or under the doctrine of
`
`equivalents) the Patents-in-Suit. Furthermore, by utilizing Microsoft Identity Platform for its own
`
`product and services, Microsoft directly and/or indirectly infringes (and literally or via the doctrine
`
`of equivalents) the Patents-in-Suit.
`
`49.
`
`As noted above, Microsoft’s
`
`infringing universal platform password-less
`
`architecture includes an authenticator. One authenticator distributed by Microsoft is Windows
`
`Hello, a native component of Windows 10 and 11. Microsoft has distributed variants of Windows
`
`Hello that have included functionality to verify a user during authentication of a Windows-
`
`compatible device. Since at least November 20, 2018, if not earlier, Windows Hello has enabled
`
`password-less sign-in to services and subscriptions offered by Microsoft. See Exhibit 11. Another
`
`authenticator distributed by Microsoft is the Microsoft Authenticator App. Microsoft has
`
`
`
`14
`
`

`

`distributed variants of the Microsoft Authenticator App that have included functionality to verify
`
`a user during authentication of an Android or iOS compatible mobile device. The current and
`
`previous versions of Windows Hello and Microsoft Authenticator, along with devices with them,
`
`alone and together, are non-limiting instances of authenticators integrated into the Accused
`
`Products.
`
`50.
`
`In addition to authenticators developed by Microsoft, authenticators developed by
`
`Microsoft’s partners may also be incorporated into the Accused Products. To receive the benefit
`
`of having their authenticator work on Windows, Microsoft Edge browser, and online Microsoft
`
`Accounts, the authenticator must meet the requirements set by Microsoft, including review by
`
`Microsoft’s engineering team. See Exhibit 12. By submitting the request for approval, an
`
`authenticator developer also enters into a contract with Microsoft in the form of its “Terms of
`
`Use,” which give Microsoft control over both the terms (which can be changed by Microsoft at
`
`any time with no prior notice) and gives Microsoft control over the means by which any such
`
`authenticator operates. By setting such requirements, Microsoft directs and controls the actions of
`
`its partners.
`
`51.
`
`The Microsoft Identity Platform, which directs and controls the actions of the
`
`authenticator, is also an element of Accused Product. Microsoft operates and maintains the
`
`Microsoft Identity platform, an evolution of the Azure Active Directory platform. When combined
`
`with authenticators, such as Windows Hello, Microsoft Authenticator App, and others developed
`
`and sold by Microsoft’s partners, consumers of Microsoft’s products and services receive the
`
`benefit of password-less biometric authentication across platforms. For instance, a user may log
`
`into and utilize Microsoft Office or their Xbox subscription on their Android phone. Third party
`
`developers can purchase identity and access management services from Microsoft to integrate their
`
`
`
`15
`
`

`

`applications with Microsoft 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 Microsoft Identity Platform must register their application or website with
`
`Microsoft, request authentication by sending a request to a URL provided by Microsoft and in a
`
`format dictated by Microsoft, and listen for a callback provided by Microsoft that contains a
`
`message generated by Microsoft in a format controlled by Microsoft. To facilitate such controlled
`
`interactions across platforms, Microsoft has developed Microsoft Authentication Library (MSAL).
`
`See Exhibit 13.
`
`52.
`
`The Accused Products also include a resource accessed following successful
`
`authentication of the authenticator by Microsoft Identity Platform. As noted above, the resource
`
`may be an application, website, and/or a subscription offered by Microsoft, a subscribing business,
`
`or a subscribing developer. When a user has been authenticated via an authenticator offered by
`
`Microsoft or one of its partners, various bearer tokens are returned by Microsoft Identity Platform
`
`to the callback URL registered with Microsoft Identity Platform. 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 Microsoft or a subscribing developer or
`
`business, the resource is on a system separate and distinct from Microsoft Identity Platform.
`
`Distribution of bearer tokens and other such access messages by Microsoft Identity Platform is
`
`thus necessary for Microsoft Identity Platform to inform the resource that the user has been
`
`successfully authenticated via an authenticator distributed by Microsoft or one of its partners. As
`
`the bearer tokens are generated and distributed by Microsoft Identity Platform, Microsoft controls
`
`their form and how they are distributed.
`
`
`
`16
`
`

`

`53.
`
`Through the operation of the foregoing as directed and controlled by Microsoft, the
`
`Accused Products practice the claims of the Patents-in-Suit to improve the user experience of
`
`Microsoft’s customers and those of subscribing developers, and to improve Microsoft’s position
`
`in the market with respect to Identity and Access Management, operating as an identity provider,
`
`along with providing access to other products, services, and subscriptions.
`
`3.
`
`Microsoft’s Direct Infringement of the Patents-in-Suit
`
`54. Microsoft directly infringes the Patents-in-Suit by creating and utilizing a universal
`
`platform password-less architecture incorporating authenticators, including Windows Hello on
`
`Windows 10 and 11, Microsoft Authenticator App on Android and iOS devices, and controlling
`
`the action of its partners to create authenticators that work on Windows, the Microsoft Edge
`
`browser, and online Microsoft accounts, incorporating the Microsoft Identity platform which
`
`controls the actions of authenticators and the dissemination of bear tokens and other such access
`
`messages, offering services, applications subscriptions and other such resources hosted by separate
`
`systems which are accessed via tokens provided by Microsoft Identity Platform, and offering
`
`businesses and developers identity and access management services which entail requesting user
`
`authentication and receiving tokens in a manner directed and controlled by Microsoft, including
`
`the use of Microsoft Authentication Library.
`
`55. Microsoft’s password-less architecture verifies a us