AttestWave LLC v. Bitdefender LLC

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: AttestWave LLC (Delaware)
  • Defendant: Bitdefender LLC (Delaware)
  • Plaintiff’s Counsel: Garibian Law Offices, P.C.; Rabicoff Law LLC
• Case Identification: 1:25-cv-00249, D. Del., 03/05/2025
• Venue Allegations: Venue is asserted on the basis that Defendant is incorporated in Delaware and has an established place of business within the district.
• Core Dispute: Plaintiff alleges that Defendant’s security software products infringe a patent related to methods for ensuring trusted software operation through secure logic interlocking.
• Technical Context: The technology addresses the challenge of verifying that software on a computer network is operating correctly and has not been maliciously modified, a foundational concern in cybersecurity.
• Key Procedural History: The complaint does not mention any prior litigation, inter partes review proceedings, or licensing history related to the patent-in-suit.

I. Case Timeline

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

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

Issued February 22, 2011

I. The Invention Explained

• Problem Addressed: The patent identifies a fundamental problem in computer networks where it is difficult to enforce "trusted operation," meaning ensuring that software on end-user stations complies with defined rules (e.g., for data transmission) and has not been altered. This vulnerability allows users to "control the network rather than the network controlling the users," leading to issues like denial-of-service attacks (Compl. ¶9; ’643 Patent, col. 1:19-23; col. 2:36-39).
• The Patented Solution: The invention proposes a system where separate software functions are transformed into a single, "interlocked" program. One part of this program performs an operational task (e.g., sending a data packet), while another, inseparable part generates an unpredictable "security signal." A remote checker, such as a firewall, which knows how the signal should be generated, can then validate it. A correct signal provides assurance that the operational task was performed by the authentic, untampered software. This is depicted in the patent's figures, such as FIG. 1, which shows a client-side "Trusted Flow Generator" (TFG) creating data packets with security tags and a network-side "Trusted Tag Checker" (TTC) verifying them (’643 Patent, Abstract; col. 2:7-20).
• Technical Importance: This method provides a mechanism to proactively validate the integrity of software executing on a remote machine, contrasting with traditional "reactive" security measures like firewalls that typically only respond after detecting misbehavior (’643 Patent, col. 2:48-54).

II. Key Claims at a Glance

• The complaint asserts "one or more claims" without specifying them (Compl. ¶11). The first independent claim, Claim 1, is representative of the system's core architecture.
• Independent Claim 1: A system for assuring proper software execution, comprising the following essential elements:
  • An integrated combination of computer software program comprised of a software application logic module and an operation assurance logic module;
  • Wherein these modules execute as a combined plurality of sub-procedures to provide combined computing functions and an integrated concurrent generation of unique security tags;
  • Storage for the integrated computer software program;
  • A controller for executing the integrated combination;
  • Wherein the unique security tags are selectively generated only when the integrated software program is executed and has not been tampered with;
  • An associated operational checking logic for validating that the program was not tampered with, responsive to the unique security tags.
• The complaint’s reference to "one or more claims" suggests the right to assert additional independent and dependent claims is reserved (Compl. ¶11).

III. The Accused Instrumentality

I. Product Identification

The complaint does not name specific accused products in its main body. It refers to them as the "Exemplary Defendant Products" identified in "charts incorporated into this Count" (Compl. ¶11). These charts, designated as Exhibit 2, were not filed with the complaint.

II. Functionality and Market Context

The complaint does not provide any description of the accused products' specific functionality, operation, or market position.

IV. Analysis of Infringement Allegations

The complaint alleges that the "Exemplary Defendant Products practice the technology claimed by the '643 Patent" and that they "satisfy all elements of the Exemplary '643 Patent Claims" (Compl. ¶16). However, because the complaint incorporates its infringement theories by reference to an external exhibit (Exhibit 2) that was not provided, no specific, element-by-element mapping of accused functionality to the patent claims is available for analysis in the public filing (Compl. ¶17).

No probative visual evidence provided in complaint.

• Identified Points of Contention:
  • Scope Questions: A primary question may be whether the architecture of the accused security products aligns with the claimed "integrated combination" of an "application logic module" and an "operation assurance logic module." The infringement analysis will likely depend on whether Defendant's software involves the specific "interlocking" taught in the patent, which makes components "inseparable," or if its modules are merely packaged together in a conventional manner (’643 Patent, col. 4:20-23).
  • Technical Questions: The complaint provides no facts to suggest how the accused products perform the claimed functions. This raises several technical questions: What evidence demonstrates that the accused products generate "unique security tags" to validate their own operation, as opposed to checking for external threats? Where does the "associated operational checking logic" reside, and does it align with the client-server (TFG/TTC) architecture described in the patent?

V. Key Claim Terms for Construction

• The Term: "integrated combination"

  • Context and Importance: This term is foundational to Claim 1. The dispute may turn on whether the accused products’ software architecture meets this limitation. Practitioners may focus on this term because its construction will determine whether simply bundling security features is sufficient to infringe, or if a specific, transformative "interlocking" process is required.
  • Intrinsic Evidence for a Broader Interpretation: The patent abstract describes the method as "taking logic modules... and transforming them into a hidden program by integrating modules to execute together," which could be argued to encompass any system where different security functions are designed to cooperate (’643 Patent, Abstract).
  • Evidence for a Narrower Interpretation: The specification repeatedly describes the integration as creating an "interlocking of the program sub-tasks in a manner which is hard to reverse engineer" to make the resulting program "inseparable" and "unreadable." This language, along with figures like FIG. 12 showing obfuscation and encryption, suggests a specific, security-hardening transformation rather than mere functional cooperation (’643 Patent, col. 4:20-23; col. 5:48-53).

• The Term: "unique security tags"

  • Context and Importance: The nature of these "tags" is critical to defining the scope of the invention. The infringement analysis will depend on whether this term covers any security-related data or is limited to the specific type of signal described in the patent.
  • Intrinsic Evidence for a Broader Interpretation: In a general sense, any hash or digital signature used for an integrity check could be considered a "security tag."
  • Evidence for a Narrower Interpretation: The patent specifies that the signal is generated by an "interlocked" module, such as a "cryptographic pseudo-random generator," to produce an output that "cannot be predicted." It is used to validate a "trusted flow" of communications, suggesting the tags are dynamic, unpredictable signals for authenticating ongoing processes, not static identifiers (’643 Patent, col. 1:63-66; col. 2:11-14).

VI. Other Allegations

• Indirect Infringement: The complaint alleges induced infringement, stating that Defendant provides "product literature and website materials" that instruct customers on how to use the accused products in an infringing manner (Compl. ¶14). It also alleges inducement through the sale of the products to customers for their end-use (Compl. ¶15).
• Willful Infringement: The complaint alleges that service of the complaint itself provides "actual knowledge of infringement" and that Defendant’s continued activities thereafter support a claim for enhanced damages (Compl. ¶¶13-14). No allegations of pre-suit knowledge are made.

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

• A core issue will be one of definitional scope: Can the term "integrated combination," which the patent describes as an "inseparable" and "interlocked" program created through obfuscation, be construed to cover a commercial security product where different functional modules are packaged and operate together without such specific, transformative integration?
• A key evidentiary question will be one of functional mapping: Given the complaint’s lack of factual detail, the case will depend on what specific features within Bitdefender's products Plaintiff can identify as corresponding to the patent's distinct "operation assurance logic module" and "operational checking logic."
• A central dispute will likely be one of technical operation: Does the accused technology function by generating its own unpredictable security tags to prove its own integrity, as claimed, or does it operate primarily by detecting external malware signatures and threats, a potentially fundamental difference in security paradigms?