AttestWave LLC v. Sophos Ltd

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: AttestWave LLC (Delaware)
  • Defendant: Sophos Ltd. (United Kingdom)
  • Plaintiff’s Counsel: Rabicoff Law LLC
• Case Identification: 2:24-cv-00930, E.D. Tex., 11/13/2024
• Venue Allegations: Plaintiff alleges venue is proper in the Eastern District of Texas because Defendant has an established place of business in the District and has committed acts of infringement there.
• Core Dispute: Plaintiff alleges that Defendant infringes a patent related to secure logic interlocking for ensuring the trusted operation of software.
• Technical Context: The technology addresses cybersecurity vulnerabilities in computer networks by creating inseparable software modules whose proper, untampered execution can be remotely verified, a key concern in preventing network abuse and denial-of-service attacks.
• Key Procedural History: No prior litigation, licensing history, or other significant procedural events are mentioned in the complaint.

Case Timeline

II. Technology and Patent(s)-in-Suit Analysis

U.S. Patent No. 7,895,643 - Secure logic interlocking

• Patent Identification: U.S. Patent No. 7,895,643, Secure logic interlocking, issued February 22, 2011 (’643 Patent). (Compl. ¶9).

The Invention Explained

• Problem Addressed: The patent's background section notes that unlike traditional, centrally controlled telephone networks, users of computer networks like the Internet typically have access to the software on their own devices. This allows a malicious or misbehaving user to modify software to overuse network resources or launch attacks, as the network lacks a mechanism to trust that a user's software is operating according to defined rules. (’643 Patent, col. 2:30-38).
• The Patented Solution: The invention proposes a system to create "trusted flows" of communication by transforming separate software modules—for example, a standard data transmission program and a cryptographic signal generator—into a single, "interlocked" and inseparable program. (’643 Patent, col. 2:7-12). This integrated program generates unpredictable security signals (e.g., a "Security Tag Vector") that are embedded in data packets. A corresponding "Trusted Tag Checker" (TTC) at a network interface, such as a firewall, independently generates the expected signal and compares it to the one received. A match validates that the original, untampered program was executed correctly. (’643 Patent, Abstract; Fig. 1).
• Technical Importance: This method sought to provide a proactive integrity function to guarantee software behavior, contrasting with then-current "reactive" security methods like firewalls that primarily detect and react to misbehavior after it occurs. (’643 Patent, col. 2:47-54).

Key Claims at a Glance

• The complaint does not specify which claims of the ’643 Patent are asserted, instead referring to "Exemplary ’643 Patent Claims" in an attached exhibit that was not provided with the filed complaint. (Compl. ¶¶11, 16). For illustrative purposes, an analysis of the first independent claim is presented below.
• Independent Claim 1:
  • An integrated combination of a computer software program comprised of a software application logic module and an operation assurance logic module.
  • The modules have sub-procedures that execute to provide combined computing functions and concurrently generate unique security tags.
  • Storage for the integrated program.
  • A controller for executing the integrated program.
  • During execution, the unique security tags are selectively generated only if the program is executed and has not been tampered with.
  • An associated operational checking logic for validating, responsive to the security tags, that the program was not tampered with.
• The complaint does not explicitly reserve the right to assert other claims, but its reference to "exemplary" claims suggests this possibility. (Compl. ¶11).

III. The Accused Instrumentality

Product Identification

The complaint does not identify any specific accused products by name. (Compl. ¶11).

Functionality and Market Context

The complaint alleges infringement by "Exemplary Defendant Products" that are identified in a separate claims chart exhibit, which was not provided. (Compl. ¶¶11, 16). The complaint does not provide sufficient detail for analysis of the functionality or market context of any accused instrumentality.

IV. Analysis of Infringement Allegations

The complaint alleges that the "Exemplary Defendant Products" practice the technology claimed by the "Exemplary ’643 Patent Claims" and that these products satisfy all elements of those claims. (Compl. ¶16). It further incorporates by reference the allegations contained within "the claim charts of Exhibit 2." (Compl. ¶17). As Exhibit 2 was not provided, a claim chart summary cannot be constructed.

