AttestWave LLC v. SAP America Inc

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: AttestWave LLC (Delaware)
  • Defendant: SAP America, Inc. (Delaware)
  • Plaintiff’s Counsel: Garibian Law Offices, P.C.; Rabicoff Law LLC
• Case Identification: 1:25-cv-00251, D. Del., 03/05/2025
• Venue Allegations: Venue is asserted based on Defendant's incorporation in Delaware and its alleged established place of business within the district.
• Core Dispute: Plaintiff alleges that certain unidentified SAP software products infringe a patent related to a system for ensuring the secure and unmodified operation of software in a network environment.
• Technical Context: The technology addresses the challenge of trusting software running on remote computers by "interlocking" operational code with a security-signal generator, making it possible to remotely verify program integrity.
• Key Procedural History: The complaint does not allege any prior litigation, inter partes review 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

(Compl. ¶¶8-9; '643 Patent, p. 1)

The Invention Explained

• Problem Addressed: The patent's background describes the difficulty in computer networks of ensuring that end-user software operates according to defined rules, as users can often modify programs. This vulnerability can lead to network abuse, Denial-of-Service attacks, and unstable performance, as traditional security methods like firewalls are merely "reactive" to misbehavior rather than preventative. ('643 Patent, col. 1:14-23, col. 2:48-52).
• The Patented Solution: The invention proposes a system to create trusted software by "interlocking" a standard operational program module with a cryptographic module that generates an unpredictable signal. These modules are transformed into a single, inseparable "combined functionality." This ensures that the unpredictable security signal (e.g., a tag in a data packet) can only be generated if the operational part of the program is executed correctly and without tampering. A remote network element can then validate this signal to verify the integrity of the sending software. ('643 Patent, Abstract; col. 2:7-19). The patent’s FIG. 1 shows a high-level system architecture with a Trusted Flow Generator (TFG) creating tagged data packets and a Trusted Tag Checker (TTC) verifying them within a network. ('643 Patent, FIG. 1).
• Technical Importance: This approach provides a proactive method for guaranteeing that network participants are operating as "trusted" entities, which can enable differentiated quality of service based on verifiable software integrity. ('643 Patent, col. 1:27-36).

Key Claims at a Glance

• The complaint asserts "one or more claims" of the '643 Patent, referencing "Exemplary '643 Patent Claims" in an unprovided exhibit. Independent Claim 1 is representative of the core invention. (Compl. ¶11).
• The essential elements of Independent Claim 1 include:
  • An "integrated combination" of a "software application logic module" and an "operation assurance logic module."
  • The modules are executed to provide "combined computing functions" that include the application's functionality and the "concurrent generation of unique security tags."
  • A "controller" for executing this integrated program.
  • The "unique security tags" are generated only when the integrated program is executed without being tampered with.
  • An "associated operational checking logic" for validating the program's integrity based on the received security tags. ('643 Patent, col. 37:51-38:22).
• The complaint's general allegations suggest it reserves the right to assert additional independent and dependent claims. (Compl. ¶11).

III. The Accused Instrumentality

Product Identification

The complaint does not identify any accused products by name. It refers to "Exemplary Defendant Products" that are identified in claim charts attached as Exhibit 2, which was not filed with the complaint. (Compl. ¶¶11, 16).

Functionality and Market Context

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

IV. Analysis of Infringement Allegations

The complaint alleges infringement through claim charts in Exhibit 2, which is not publicly available. (Compl. ¶¶16-17). The narrative infringement theory alleges that Defendant's "Exemplary Defendant Products" practice the technology claimed in the ’643 Patent and satisfy all elements of the asserted claims. (Compl. ¶16). The complaint's theory appears to be that components within the accused SAP products perform functions analogous to the "Trusted Flow Generator" (TFG) and "Trusted Tag Checker" (TTC) taught by the patent. The patent’s FIG. 8 depicts a functional flowchart for the TFG software, which computes and attaches security tags to data packets. ('643 Patent, FIG. 8). The corresponding FIG. 9 illustrates the flowchart for the TTC operation, which involves receiving packets and checking the validity of their security tags. ('643 Patent, FIG. 9). The plaintiff alleges direct infringement through Defendant’s own internal use and testing, as well as its sales of the products. (Compl. ¶¶11-12).

Identified Points of Contention

• Evidentiary Questions: The central issue will be evidentiary. Given the lack of detail in the complaint, the plaintiff must use discovery to find evidence that specific, concrete features of the unidentified SAP products map to the abstract elements of the asserted claims.
• Technical Questions: A key technical question for the court will be whether the accused products generate "unique security tags" that are "only generated when the integrated software computer program is executed and has not been tampered with," as required by Claim 1. Proving this specific causal link between program integrity and signal generation will be critical for the plaintiff.

V. Key Claim Terms for Construction

Term: "integrated combination"

Context and Importance

This term is foundational to the patent's "interlocking" concept. The required degree of integration between the "software application logic module" and the "operation assurance logic module" will be a central point of dispute. Practitioners may focus on this term because it directly addresses whether loosely coupled software components can infringe, or if a more monolithic, technically inseparable program is required.

Intrinsic Evidence for Interpretation

• Evidence for a Broader Interpretation: The specification suggests that integration can be achieved through various functional means, including "obfuscation," "encryption," or creating a "hidden program," which may support an argument that functional inseparability is sufficient. ('643 Patent, Abstract; col. 6:45-52).
• Evidence for a Narrower Interpretation: The specification and figures repeatedly refer to the output of the integration process as a "Single Logic Program," which could support an argument that the modules must be transformed into a single, inseparable binary file or object code. ('643 Patent, FIG. 12A-D, 1211, 1221, 1231).

Term: "operation assurance logic module"

Context and Importance

This term defines the security-generating component of the invention. Its construction will determine the specific type of functionality an accused product must have to be found infringing.

Intrinsic Evidence for Interpretation

• Evidence for a Broader Interpretation: The patent describes this module's function as generating "unpredictable signals," such as from a "cryptographic pseudo-random generator," which could be construed broadly to encompass a wide variety of integrity-checking or authentication code. ('643 Patent, col. 2:10-13).
• Evidence for a Narrower Interpretation: Specific embodiments in the patent describe the generation of a "Security Tag Vector (STV)" and "Security Tag Serial Number (STSN)," which are particular data structures. A defendant may argue this disclosure limits the term to modules that generate these specific types of tags or their close equivalents. ('643 Patent, FIG. 7B, 711, 712).

VI. Other Allegations

Indirect Infringement

The complaint alleges that Defendant induces infringement by selling the accused products to customers and providing "product literature and website materials" that allegedly instruct users to operate the products in a manner that infringes the ’643 Patent. (Compl. ¶14, ¶15).

Willful Infringement

The complaint does not contain allegations of pre-suit knowledge of the patent or infringement. It alleges that service of the complaint provides "actual knowledge" and that Defendant's continued alleged infringement thereafter supports a claim for post-filing damages enhancement. (Compl. ¶¶13-14).

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

• A primary issue for the court will be one of evidentiary demonstration: Can the plaintiff, having filed a complaint devoid of specific product details, uncover evidence in discovery to show that unnamed SAP software products contain the specific "integrated combination" of modules and perform the conditional security tag generation required by the asserted claims?
• A key legal question will be one of definitional scope: How will the term "integrated combination" be construed? The case may turn on whether a broad, functional interlocking of software modules is sufficient to meet this limitation, or if the patent requires a narrower, structural transformation of separate code into a single, monolithic program.