AttestWave LLC v. Honeywell Intl Inc

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: AttestWave LLC (Delaware)
  • Defendant: Honeywell International Inc. (Delaware)
  • Plaintiff’s Counsel: Rabicoff Law LLC
• Case Identification: 2:24-cv-00926, E.D. Tex., 11/13/2024
• Venue Allegations: Plaintiff alleges venue is proper in the Eastern District of Texas because Defendant maintains an established place of business in the District and has allegedly committed acts of patent infringement there.
• Core Dispute: Plaintiff alleges that certain of Defendant’s products infringe a patent related to secure logic interlocking for validating software operations in computer networks.
• Technical Context: The technology addresses methods for ensuring that software on a computer network operates correctly according to predefined rules, a function intended to improve security and performance in data communications.
• Key Procedural History: The complaint does not mention any prior litigation, Inter Partes Review (IPR) proceedings, or licensing history related to the patent-in-suit.

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.

The Invention Explained

• Problem Addressed: The patent describes a problem inherent in computer networks where users, having access to the software on their own devices, can modify it to overburden the network or bypass security, in contrast to traditional telephone networks where the network infrastructure is not user-accessible (’643 Patent, col. 2:30-38). Existing security measures like firewalls are described as merely "reactive" to such misbehavior (’643 Patent, col. 2:50-52).
• The Patented Solution: The invention proposes a system of "interlocking" separate software functions into a single, combined functionality (’643 Patent, col. 2:7-9). For example, an operational program (like one for sending data packets) is integrated with a cryptographic signal generator. A separate "checker" at the network level, which knows how the signal should be generated, can validate the signal received with a data packet. A valid signal confirms that the originating software is authentic and has not been tampered with, thereby creating a "trusted flow" of data (’643 Patent, Abstract; FIG. 1).
• Technical Importance: This approach sought to provide a proactive method for ensuring software compliance, allowing network operators to validate that remote client software is behaving as expected and to create trusted communication channels that could be prioritized or given a higher class of service (’643 Patent, col. 1:31-36; col. 2:64-67).

Key Claims at a Glance

• The complaint asserts infringement of "one or more claims" and "the Exemplary '643 Patent Claims" but does not identify any specific claims being asserted (Compl. ¶11, ¶16).
• Independent claim 1, a representative system claim, includes the following essential elements:
  • An "integrated combination" of a "software application logic module" and an "operation assurance logic module", which execute together to provide combined functions and generate "unique security tags".
  • Storage for the integrated program.
  • A controller for executing the integrated program.
  • The "unique security tags" are generated only when the integrated program is executed and has not been tampered with.
  • An "associated operational checking logic" for validating the program's integrity responsive to the "unique security tags".

III. The Accused Instrumentality

Product Identification

The complaint does not identify any specific accused products by name. It refers to them as the "Exemplary Defendant Products" and states they are identified in an attached Exhibit 2, which was not publicly filed with the complaint (Compl. ¶11, ¶16).

Functionality and Market Context

The complaint does not provide sufficient detail for analysis of the functionality or market context of the accused products.

IV. Analysis of Infringement Allegations

The complaint alleges that the "Exemplary Defendant Products practice the technology claimed by the '643 Patent" and "satisfy all elements of the Exemplary '643 Patent Claims" (Compl. ¶16). It incorporates by reference claim charts from Exhibit 2, which is not provided, and offers no further narrative detail on its infringement theory (Compl. ¶17). Therefore, a detailed claim-by-claim analysis is not possible from the complaint alone.

No probative visual evidence provided in complaint.

Identified Points of Contention

Based on the technology and the likely nature of the dispute, several technical and legal questions may arise.