• Identified Points of Contention: Based on the patent's claims and the general nature of the allegations, the infringement analysis may raise several technical and legal questions.
  • Scope Questions: A central question may be whether the architecture of an accused product constitutes an "integrated combination" of software modules that are "interlocked" as described in the ’643 Patent. The analysis would need to determine if the accused software creates an "inseparable" program (’643 Patent, col. 3:24-25), or if its components are merely called in sequence in a way that could be modified by an end-user, potentially falling outside the claim scope.
  • Technical Questions: An evidentiary question will likely concern the function of any security mechanism in the accused products. The court may need to determine if the accused product's signaling and verification system performs the specific function of "validating that the integrated software computer program as executed was not tampered with" (Claim 1), or if it performs a more general security task, such as authenticating a user or ensuring data integrity, that is technically distinct from the claimed invention. Figure 1 of the ’643 Patent depicts a system where a Trusted Flow Generator (TFG) and a Trusted Tag Checker (TTC) work in concert to validate the flow. (Compl. ¶9; ’643 Patent, Fig. 1). The complaint's visual evidence shows this distinct architectural relationship. (Compl. ¶9; ’643 Patent, Fig. 1). A potential dispute is whether the accused product mirrors this architecture or achieves a similar result through a different, non-infringing technical approach.

V. Key Claim Terms for Construction

• The Term: "integrated combination" / "interlocking"

• Context and Importance: These terms appear in Claim 1 and are central to the patent's core concept of creating an inseparable, trusted program. The outcome of the case may depend on whether the accused product's software architecture meets this definitional threshold, which requires more than two modules simply co-existing or communicating. Practitioners may focus on this term because it defines the structural prerequisite for the entire patented system.

• Intrinsic Evidence for Interpretation:

  • Evidence for a Broader Interpretation: The specification describes multiple ways to achieve the combination, including through "obfuscation," "encryption," and the creation of a "hidden program," suggesting the term is not limited to a single implementation. (’643 Patent, col. 6:45-53; Figs. 12A-12D). This may support a construction covering any technique that makes it functionally difficult for a typical user to separate the modules.
  • Evidence for a Narrower Interpretation: The patent repeatedly uses the word "inseparable" and states the goal is to create a "unique functionality" from combined modules. (’643 Patent, Abstract; col. 3:24-25). A defendant could argue this language requires a specific technical result, such as a single monolithic executable, where the modules cannot be individually replaced or bypassed, as opposed to a system with separate but communicating processes.

• The Term: "operational checking logic, for validating that the integrated software computer program as executed was not tampered with"

• Context and Importance: This limitation from Claim 1 defines the purpose and function of the verification component (the "TTC" in the patent's embodiment). The infringement analysis will turn on whether the accused product's checker performs this specific validation of program integrity, or a different kind of security check.

• Intrinsic Evidence for Interpretation:

  • Evidence for a Broader Interpretation: A plaintiff might argue that any check of a signal that can only be generated by the "integrated program" inherently validates that the program was not tampered with, as a modified program would fail to generate the correct signal.
  • Evidence for a Narrower Interpretation: The patent distinguishes its invention from general security tools. Language stating the checker assures "compliance" and "good behavior of the continuous flow" could support a narrower construction requiring the check to validate the program's operational state and adherence to rules, not merely authenticating a static piece of data. (’643 Patent, col. 2:8-12, col. 3:27-33).

VI. Other Allegations

• Indirect Infringement: The complaint alleges induced infringement, stating that Defendant provides "product literature and website materials" that instruct end users to use the accused products in a manner that infringes the ’643 Patent. (Compl. ¶14).
• Willful Infringement: The complaint bases its willfulness allegation on post-suit knowledge. It alleges that the "service of this Complaint" constitutes actual knowledge and that Defendant's continued conduct thereafter is knowing and intentional. (Compl. ¶¶13, 15). No allegations of pre-suit knowledge are made.

VII. Analyst’s Conclusion: Key Questions for the Case

• A core issue will be one of technical scope: Can the patent's requirement for an "integrated combination" of "interlocked" software modules be met by the accused product's architecture, or are the relevant functional components sufficiently distinct and separable to fall outside the claim language?
• A key evidentiary question will be one of functional purpose: Does the accused product's security verification system perform the specific, claimed function of validating that the program's execution was not tampered with, or does it perform a more conventional security check (e.g., user or data authentication) that is technically distinct from the patented invention?