DCT
2:25-cv-01187
Sulaco Enterprisessssss LLC v. Fortinet Inc
Key Events
Complaint
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: Sulaco Enterprises LLC (Texas)
- Defendant: Fortinet Inc. (Delaware)
- Plaintiff’s Counsel: Fabricant LLP
- Case Identification: 2:25-cv-01187, E.D. Tex., 12/03/2025
- 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 and has committed acts of alleged infringement there.
- Core Dispute: Plaintiff alleges that Defendant’s web application firewall and cybersecurity sandbox products infringe a patent related to methods for detecting malicious activity at the Application Programming Interface (API) level.
- Technical Context: The dispute is in the cybersecurity domain, specifically concerning the protection of modern web applications and services that rely heavily on APIs for communication, which have become a significant target for sophisticated cyberattacks.
- 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
| Date | Event |
|---|---|
| 2013-02-18 | U.S. Patent No. 8,990,942 Priority Date |
| 2015-03-24 | U.S. Patent No. 8,990,942 Issues |
| 2025-12-03 | Complaint Filed |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 8,990,942 - "Methods and Systems for API-Level Intrusion Detection,"
- Patent Identification: U.S. Patent No. 8,990,942, "Methods and Systems for API-Level Intrusion Detection," issued March 24, 2015 (’942 Patent). (Compl. ¶6).
The Invention Explained
- Problem Addressed: The patent addresses the shortcomings of traditional intrusion detection systems that operate at the network (IP packet) or host level. These systems are often unable to effectively analyze and stop attacks that exploit the logic and structure of an application’s API calls, such as denial-of-service or malware attacks disguised as legitimate API requests (’942 Patent, col. 1:19-41).
- The Patented Solution: The invention proposes an intermediary system, termed an "API sandbox," that sits between a user's device and the application server. This sandbox intercepts API calls, creates a "local and non-invasive copy" of the call’s name and parameters, and analyzes this copy against a set of security rules in a "rules execution engine." Based on this analysis, the system can determine if the API call is malicious before the original, unaltered call is forwarded to the application server, thereby providing application-aware security (’942 Patent, Abstract; Fig. 2; col. 3:36-41).
- Technical Importance: This method allows for flexible, scalable, and customizable security screening that is specific to the API layer, a critical and often vulnerable component of modern web and cloud services (’942 Patent, col. 2:60-col. 3:4).
Key Claims at a Glance
- The complaint asserts at least independent claim 22 (’942 Patent, col. 23:55-col. 24:21; Compl. ¶14).
- Essential elements of claim 22 include:
- Receiving an API call for a service at an API sandbox module.
- Parsing the API call to extract its name or parameters.
- Generating a copy of the extracted name or parameters.
- Providing the copy to an intrusion detection rules execution engine.
- Determining, via the engine, if the API call violates security rules.
- Providing an indication of whether the call is in violation.
- The API sandbox module is co-located at an enterprise software gateway and configured for processing API calls for user-selected developers and API names for application-specific intrusion detection.
- The complaint does not explicitly reserve the right to assert dependent claims.
III. The Accused Instrumentality
Product Identification
The accused products include Fortinet's Web Application Firewall products, such as the FortiWeb 100F, and its Sandbox products, such as FortiSandbox, among a larger list of Fortinet security offerings (Compl. ¶13).
Functionality and Market Context
The complaint alleges that the accused products function as an integrated system to protect web applications and APIs from attacks (Compl. ¶9). Incoming traffic is first sent to the FortiWeb product, which analyzes it and sends suspicious files to the FortiSandbox for further analysis (Compl. p. 7). The complaint includes a marketing diagram describing this as a system that provides "real-time proactive detection, filtering, and protection against sophisticated attack tactics" (Compl. p. 5). The system uses "multi-layered and correlated detection methods" and a "machine-learning function" to identify and block threats (Compl. p. 6).
IV. Analysis of Infringement Allegations
'942 Patent Infringement Allegations
| Claim Element (from Independent Claim 22) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| receiving an application programming interface (API) call for a service at an API sandbox module; | The FortiWeb 100F allegedly receives API calls for a service at what the complaint terms an "API sandbox module." A product diagram shows all incoming traffic for web applications being sent to FortiWeb (Compl. p. 7). | ¶15 | col. 23:57-59 |
| parsing the API call to extract at least one of: an API call name; or one or more API call parameters; | FortiWeb allegedly parses the API call to extract its name or parameters. A screenshot from a FortiWeb Administration Guide states the system "parses the data and then learns the parameter and body of the API requests" (Compl. p. 6). | ¶16 | col. 23:60-63 |
| generating a copy of the at least one of: the API call name or the one or more API call parameters; | The complaint alleges the FortiWeb 100F performs the step of generating a copy of the API call name or its parameters. | ¶17 | col. 23:64-67 |
| providing, to an intrusion detection rules execution engine including one or more hardware processors, the copy...; | The complaint alleges the FortiWeb 100F provides the copy to an intrusion detection engine. FortiWeb is described as using "specialized heuristic detection engines" to analyze traffic (Compl. p. 6). | ¶17 | col. 24:1-5 |
| 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 FortiWeb 100F allegedly determines if an API call violates security rules. FortiWeb is described as using "multi-layered and correlated detection methods" to defend against known vulnerabilities and zero-day threats (Compl. p. 6). | ¶18 | col. 24:6-10 |
| and providing an indication of whether the API call is in violation of the one or more security rules; | If FortiSandbox detects a malicious file, it allegedly "sends an alert to FortiWeb," which then blocks the file (Compl. p. 7). | ¶18 | col. 24:11-13 |
| wherein the API sandbox module is co-located at an enterprise software gateway, and is configured for...processing the received API calls for application specific intrusion detection. | The FortiWeb 100F is alleged to use an "API sandbox module co-located at an enterprise software gateway" to perform application-specific intrusion detection for selected API calls (Compl. p. 8). | ¶19 | col. 24:14-21 |
- Identified Points of Contention:
- Scope Questions: A central question may be whether Fortinet’s Web Application Firewall (WAF) and Sandbox products, as commercially implemented, constitute the claimed "API sandbox module co-located at an enterprise software gateway." The complaint asserts this characterization, but the defense may argue that a WAF is a distinct technology that does not meet this specific architectural limitation.
- Technical Questions: The complaint’s direct evidence for the "generating a copy" limitation (Compl. ¶17) is less specific than for other elements. The patent describes creating a "local and non-invasive copy" for analysis (’942 Patent, col. 3:37-38). A potential dispute is whether the accused system actually creates a discrete copy for analysis, as claimed, or inspects the live data stream in a fundamentally different manner.
V. Key Claim Terms for Construction
- The Term: "API sandbox module"
- Context and Importance: This term defines the core component of the invention. The infringement case hinges on whether the accused FortiWeb/FortiSandbox architecture can be properly characterized as an "API sandbox module." Practitioners may focus on this term because its construction will likely determine whether the accused products fall within the claim's scope.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The specification suggests flexibility, stating the system can be "implemented as an intermediary between end user devices... and an application server" and can be deployed as "a standalone server, or as a process or application executing on the application server" (’942 Patent, col. 2:56-59, col. 6:1-3).
- Evidence for a Narrower Interpretation: The term "sandbox" itself implies an isolated environment. The patent describes the module as creating a "local and non-invasive copy" to ensure "other modules or data 'outside' the API sandbox may not become involved" (’942 Patent, col. 3:56-62), which could support a narrower definition requiring a degree of isolation not present in all WAFs.
- The Term: "generating a copy"
- Context and Importance: This term defines a key mechanistic step. A dispute over whether the accused system performs this step, as opposed to in-line analysis of the original data, could be dispositive.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The claim language itself does not specify the nature of the "copy," which could be argued to encompass any form of data replication for analysis, including buffering a data stream.
- Evidence for a Narrower Interpretation: The specification repeatedly refers to a "local and non-invasive copy" and a "T-Tap output" which separates the copied data for analysis by the "rules execution engine" (’942 Patent, col. 3:37-38, col. 3:54-58). This may suggest the invention requires creating a distinct, separate data object for analysis, rather than simply inspecting a data flow.
VI. Other Allegations
- Indirect Infringement: The complaint alleges induced infringement, stating that Defendant provides customers with instructions on how to operate the accused products through its website and product literature (Compl. ¶23). It also alleges contributory infringement, asserting the accused products are not staple articles of commerce and have no substantial non-infringing uses (Compl. ¶24).
- Willful Infringement: The complaint alleges willfulness based on knowledge of the ’942 Patent "at least as of the date of this Complaint" (Compl. ¶22). It further alleges pre-suit willful blindness, claiming Defendant has a policy of not reviewing patents of others and remained willfully blind to the patent since its issuance (Compl. ¶22).
VII. Analyst’s Conclusion: Key Questions for the Case
- A core issue will be one of definitional scope: Can Fortinet's integrated Web Application Firewall and Sandbox architecture be properly construed as the "API sandbox module co-located at an enterprise software gateway" as required by Claim 22, or is it a fundamentally different security paradigm?
- A key evidentiary question will be one of technical mechanism: Does the accused system’s method of analyzing API traffic meet the "generating a copy" limitation as understood in the context of the patent's specification, or does it operate on the live data stream in a way that falls outside the claim?
- A significant procedural question will concern willfulness: Can the plaintiff substantiate its claim of pre-suit willful blindness by providing evidence of a specific policy by the defendant to ignore the patent rights of others, or will the claim be limited to alleged infringement occurring after the complaint was filed?