DCT
2:25-cv-01221
Sulaco Enterprisess LLC v. Radware Ltd
Key Events
Complaint
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: Sulaco Enterprises LLC (Texas)
- Defendant: Radware Ltd. (Israel)
- Plaintiff’s Counsel: Fabricant LLP
- Case Identification: 2:25-cv-01221, E.D. Tex., 12/16/2025
- Venue Allegations: Venue is alleged to be proper because the Defendant is not a resident of the United States and may therefore be sued in any judicial district.
- Core Dispute: Plaintiff alleges that Defendant’s application security products infringe a patent related to methods for detecting intrusions at the Application Programming Interface (API) level.
- Technical Context: The technology involves intercepting and analyzing API calls to identify and block malicious activity, a critical function for securing modern web services and applications.
- Key Procedural History: No significant procedural events, such as prior litigation or post-grant proceedings involving the patent-in-suit, are mentioned in the complaint.
Case Timeline
| Date | Event |
|---|---|
| 2013-02-18 | ’942 Patent Priority Date |
| 2015-03-24 | ’942 Patent Issue Date |
| 2024-07-28 | Date of Accused Product marketing brief referenced in complaint |
| 2025-12-16 | Complaint Filing Date |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 8,990,942 - Methods and Systems for API-Level Intrusion Detection
The patent-in-suit is U.S. Patent No. 8,990,942, issued March 24, 2015 (’942 Patent).
The Invention Explained
- Problem Addressed: The patent’s background section notes that traditional intrusion detection systems (IDS) operate at the network (IP packet) or host level. It posits that these approaches are ill-suited to detect improper application usage, as the application developer is best positioned to define correct versus incorrect use, which is best captured at the application programming level (’942 Patent, col. 1:20-41).
- The Patented Solution: The invention describes an intermediary "API sandbox module" that receives API calls intended for an application server. This module makes a "non-invasive, local copy" of the API call's name and parameters and provides this copy to a separate "rules execution engine." This engine then determines if the call violates security rules stored in a database, decoupling the security analysis from the primary application logic (’942 Patent, Abstract; col. 4:32-37; FIG. 2).
- Technical Importance: This architecture allows for a scalable and flexible API security system where security policies can be customized and rapidly deployed without modifying the underlying web service or application code (’942 Patent, col. 2:60-col. 3:14).
Key Claims at a Glance
- The complaint asserts infringement of at least independent claim 22 (’942 Patent, Compl. ¶15).
- The essential elements of method claim 22 include:
- Receiving an API call for a service at an API sandbox module.
- Parsing the API call to extract its name and/or parameters.
- Generating a copy of the extracted name and/or parameters.
- Providing the copy to an intrusion detection rules execution engine.
- Determining, via the engine, if the call violates security rules from a security rules object.
- Providing an indication of whether the call violates the rules.
- The complaint states Defendant infringes "one or more claims" and the prayer for relief is not limited to claim 22, suggesting the right to assert additional claims is reserved (Compl. ¶14; Prayer for Relief ¶a).
III. The Accused Instrumentality
Product Identification
The complaint names a suite of "Radware Application Protection Products," focusing primarily on the "Radware API Protection Product" (Compl. ¶¶14-15).
Functionality and Market Context
The complaint alleges the accused product is an API-level intrusion detection system (Compl. ¶15). It is described as using an "AI-driven protection engine" that "goes beyond analyzing logs of past attacks by continuously learning the API's business logic directly from real-time transactions" to detect and block malicious API calls (Compl. ¶17; p. 5). A screenshot from a Radware marketing document describes the product as providing "real-time detection and immediate mitigation of business logic attacks" (Compl. p. 4). The complaint alleges the product addresses "business logic vulnerabilities" that can be exploited even by authenticated users (Compl. p. 4).
IV. Analysis of Infringement Allegations
’942 Patent Infringement Allegations
| Claim Element (from Independent Claim 22) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| An application programming interface (API)-level intrusion detection method, comprising: receiving an API call for a service at an API sandbox module; | The Radware API Protection Product allegedly performs the step of receiving an API call at an API sandbox module, which is alleged on information and belief to be co-located at an enterprise software gateway. | ¶15, ¶18 | col. 4:32-41 |
| parsing the API call to extract at least one of: an API call name; or one or more API call parameters; | The product is alleged to perform the step of parsing the API call to extract its name or parameters. | ¶15 | col. 6:19-22 |
| generating a copy of the at least one of: the API call name or the one or more API call parameters; | The product is alleged to perform the step of generating a copy of the API call name or its parameters. | ¶16 | col. 6:15-16 |
| providing, to an intrusion detection rules execution engine including one or more hardware processors, the copy...; | The product is alleged to provide the copy to an "intrusion detection rules execution engine." A product screenshot refers to this as an "AI-driven protection engine" (p. 5). | ¶16 | col. 4:56-58 |
| determining, via the intrusion detection rules execution engine, whether the API call is in violation of one or more security rules obtained from a security rules object; | The product's engine allegedly determines if an API call is malicious by applying security policies. A screenshot states this "enables the detection of malicious API calls as they occur" (p. 6). | ¶17 | col. 6:23-28 |
| and providing an indication of whether the API call is in violation of the one or more security rules. | The product allegedly provides an indication of a violation by taking "immediate action by automatically generating and applying security policies in real-time to block business logic attacks" (p. 6). | ¶17 | col. 6:28-30 |
Identified Points of Contention
- Scope Questions: A central question may be whether the accused product's "AI-driven protection engine" that "continuously learn[s]" business logic (Compl. p. 5) meets the claim limitation of an "intrusion detection rules execution engine" that uses a "security rules object." The defense may argue that the patent contemplates a more static, pre-defined set of rules, whereas the accused product employs a dynamic, machine-learning-based approach that is fundamentally different.
- Technical Questions: The complaint alleges the existence of an "API sandbox module" on "information and belief" (Compl. ¶18). The provided marketing materials do not use this specific term. A key factual dispute may concern whether the architecture of the accused product includes a distinct module that generates a "copy" for analysis, as claimed, or if it processes API calls in a different manner.
V. Key Claim Terms for Construction
The Term: "API sandbox module"
Context and Importance
This term defines the entry point and initial processing step of the claimed method. The infringement case depends on establishing that the accused product contains a component with this functionality, which the complaint alleges "on information and belief" (Compl. ¶18).
Intrinsic Evidence for Interpretation
- Evidence for a Broader Interpretation: The specification describes the system as an "intermediary between end user devices ... and an application server" (’942 Patent, col. 2:56-58) and states the sandbox can be "co-located at an enterprise software gateway" (’942 Patent, col. 4:40-41). This language may support construing the term to cover a wide range of API interception architectures.
- Evidence for a Narrower Interpretation: The description of the sandbox making a "local and non-invasive copy of both the called API names and API parameters" (’942 Patent, col. 4:34-36) could support a narrower definition requiring a specific architecture where a copy is bifurcated for analysis while the original proceeds separately.
The Term: "intrusion detection rules execution engine"
Context and Importance
This term is critical because of the potential technical mismatch between the patent's disclosure and the accused product's functionality. Practitioners may focus on this term because the accused product is described as an "AI-driven protection engine" rather than a system executing pre-defined rules.
Intrinsic Evidence for Interpretation
- Evidence for a Broader Interpretation: Plaintiff may argue that the term should be understood functionally to encompass any component that applies security logic to API calls. The patent's abstract description of "determining ... whether the API call violates one or more security rules" (’942 Patent, Abstract) could be argued as a functional definition that an AI model satisfies.
- Evidence for a Narrower Interpretation: The specification provides examples of security rules in explicit, logical pseudo-code and VB code (e.g., "IF numrequests($api_name)>50 OVER time (01:00:00) THEN...") (’942 Patent, col. 7:7-13). This may support a narrower construction limited to systems that execute discrete, human-readable or machine-readable logical rules, as distinct from a system based on learned statistical models.
VI. Other Allegations
- Indirect Infringement: The complaint alleges inducement, stating that Radware provides its products to customers and instructs them on their infringing use through "demonstrations, testing, repairs, troubleshooting, training, and instructional guidance" (Compl. ¶¶19, 22). Contributory infringement is also alleged (Compl. ¶23).
- Willful Infringement: Willfulness is alleged based on knowledge of infringement "at least as of the date of this Complaint" (Compl. ¶21). The complaint also pleads in the alternative that Defendant was willfully blind to the patent since its issuance, based on an alleged corporate policy of not reviewing third-party patents (Compl. ¶21).
VII. Analyst’s Conclusion: Key Questions for the Case
- A core issue will be one of definitional scope: can the term "intrusion detection rules execution engine," disclosed in the context of explicit, logic-based rules, be construed to cover the accused product's "AI-driven protection engine" that "continuously learn[s]" from real-time data? This question highlights the legal challenge of applying patent claims to evolving technologies.
- A key evidentiary question will be one of architectural correspondence: does discovery reveal that the accused Radware API Protection Product incorporates a component that functions as an "API sandbox module" by creating a "copy" of API call data for separate analysis, as required by the claim, or is there a fundamental mismatch in its technical operation?