3:25-cv-01599
Authentixx LLC v. Pickleball OpCo LLC
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: Authentixx LLC (Delaware)
- Defendant: Pickleball OpCo LLC (Delaware)
- Plaintiff's Counsel: Rabicoff Law LLC; DNL Zito
- Case Identification: 3:25-cv-01599, N.D. Tex., 09/19/2025
- Venue Allegations: Venue is alleged to be proper in the Northern District of Texas because the Defendant maintains an established place of business in Dallas, Texas, and has committed alleged acts of patent infringement within the district.
- Core Dispute: Plaintiff alleges that Defendant's website, pickleball.com, infringes a patent related to a system and method for authenticating electronic content.
- Technical Context: The technology addresses the problem of fraudulent websites and identity theft by providing a method to verify the authenticity of web page content beyond easily counterfeited visual indicators or spoofed URLs.
- Key Procedural History: The asserted patent is part of a family of applications claiming priority back to a provisional application filed in 1999, indicating a long history of development and prosecution for the underlying technology.
Case Timeline
| Date | Event |
|---|---|
| 1999-09-09 | Earliest Priority Date ('863 Patent) |
| 2017-12-08 | '863 Patent Application Filing Date |
| 2019-07-16 | '863 Patent Issue Date |
| 2025-09-19 | First Amended Complaint Filing Date |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 10,355,863 - System and method for authenticating electronic content
- Patent Identification: U.S. Patent No. 10,355,863 ("'863 Patent"), issued July 16, 2019. Compl. ¶9
The Invention Explained
- Problem Addressed: The patent addresses the technological deficiency of conventional web authentication systems that rely on easily copied visual elements like logos or on URLs that can be spoofed, leaving users uncertain about the true owner of a web page and vulnerable to fraud. Compl. ¶¶10-11 '863 Patent, col. 1:25-40
- The Patented Solution: The invention proposes a distributed authentication system. A server generates an "authenticity key" and embeds it into the web page content. A client-side component, such as a browser plug-in, then uses this key to locate and retrieve a user-defined "authenticity stamp" from a locally stored "preferences file." This process allows the user to verify the webpage's authenticity based on a mechanism separate from the page's visible content. '863 Patent, abstract '863 Patent, col. 2:14-23 '863 Patent, col. 4:10-13
- Technical Importance: This hybrid client-server approach aims to provide a more robust, multi-factor authentication method that is difficult to counterfeit, enhancing security by separating the authentication logic from the web content itself. (Compl. ¶¶14; Compl. ¶16)
Key Claims at a Glance
- The complaint asserts method claim 9 as an exemplary independent claim and also references dependent claim 11. Compl. ¶23 Compl. Ex. 2, p. 2
- The essential elements of independent claim 9 include:
- 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 a request for a web page from a client computer;
- creating formatted data corresponding to the web page;
- receiving a request for the authenticity key;
- sending the formatted data to the client computer;
- providing 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 authenticity stamp to be displayed with a representation of the formatted data.
- The complaint states that Defendant infringed "one or more claims," suggesting Plaintiff may assert additional claims, including dependent claims like claim 11, which adds a requirement for obscuring the file location. Compl. ¶23 Compl. ¶26
III. The Accused Instrumentality
Product Identification
- The accused instrumentality is the website located at pickleball.com and its associated backend systems. Compl. Ex. 2, p. 2
Functionality and Market Context
- The accused product is a website that provides information and user-specific features. According to the complaint, when a user has a profile, an image associated with that user is stored on the Defendant's server. When the user visits the site, the system allegedly generates a key related to the URL of that user image, which is then used to retrieve and display the image in the website's header, thereby authenticating the page to the user. (Compl. Ex. 2, pp. 2-4) The complaint does not provide specific details on the product's market positioning.
IV. Analysis of Infringement Allegations
The infringement allegations are detailed in Exhibit 2 of the complaint, which is incorporated by reference. Compl. ¶28 Compl. ¶29 The complaint alleges that the standard operation of the pickleball.com website for registered users practices every step of the method claimed in claim 9. The complaint provides a screenshot of the accused website's header, annotated to identify a user's profile picture as the alleged "authenticity stamp". Compl. Ex. 2, p. 3 Another screenshot purports to show the "authenticity key", which is identified as the direct URL path to the user's profile image file hosted on Defendant's content delivery network (CDN). Compl. Ex. 2, p. 4
'863 Patent Infringement Allegations
| Claim Element (from Independent Claim 9) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| storing at least one authenticity stamp in a preferences file located in a file location; | Storing a user image (the alleged "authenticity stamp") in a user profile file (the alleged "preferences file") on the server of the accused product. | ¶29 | col. 11:15-20 |
| creating, by one or more designated servers, an authenticity key with information to locate the preferences file; | When a profile image is provided, the accused product's servers create a URL for the image, which is alleged to be an "authenticity key" related to the URL. | ¶29 | col. 2:17-18 |
| receiving, at the one or more designated servers, a request from a client computer for the at least one web page; | The accused product's servers receive a request for a web page from a user's computer. | ¶29 | col. 2:14-15 |
| creating, by the one or more designated servers, formatted data corresponding to the requested at least one web page; | The accused product's servers create structured web page data corresponding to the requested web page. | ¶29 | col. 2:59-60 |
| providing, by the one or more designated servers, the authenticity key for processing to determine the file location of the preferences file; | The accused product provides the image URL (alleged "authenticity key") within the HTML source code sent to the client computer. | ¶29 | col. 2:18-19 |
| processing the authenticity key to determine the file location of the preferences file; | The client's browser processes the image URL to locate the image file on the defendant's server. | ¶29 | col. 12:4-10 |
| retrieving the at least one authenticity stamp from the preferences file; and | The client's browser retrieves the user image (alleged "authenticity stamp") from the server location identified by the URL. | ¶29 | col. 12:4-10 |
| 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 user image is displayed along with the rest of the web page content on the user's computer screen. | ¶29 | col. 4:11-13 |
- Identified Points of Contention:
- Architectural Mismatch: A significant question arises from the location of the "preferences file." The patent specification describes a distributed architecture where user preferences are "stored locally on the client system" and verified by a client-side plug-in. Compl. ¶16 '863 Patent, col. 2:20-22 The complaint, however, alleges infringement via a "user profile file" stored on the Defendant's remote server. Compl. Ex. 2, p. 2 This raises the question of whether a server-side file can satisfy the "preferences file" limitation as contemplated by the patent.
- Scope Questions: The case may turn on whether a standard URL to an image file constitutes an "authenticity key" under the patent's claims. The patent describes the key as a special component generated by an "authentication server" for a security purpose, whereas the complaint identifies it as a simple hyperlink to an image. '863 Patent, abstract Compl. Ex. 2, p. 4
- Technical Questions: What evidence does the complaint provide that the standard browser function of rendering a webpage by fetching an image from a URL performs the specific, multi-step authentication process recited in claim 9? The infringement theory appears to equate a conventional web-browsing step with the patent's distinct steps of "processing" a key to "determine the file location" and "locating the preferences file."
V. Key Claim Terms for Construction
The Term: "preferences file"
- Context and Importance: The definition of this term is critical because of the architectural mismatch between the patent's apparent client-side storage model and the accused system's server-side storage. Practitioners may focus on this term because its location (client vs. server) is central to the patent's described security architecture.
- Intrinsic Evidence for a Broader Interpretation: The language of claim 9 itself requires "storing at least one authenticity stamp in a preferences file located in a file location," without explicitly restricting that location to the client computer. '863 Patent, col. 15:28-30 Plaintiff may argue this language is broad enough to cover any file location, including a remote server.
- Intrinsic Evidence for a Narrower Interpretation: The specification repeatedly emphasizes a client-side architecture, stating that authenticity is "verified at the user's computer because the user computer includes logic (e.g., software) to verify the authenticity." '863 Patent, col. 2:20-22 It also describes the user defining stamps "after it is downloaded to the user's computer." '863 Patent, col. 2:23-25 This context suggests the "preferences file" is intended to be local to the client.
The Term: "authenticity key"
- Context and Importance: This term's construction is central to whether a standard image URL can be considered the special security element described in the patent. The dispute may hinge on whether the "key" must be more than just a location pointer.
- Intrinsic Evidence for a Broader Interpretation: Claim 9 requires an "authenticity key with information to locate the preferences file." '863 Patent, col. 15:31-33 Plaintiff may argue that a URL perfectly fits this description, as it is a piece of information used to locate a file.
- Intrinsic Evidence for a Narrower Interpretation: The specification describes the key as being generated by an "authentication server," inserted into web content, and processed by a client-side "plug-in" to "verify the authenticity." '863 Patent, abstract '863 Patent, col. 2:17-22 The patent also describes the key as being used for security functions like signature verification, suggesting it is a cryptographic or specialized element, not just a standard hyperlink. '863 Patent, col. 12:4-10
VI. Analyst's Conclusion: Key Questions for the Case
The resolution of this dispute will likely depend on the court's interpretation of several key technical and legal issues:
- A core issue will be one of architectural scope: Can the claimed system, which the patent specification describes as involving a client-side "preferences file" verified by a user's computer, be construed to cover the accused system's server-side storage of a "user profile file"?
- A central claim construction question will be one of definitional scope: Can the term "authenticity key", described in the patent as a specialized element for a security process, be interpreted to encompass a standard URL used by a web browser to render an image?
- A key evidentiary question will be one of functional equivalence: Does the conventional browser process of fetching and displaying an image via a hyperlink perform the specific, multi-step authentication method recited in Claim 9, or is there a fundamental mismatch in technical operation between the accused product and the patented invention?