2:25-cv-00648
Authentixx LLC v. Uvation LLC
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: Authentixx LLC (Delaware)
- Defendant: Uvation, LLC (New York)
- Plaintiff’s Counsel: Rabicoff Law LLC
- Case Identification: 2:25-cv-00648, E.D. Tex., 06/19/2025
- Venue Allegations: Venue is alleged to be proper based on the Defendant having an established place of business in the district, committing acts of infringement in the district, and causing the Plaintiff harm in the district.
- Core Dispute: Plaintiff alleges that Defendant’s unidentified products infringe a patent related to methods for authenticating electronic content, such as web pages, to prevent spoofing and phishing.
- Technical Context: The technology addresses online security by providing a system to verify that electronic content originates from its purported source, a critical function in combating online fraud.
- Key Procedural History: The asserted patent is subject to a terminal disclaimer. It is a continuation of a 2005 application, which is a continuation-in-part of a 2000 application that claims priority to a 1999 provisional application, indicating a long and complex prosecution history that may be relevant to claim scope.
Case Timeline
| Date | Event |
|---|---|
| 1999-09-09 | ’863 Patent Priority Date (Provisional App. 60/153,004) |
| 2017-12-08 | ’863 Patent Application Filing Date |
| 2019-07-16 | U.S. Patent No. 10,355,863 Issued |
| 2025-06-19 | Complaint Filed |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 10,355,863 - “System and method for authenticating electronic content”
The Invention Explained
- Problem Addressed: The patent identifies the risk of online fraud where malicious actors use copied corporate logos or deceptively similar URLs (e.g., "www.blgbank.com" instead of "www.bigbank.com") to create spoofed websites or phishing emails for identity theft (’863 Patent, col. 1:24-61).
- The Patented Solution: The invention proposes a system where a server inserts a unique "authenticity key" into electronic content (like a web page) before sending it to a user. A corresponding software component on the user’s computer, such as a browser plug-in, verifies this key and displays a pre-configured "authenticity stamp" to assure the user the content is genuine (’863 Patent, col. 2:13-30; Fig. 4). This stamp can be a custom visual icon, text, or even a fractal design, defined by the user to prevent easy counterfeiting (’863 Patent, col. 4:12-24, 4:45-54).
- Technical Importance: The technology provides a client-side, user-configurable verification method, aiming to create a more reliable trust indicator than server-side signals (like HTTPS) or easily forged visual elements.
Key Claims at a Glance
- The complaint asserts "one or more claims" without specifying them, instead referencing an external exhibit not provided with the complaint (Compl. ¶¶11, 13). Independent claim 9 is representative of the end-to-end method.
- Independent Claim 9 (Method):
- storing at least one authenticity stamp in a preferences file located in a file location;
- creating, by one or more designated servers, an authenticity key with information to locate the preferences file;
- receiving, at the one or more designated servers, a request from a client computer for the at least one web page;
- creating, by the one or more designated servers, formatted data corresponding to the requested at least one web page; and
- receiving, at the one or more designated servers, a request for the authenticity key used to locate the preferences file;
- sending, by the one or more designated servers, the formatted data to the client computer;
- providing, by the one or more designated servers, the authenticity key for processing to determine the file location of the preferences file;
- processing the authenticity key to determine the file location of the preferences file;
- locating the preferences file in the file location;
- retrieving the at least one authenticity stamp from the preferences file; and
- enabling the at least one authenticity stamp to be displayed with a representation of the formatted data on a display of the client computer.
- The complaint does not explicitly reserve the right to assert dependent claims.
III. The Accused Instrumentality
Product Identification
The complaint does not name any specific accused products, methods, or services. It refers only to "Exemplary Defendant Products" that are identified in "charts incorporated into this Count" via Exhibit 2 (Compl. ¶11, 13). Exhibit 2 was not filed with the complaint.
Functionality and Market Context
The complaint does not provide sufficient detail for analysis of the accused instrumentality's functionality or market context.
IV. Analysis of Infringement Allegations
The complaint alleges that infringement is detailed in claim charts in Exhibit 2, which is not publicly available (Compl. ¶13). The complaint itself contains no specific factual allegations mapping any accused product feature to any claim element. The infringement theory is stated in conclusory terms: "the Exemplary Defendant Products practice the technology claimed by the '863 Patent" and "satisfy all elements of the Exemplary '863 Patent Claims" (Compl. ¶13). No probative visual evidence provided in complaint.
Identified Points of Contention
Due to the lack of factual detail in the complaint, any analysis is speculative. However, based on the language of claim 9, disputes may arise over several points:
- Scope Questions: Do the accused products utilize a "preferences file" and an "authenticity key" as those terms are understood in the context of the patent? The patent describes a specific architecture involving a user-configurable stamp stored locally and a key from the server used to locate it (’863 Patent, col. 12:47-53, col. 14:52-60). A central question will be whether the accused system's method for storing and retrieving user settings or authentication data falls within this claimed scope.
- Technical Questions: What specific functionality in the accused products constitutes "processing the authenticity key to determine the file location"? The patent suggests a process involving decryption and use of a shared secret (’863 Patent, col. 6:35-42). Evidence will be required to show that the accused products perform this specific type of processing, or a functional equivalent, rather than a more generic data lookup.
V. Key Claim Terms for Construction
The Term: "authenticity stamp"
Context and Importance: This term defines the ultimate output of the claimed method and is the user-facing security indicator. Its construction is critical because it will determine what kind of indicator qualifies, impacting the breadth of infringement. Practitioners may focus on this term because the patent provides multiple, distinct examples.
Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The specification describes the stamp broadly as a mechanism by which a user can "specify the appearance," including "graphics only, text only or a combination thereof" as well as color and other attributes, suggesting it could be any user-configured indicator (’863 Patent, col. 4:12-22).
- Evidence for a Narrower Interpretation: The specification provides specific visual examples, such as a diamond-shaped "SEAL OF APPROVAL" (Fig. 2) or text embedded in other images (Fig. 3). A defendant could argue these embodiments limit the term to a distinct, overlaid visual element, rather than any change in the displayed content.
The Term: "processing the authenticity key to determine the file location"
Context and Importance: This functional step is the core of the client-side verification mechanism. How this "processing" is defined will be central to whether an accused system that uses a different method to link a server response to local user data infringes.
Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The claim language is functional and does not recite a specific algorithm. Plaintiff may argue that any method using information from the server ("authenticity key") to find local data ("preferences file") meets this limitation.
- Evidence for a Narrower Interpretation: The detailed description explains this process in a specific context: a plug-in receiving an encrypted key, decrypting it, and using the result to find a preferences file whose location is "not readily known" (’863 Patent, col. 6:35-42). A defendant may argue that "processing" is limited to this decryption-based method for locating an intentionally obscured file.
VI. Other Allegations
- Indirect Infringement: The complaint does not allege indirect infringement.
- Willful Infringement: The complaint does not explicitly allege willful infringement. It does, however, request in the prayer for relief that the case be declared "exceptional" under 35 U.S.C. § 285 (Compl. Prayer ¶E.i). The complaint provides no factual basis to support a finding of egregiousness or willfulness, such as allegations of pre-suit knowledge of the patent.
VII. Analyst’s Conclusion: Key Questions for the Case
- A primary threshold issue is one of pleading sufficiency: the complaint's complete reliance on a non-proffered exhibit to provide the factual basis for infringement raises the question of whether it meets the pleading standards articulated by the Supreme Court in Iqbal and Twombly.
- The central technical dispute will likely be one of functional mapping: assuming a specific product is identified, the key question will be whether its architecture for verifying content and displaying a trust signal performs the specific, multi-step process recited in the claims, particularly concerning the generation and "processing" of an "authenticity key" to locate a "preferences file."
- A core legal question will be one of claim scope: can the term "authenticity stamp", described in the patent as a distinct, user-configured visual icon, be construed broadly enough to read on more generalized trust indicators that may be present in modern web applications?