Sulaco Enterprises LLC v. Imperva Inc

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: Sulaco Enterprises LLC (Texas)
  • Defendant: Imperva, Inc. (California)
  • Plaintiff's Counsel: Fabricant, Rubino & Lambrianakos LLP
• Case Identification: 2:26-cv-00345, E.D. Tex., 06/24/2026
• Venue Allegations: Plaintiff alleges venue is proper in the Eastern District of Texas because Defendant maintains a regular and established place of business in the district, transacts business there, and has previously not contested venue in the district in other litigation.
• Core Dispute: Plaintiff alleges that Defendant's API security products and services infringe a patent related to methods and systems for API-level intrusion detection.
• Technical Context: The technology relates to computer security, specifically the monitoring of Application Programming Interface (API) calls to detect and analyze malicious or unauthorized activity.
• Key Procedural History: The filing is an Amended Complaint. The complaint alleges that Defendant previously admitted or did not contest venue in the district in a separate case, DataCloud Techs., LLC v. Palo Alto Networks, Inc. (2:24-cv-00482).

Case Timeline

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

• Patent Identification: U.S. Patent No. 8,990,942 ("Method and Systems for API-Level Intrusion Detection"), issued March 24, 2015. Compl. ¶6
• The Invention Explained:
  • Problem Addressed: The patent's background section notes that traditional network-based or host-based intrusion detection systems (IDS) may not be ideal for protecting web services, as the application developer is often best positioned to define the "right" and "wrong" uses of an application. ʼ942 Patent, col. 1:19-42
  • The Patented Solution: The invention describes a system where an "API sandbox module" intercepts API calls directed to an application. ʼ942 Patent, abstract ʼ942 Patent, Fig. 2 The sandbox parses the API call to extract information like its name and parameters, creates a copy, and forwards that copy to a "rules execution engine." ʼ942 Patent, col. 3:45-56 This engine then compares the call information against a set of security rules to determine if a violation has occurred. ʼ942 Patent, abstract
  • Technical Importance: This API-centric approach allows for the creation of more nuanced, context-aware security policies that are private, scalable, and can be rapidly deployed to counter threats specific to an application's logic. ʼ942 Patent, col. 3:1-15
• Key Claims at a Glance:
  • The complaint asserts infringement of at least independent claim 22. Compl. ¶14
  • The essential elements of independent claim 22 are:
    • An API-level intrusion detection method comprising:
    • receiving an API call for a service at an API sandbox module;
    • parsing the API call to extract an API call name or parameters;
    • generating a copy of the API call name or parameters;
    • providing the copy to an intrusion detection rules execution engine;
    • determining, via the engine, if the API call violates security rules from a security rules object;
    • providing an indication of any violation;
    • wherein the API sandbox module is co-located at an enterprise software gateway and configured for receiving API calls for user-selected developers and API name references, and for processing them for application-specific intrusion detection.
  • The complaint broadly alleges infringement of one or more claims of the '942 Patent. Compl. ¶13

III. The Accused Instrumentality

• Product Identification: The accused products include Imperva API Security, Imperva API Security Anywhere Self-Managed, Imperva Web Application Firewall (WAF), Imperva WAF Gateway solutions, and other related security products and services. Compl. ¶13 The allegations focus on "Imperva API Security Anywhere." Compl. ¶14
• Functionality and Market Context:
  • The complaint alleges that the accused products, particularly API Security Anywhere operating with the Imperva WAF Gateway Plug-in, perform an API-level intrusion detection method. Compl. ¶14 The system is alleged to provide "continuous protection of all APIs using deep discovery and classification to detect all public, private and shadow APIs." Compl. ¶17, citing an Imperva datasheet
  • The system allegedly receives API calls via an "API Security sensor," parses them to extract endpoints and parameters, and provides the captured data to an "API Security Anywhere controller" for analysis against security policies. Compl. ¶15 Compl. ¶16 Compl. ¶18 Compl. ¶19
  • A diagram in the complaint depicts the architecture for Imperva API Security Anywhere, showing API calls being processed by an "API Security Anywhere Controller" in both cloud-managed and self-managed environments. Compl. p. 5
  • Another screenshot from Imperva documentation illustrates how API-level policies can be configured to detect violations such as "New Paths," "New Methods," or "Invalid Parameters Data Type." Compl. p. 6