• Scope Questions: A central question may be whether the term "integrated combination" as used in the patent, which is described with features like "obfuscation" and making components "inseparable," can be construed to read on the software architecture of the accused products (’643 Patent, col. 4:20-27). The defense may argue that its products use standard modular software that lacks the claimed level of deep, interlocking integration.
• Technical Questions: The infringement analysis will raise the question of what evidence the plaintiff can provide that the accused products generate "unique security tags" that are specifically tied to the integrity of the entire program, as required by the claims. A further question is whether the accused products contain an "operational checking logic" that performs the specific function of validating program integrity based on these tags, or if it performs a more general security function that is technically distinct from what is claimed.

V. Key Claim Terms for Construction

"integrated combination" (from Claim 1)

• Context and Importance: This term appears central to the patent's "interlocking" concept. Its construction will likely determine whether the claims require a single, transformed software program created via obfuscation or encryption, or if they could also cover systems with more loosely coupled but coordinated software modules. The viability of the infringement case may depend heavily on this definition.
• Intrinsic Evidence for Interpretation:
  • Evidence for a Broader Interpretation: The specification uses general language like "integrating modules to execute together," which might not strictly require a single compiled program file (’643 Patent, col. 6:50-51). The term "combination" itself is often afforded a broad construction in patent law.
  • Evidence for a Narrower Interpretation: The specification repeatedly emphasizes making software components "inseparable" through "obfuscation" and "encryption" to defeat reverse engineering (’643 Patent, col. 4:20-27, col. 5:45-51). Embodiments shown in figures like 12A-D depict an "Obfuscator" or "Program Encrypter" that transforms multiple logic modules into a "Single Logic Program," suggesting a narrow definition requiring a transformative integration process (’643 Patent, FIG. 12A-D).

"operational checking logic" (from Claim 1)

• Context and Importance: This term defines the "checker" component of the claimed system. The dispute will likely involve whether the accused functionality (e.g., a firewall or other security feature) performs the specific validation required by the claim—validating that the program "was not tampered with responsive to the unique security tags"—or a more generic security function.
• Intrinsic Evidence for Interpretation:
  • Evidence for a Broader Interpretation: The patent states this logic can be part of various network elements, including a "firewall, a gateway, a router," which could support an argument that it covers standard network security appliances (’643 Patent, col. 20:11-12).
  • Evidence for a Narrower Interpretation: The claim requires the logic to validate the program's integrity "responsive to the unique security tags," a specific function beyond general packet filtering. The patent's figures depict the "Trusted Tag Checker" (TTC) as a purpose-built component with its own logic for computing and checking tags in coordination with the "Trusted Flow Generator" (TFG), suggesting it is not a generic, off-the-shelf component (’643 Patent, FIG. 9, FIG. 11).

VI. Other Allegations

• Indirect Infringement: The complaint alleges induced infringement, stating that Defendant sells the accused products and distributes "product literature and website materials" that instruct end users on how to use the products in an allegedly infringing manner (Compl. ¶14-15).
• Willful Infringement: The complaint does not use the term "willful." It alleges "Actual Knowledge of Infringement" based solely on the future service of the complaint and its attachments (Compl. ¶13). This allegation, if proven, could only support a claim for enhanced damages based on post-filing conduct, as no pre-suit knowledge is alleged.

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

• A central issue will be one of evidentiary sufficiency: Given the complaint's lack of specificity regarding the accused products and the infringement mechanism, a primary question is whether the plaintiff can produce technical evidence demonstrating that the accused products actually implement the highly specific and often concealed "interlocking" and "tag-checking" functionalities required by the patent claims.
• The case will likely turn on a question of definitional scope: Can the term "integrated combination", which the patent describes in the context of obfuscation and making components "inseparable," be construed broadly enough to cover the potentially modular software architecture of modern commercial products, or will it be limited to the tightly-coupled, transformed program shown in the patent's specific embodiments?
• A key technical question will be one of functional specificity: Does an accused security feature perform the specific, claimed function of validating the integrity of an entire software program via unique, cryptographically-generated tags, or does it perform a more conventional and technically distinct security function, such as user authentication or standard packet filtering?