DCT
2:19-cv-05836
TransactionSecure LLC v. Deviantart Inc
Key Events
Complaint
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: Transaction Secure, LLC (a foreign limited liability company)
- Defendant: DeviantArt, Inc. (a Delaware corporation with headquarters in California)
- Plaintiff’s Counsel: Watson LLP
- Case Identification: 2:19-cv-05836, C.D. Cal., 07/08/2019
- Venue Allegations: Venue is alleged to be proper as Defendant has a regular and established place of business in the Central District of California and resides in the district.
- Core Dispute: Plaintiff alleges that Defendant’s online user authentication system infringes a patent related to methods for authenticating a person's identity using a trusted third-party entity.
- Technical Context: The technology resides in the field of digital identity verification, a foundational security layer for e-commerce, API access, and online services that seeks to confirm a user's identity without unnecessarily exposing sensitive personal data.
- Key Procedural History: An inter partes review (IPR) of the patent-in-suit was initiated after this complaint was filed (IPR2020-00321). The IPR resulted in a certificate issued on May 18, 2021, cancelling claims 1, 4-8, 10, 15, 17, and 20-23. The complaint asserts at least Claim 1, which is now cancelled. This event fundamentally impacts the viability of the infringement allegations as pleaded.
Case Timeline
| Date | Event |
|---|---|
| 2006-05-16 | ’921 Patent Priority Date |
| 2014-05-27 | ’921 Patent Issue Date |
| 2019-07-08 | Complaint Filing Date |
| 2019-12-31 | IPR Petition (IPR2020-00321) Filed against '921 Patent |
| 2021-05-18 | IPR Certificate Issued, Cancelling Asserted Claim 1 |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 8,738,921 - System and Method for Authenticating a Person's Identity Using a Trusted Entity
- Issued: May 27, 2014
The Invention Explained
- Problem Addressed: The patent background describes the risk of identity theft stemming from the repeated use of permanent, static identifiers like a person's Social Security Number (SSN) and birthdate to authenticate transactions online. Once this information is compromised, it can be used fraudulently for the lifetime of the victim ('921 Patent, col. 2:1-29).
- The Patented Solution: The invention proposes a three-party system to solve this problem. A "person" seeking to transact with a "transactional entity" (e.g., an online store) first requests a temporary, "unique code" from a separate "trusted entity" (e.g., the Social Security Administration) that securely stores the person's core identity information. The person provides this unique code to the transactional entity, which in turn contacts the trusted entity to confirm the code's validity. This allows authentication without the transactional entity ever receiving or storing the person's permanent, sensitive data ('921 Patent, col. 3:23-56; Fig. 1).
- Technical Importance: The described method aims to enhance security by replacing the exchange of permanent personal identifiers with temporary, verifiable tokens for individual transactions, thereby limiting the value of any single intercepted credential ('921 Patent, col. 3:57-64).
Key Claims at a Glance
- The complaint asserts independent method Claim 1 and independent system Claim 24 (Compl. ¶¶17-18, 20).
- Independent Claim 1, a method claim, includes the essential elements of:
- A trusted entity receiving and confidentially storing a person's personal identity information.
- Storing a user identifier and password that are associated with, but do not contain, the personal identity information.
- Receiving a request from the person for a unique code, where the request includes the user identifier and password.
- Providing the unique code (comprising a "person identifier" and a "key") to the person for transmission to a transactional entity.
- The trusted entity confirming the unique code for the transactional entity to verify the person's identity.
- Independent Claim 24, a system claim, recites hardware and software modules to carry out a similar process, including a "client module," a "transactional processing module," and a "trusted entity server" with a database.
III. The Accused Instrumentality
Product Identification
- Defendant DeviantArt's website and its associated user authentication system and method (Compl. ¶¶20-21).
Functionality and Market Context
- The complaint describes an authentication flow where DeviantArt acts as a "trusted entity" to authenticate its users ("account holders") who wish to access services from a "resource server (i.e., a transactional entity)" (Compl. ¶22). The process, as depicted in a diagram within the complaint, involves a client application requesting an "Authorization Code" from DeviantArt, the user authorizing this request, and the client then exchanging that code for an "Access Token" to access protected "Endpoints" (Compl. p. 6). This workflow is characteristic of an OAuth 2.0 authorization framework, a standard protocol for delegated access to APIs. The complaint alleges this system uses non-personal information (the authorization code/token) to secure personal data (Compl. ¶22). The complaint's diagram of the accused workflow shows a client requesting an authorization code from DeviantArt. (Compl. p. 6).
IV. Analysis of Infringement Allegations
'921 Patent Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| A method for authenticating a person's identity to a transactional entity using a trusted entity... | Defendant's website, the "Accused Product," operates as a "trusted entity" that authenticates its account holders when they seek to access a service from a "resource server (i.e., a transactional entity)." | ¶22 | col. 4:20-23 |
| receiving personal identity information at a trusted entity computer system... | The accused system "receives personal information from users...such as their name, age, birthdate, email address, phone number etc. when users create an account," which is then confidentially stored. | ¶23 | col. 11:60-62 |
| in the secure repository, storing a user identifier and a password that are associated with, but do not contain, the personal identity information | Defendant provides users with "authorization login details (i.e., user identifier and password)" that are associated with the user but "do not contain the personal details." | ¶24 | col. 7:22-29 |
| at the trusted entity computer system, receiving a request from the person for a unique code, the request including the user identifier and the password... | "The user then requests Defendant for resource access to a trusted entity computer system. The request includes the user identifier and the password." The user is redirected to DeviantArt to "Obtain User Authorization." | ¶25, p. 6 | col. 7:30-34 |
| providing the unique code to the person, the unique code comprising a person identifier and a key... | "Defendant provides a unique authorization code to the user...which includes a user identified and access key." This authorization code is then used to obtain an access token. | ¶26 | col. 8:36-39 |
| the trusted entity computer system confirming the unique code to the transactional entity to verify the person's identity. | "In the Accused Product, the user identity is verified by the resource server by using the authorization code." The provided diagram shows the client submitting a "Request Access Token" to DeviantArt, which then issues a token, a process which functionally serves as confirmation of the initial authorization code. | ¶28, p. 6 | col. 8:36-39 |
Identified Points of Contention
- Scope Questions: The complaint maps an OAuth-style API authorization flow onto the patent's identity verification framework. A court may need to decide if the roles are analogous. For instance, is an online art community like DeviantArt, which also serves as the resource server, the type of "trusted entity" contemplated by the patent, which provides examples like the Social Security Administration ('921 Patent, col. 15:33-35)?
- Technical Questions: A key technical question is whether the accused "authorization code" meets the claim limitation of "comprising a person identifier and a key." The complaint makes this conclusory allegation (Compl. ¶26) but provides no evidence that a standard OAuth authorization code is structured as a concatenation of two distinct components as described in the patent, versus being an opaque, single-use credential.
V. Key Claim Terms for Construction
The Term: "trusted entity"
- Context and Importance: The definition of this term is foundational, as it defines the central actor in the claimed method. The infringement theory depends on casting DeviantArt in this role. Practitioners may focus on this term to determine if the patent's scope is limited to specific types of institutions (e.g., governmental, financial) or broadly covers any online service with a user database.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The specification states the transactional entity can be a "bank, credit card company, mortgage company, financial institution, business, insurance company, healthcare provider, government entity, service provider, or other entity desiring the person's identity to be authentic" ('921 Patent, col. 6:3-9). This broad list could imply the "trusted entity" is likewise not limited to a specific type.
- Evidence for a Narrower Interpretation: The patent’s examples and problem statement focus on entities that are custodians of high-stakes, official identity information like SSNs ('921 Patent, col. 15:33-38). An argument could be made that the term implies an entity whose primary function is identity management, not a general service provider that happens to have user accounts.
The Term: "unique code comprising a person identifier and a key"
- Context and Importance: This term dictates the specific structure of the credential used for authentication. The infringement case hinges on showing that the accused "authorization code" has this two-part structure. The complaint's mapping of this term to the accused product appears to be a point of potential dispute.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The specification refers to the unique code as an "alpha-numeric string" ('921 Patent, col. 4:8-9), which could suggest flexibility in its format.
- Evidence for a Narrower Interpretation: The claim language itself explicitly requires the code to "comprise" both a "person identifier" and a "key." The specification consistently discusses these as distinct elements that are combined ('921 Patent, col. 8:3-21, Fig. 2), suggesting the code is not an opaque string but a structured data element with two specified components. This could support a narrower construction requiring proof of both distinct parts in the accused code.
VI. Other Allegations
- Indirect Infringement: While not pleaded as a separate count, the complaint's reference to Defendant's developer documentation (Compl. ¶20) could form the basis for an induced infringement theory. The allegation is that DeviantArt provides instructions for third-party client applications to implement the allegedly infringing authentication method.
- Willful Infringement: The complaint makes a conclusory allegation of willful infringement "upon information and belief," asserting that Defendant knew of the '921 Patent (Compl. ¶29). It does not, however, plead specific facts to support pre-suit knowledge of the patent or its alleged infringement.
VII. Analyst’s Conclusion: Key Questions for the Case
- A threshold issue is one of case viability: given that the lead asserted claim (Claim 1) was cancelled in an inter partes review proceeding subsequent to the filing of the complaint, can the Plaintiff's action proceed as currently pleaded, or is it moot with respect to that claim?
- A second core issue will be one of definitional scope: can the patent’s framework, described in the context of protecting core identity data (like SSNs) from merchants, be construed to cover a standard OAuth 2.0 flow used for delegated API access? This will turn on the court's interpretation of the roles of a "trusted entity" and "transactional entity" as applied to the DeviantArt ecosystem.
- A final key evidentiary question will be one of technical mapping: does the accused "authorization code" in DeviantArt's OAuth flow function as the claimed "unique code comprising a person identifier and a key," or is there a fundamental mismatch between the opaque, single-use nature of an OAuth code and the specific two-part structure required by the patent claim?