IV. Analysis of Infringement Allegations

'942 Patent Infringement Allegations

• Identified Points of Contention:
  • Scope Question: A central question may be whether Imperva's "API Security sensor" or "WAF Gateway Plug-in" meets the definition of an "API sandbox module" as that term is used in the patent.
  • Scope Question: A related issue may be whether the architectural limitation "co-located at an enterprise software gateway" is met by a "plug-in integrated into" a WAF gateway, which could turn on the specific technical nature of that integration.
  • Technical Question: The complaint maps the claim's requirement for "user selected developers" and "user selected API name references" to Imperva's use of "user-selected API/OAS configuration" and API hosts/paths. Compl. ¶21 The degree of functional correspondence between these features could be a point of dispute.

V. Key Claim Terms for Construction

• The Term: "API sandbox module"

  • Context and Importance: This term describes a core component of the claimed invention. The infringement case hinges on whether Defendant's "API Security Anywhere WAF Gateway Plug-in" or "API Security sensor" falls within its scope.
  • Intrinsic Evidence for a Broader Interpretation: The specification functionally describes the module as receiving API calls and making a non-invasive copy for analysis, which could support a broad reading covering any component that performs this function. ʼ942 Patent, col. 3:45-56
  • Intrinsic Evidence for a Narrower Interpretation: The patent states that the sandbox ensures that data being operated on is "not accessible to modules on the other side of the API sandbox," which suggests a degree of isolation that Defendant may argue its product does not possess. ʼ942 Patent, col. 3:56-4:1 The term "sandbox" itself implies a constrained, secure environment.

• The Term: "co-located at an enterprise software gateway"

  • Context and Importance: This limitation appears in the asserted independent claim 22 and is a key distinguishing feature. Plaintiff alleges that Defendant's "WAF Gateway Plug-in integrated into an Imperva on-premises WAF Gateway" satisfies this element. Compl. ¶21 The interpretation of "co-located" will be critical.
  • Intrinsic Evidence for a Broader Interpretation: The patent itself uses the term broadly, stating in the summary that an "SDK may be co-located at an enterprise level software gateway." ʼ942 Patent, col. 1:66-2:2 This could support an interpretation where "co-located" means running in the same software or hardware environment, consistent with a plug-in architecture.
  • Intrinsic Evidence for a Narrower Interpretation: A defendant might argue "co-located at" requires a more specific and physically or architecturally unified relationship than a "plug-in" architecture provides, potentially arguing it must be a single, inseparable product. However, the specification's language appears flexible.

VI. Other Allegations

• Indirect Infringement: Plaintiff alleges that Defendant induces infringement by providing customers with products and "supplying them with instructions on how to operate the infringing technology" through its website, product literature, and other publications. Compl. ¶25
• Willful Infringement: The complaint alleges knowledge of the '942 Patent as of the filing date of the original complaint. Compl. ¶24 It also alleges willful blindness, claiming Defendant has a "policy of not reviewing the patents of others" and was therefore willfully blind to its infringement since the patent's issuance. Compl. ¶24

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

• A core issue will be one of definitional scope: can the term "API sandbox module," as defined and used in the '942 Patent, be construed to read on Defendant's "API Security sensor" and "WAF Gateway Plug-in"? The outcome will likely depend on the level of functional isolation required by the term "sandbox."
• A second key issue will be a matter of technical and factual mapping: does the architecture of Defendant's accused system, where a "plug-in" is "integrated into" a gateway, satisfy the claim 22 requirement that the sandbox module be "co-located at an enterprise software gateway"?
• An important question for damages will be one of intent: can Plaintiff produce sufficient evidence to support its allegation of willful blindness, particularly the claim that Defendant maintains a "policy of not reviewing the patents of others," which could expose Defendant to enhanced damages?