Sulaco Enterprisessssss LLC v. Check Point Software Tech Ltd

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: Sulaco Enterprises LLC (Texas)
  • Defendant: Check Point Software Technologies Ltd. (Israel)
  • Plaintiff’s Counsel: Fabricant LLP
• Case Identification: 2:25-cv-01192, E.D. Tex., 12/05/2025
• Venue Allegations: Plaintiff alleges venue is proper because Defendant is not a resident of the United States and may be sued in any judicial district.
• Core Dispute: Plaintiff alleges that Defendant’s cloud security products, particularly its Web Application Firewall (WAF), infringe a patent related to API-level intrusion detection.
• Technical Context: The technology concerns methods for monitoring Application Programming Interface (API) calls in real-time to detect and block malicious activity, a critical function in modern web application security.
• Key Procedural History: No significant procedural events are mentioned in the complaint.

Case Timeline

Date	Event
2013-02-18	’942 Patent Priority Date
2015-03-24	’942 Patent Issue Date
2025-12-05	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"

• Patent Identification: U.S. Patent No. 8,990,942, "Methods and Systems for API-Level Intrusion Detection," issued March 24, 2015.

The Invention Explained

• Problem Addressed: The patent describes a need for improved intrusion detection for web services, noting that traditional network-based or host-based systems operating at the Internet Protocol (IP) packet level are insufficient for understanding application-specific threats (’942 Patent, col. 1:19-41).
• The Patented Solution: The invention proposes an intermediary monitoring system that intercepts API calls before they reach the main application server. This system utilizes an "API sandbox" to create a non-invasive copy of the API call's name and parameters, which is then analyzed by a "rules execution engine" against a set of security policies (’942 Patent, col. 3:36-54; Fig. 2). By separating the security analysis from the application server, the system provides a flexible, scalable, and customizable method for detecting threats like denial-of-service attacks or malware infections (’942 Patent, col. 1:50-2:2).
• Technical Importance: This approach allows for security rules to be managed and deployed independently of the application's code, offering a centralized security layer for potentially large numbers of users and applications (’942 Patent, col. 2:56-65).

Key Claims at a Glance

• The complaint asserts at least independent claim 22 (’942 Patent, col. 23:55-24:22; Compl. ¶15).
• Essential Elements of Claim 22:
  • 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 API call name and/or parameters.
  • Providing the copy to an intrusion detection rules execution engine that includes hardware processors.
  • Determining, via the engine, if the API call violates security rules from a security rules object.
  • Providing an indication of whether the API call violates the rules.
  • The API sandbox module is co-located at an enterprise software gateway and configured to receive and process calls for 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 complaint identifies a range of Check Point products, with a primary focus on the "CloudGuard Cloud Products including but not limited to the CloudGuard WAF" (Web Application Firewall) (Compl. ¶14). Also implicated are related services such as ThreatCloud AI, Check Point Zero Day Protection, and Sandboxing appliances (Compl. ¶18).

Functionality and Market Context

The complaint alleges the accused products provide API-level intrusion detection and sandboxing capabilities (Compl. ¶15). The Check Point CloudGuard WAF is described as a system that secures APIs by analyzing traffic, validating schemas, and detecting threats (Compl. p. 7). A screenshot from Defendant’s documentation describes a "Contextual Evaluation Engine" that uses machine learning to determine if a payload is malicious (Compl. p. 6). The system allegedly uses a "sandbox" located in the "Check Point ThreatCloud" to run an "emulated run" for preventing attacks (Compl. p. 13). The complaint alleges these products are used for application-specific intrusion detection (Compl. ¶18).

IV. Analysis of Infringement Allegations

U.S. Patent No. 8,990,942 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 CloudGuard WAF performs an API-level intrusion detection method and receives API calls for a service at an API sandbox module, such as ThreatCloud AI and Sandboxing appliances.	¶¶16, 18	col. 1:46-48
parsing the API call to extract at least one of: an API call name; or one or more API call parameters;	The CloudGuard WAF parses the API call to extract the API call name and/or its parameters.	¶16	col. 1:48-51
generating a copy of the at least one of: the API call name or the one or more API call parameters;	The CloudGuard WAF generates a copy of the API call name and/or its parameters.	¶16	col. 1:51-54
providing, to an intrusion detection rules execution engine including one or more hardware processors, the copy of the at least one of: the API call name or the one or more API call parameters;	The CloudGuard WAF provides the copy of the API call elements to an intrusion detection rules execution engine. A provided screenshot describes a "Contextual Evaluation Engine" that makes a determination of maliciousness.	¶17; p. 6	col. 1:54-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 CloudGuard WAF determines, via the engine, whether the API call violates one or more security rules from a security rules object.	¶17	col. 1:58-61
and providing an indication of whether the API call is in violation of the one or more security rules;	The CloudGuard WAF provides an indication of whether the API call violates the security rules.	¶17	col. 1:61-63
wherein the API sandbox module is co-located at an enterprise software gateway...	The complaint alleges the accused sandbox module is co-located at an enterprise software gateway. A provided diagram shows "API-level inspection" as a component within a larger security architecture.	¶18; p. 12	col. 24:7-9

• Identified Points of Contention:
  • Scope Questions: The case may turn on the construction of key terms relative to modern cloud architectures. For instance, a central question may be whether Defendant's distributed, cloud-based "ThreatCloud" and on-premises "SandBlast Appliances" (Compl. p. 11) meet the claim requirement that an "API sandbox module" be "co-located at an enterprise software gateway." The patent describes this gateway as "tunneling all selected API calls from/to within the enterprise" (’942 Patent, col. 2:1-2), raising the question of how this applies to a hybrid cloud/on-premise security service.
  • Technical Questions: A factual question may arise regarding the specific operations of the accused products. For example, what evidence does the complaint provide that the CloudGuard WAF's process of analysis involves "generating a copy" of the API call parameters and "providing" that specific copy to the rules engine, as distinct from simply analyzing the live data stream? The complaint asserts these steps occur, but the mechanism is not detailed (Compl. ¶16-17).

V. Key Claim Terms for Construction

• The Term: "API sandbox module"

• Context and Importance: This term is central to the infringement theory, as the complaint identifies Defendant’s "ThreatCloud AI" and "Sandboxing appliances" as the infringing "API sandbox module" (Compl. ¶18). The definition will determine whether Defendant’s threat analysis environments, which include cloud-based emulation (Compl. p. 13), fall within the scope of the claims.

• Intrinsic Evidence for Interpretation:

  • Evidence for a Broader Interpretation: The patent specification describes the "API sandbox" in functional terms as a module that can "receive API calls from user devices, make a local and non-invasive copy of both the called API names and API parameters, and pass the API call to the original web service provider" (’942 Patent, col. 3:37-42). This functional description could support an interpretation covering various types of isolated analysis environments.
  • Evidence for a Narrower Interpretation: The patent’s description of the sandbox making a "local" copy and its depiction as a distinct architectural block (Fig. 2, element 201) could support a narrower construction that requires a specific type of localized, copying-based isolation, potentially excluding systems that analyze data streams in a more integrated or distributed manner.

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

• Context and Importance: The location and architectural placement of the "API sandbox module" is a specific limitation in claim 22. The complaint alleges the accused products meet this limitation, but describes them as a combination of cloud services and on-premise appliances (Compl. ¶18, p. 11). Practitioners may focus on whether "co-located" requires physical or logical proximity within a single gateway, or if it can read on a distributed system where components are logically connected but physically separate.

• Intrinsic Evidence for Interpretation:

  • Evidence for a Broader Interpretation: The term "co-located" is not explicitly defined. A party might argue that in the context of software, logical integration within a unified security architecture (as depicted in the diagram on page 12 of the complaint) satisfies the "co-located" requirement, even if components are physically distributed.
  • Evidence for a Narrower Interpretation: The specification states that "the SDK may be co-located at an enterprise level software gateway tunneling all selected API calls from/to within the enterprise" (’942 Patent, col. 1:66-2:2). This language, particularly the reference to "tunneling," could suggest a more traditional, centralized gateway through which all relevant traffic must pass, potentially limiting the term’s application to distributed cloud services.

VI. Other Allegations

• Indirect Infringement: The complaint alleges induced infringement, stating that Defendant knowingly encourages infringement by providing customers with products and instructions on how to operate the infringing technology (Compl. ¶¶20, 22). It also alleges contributory infringement, asserting that the accused components are not staple articles of commerce, have no substantial non-infringing uses, and are known by Defendant to be specially adapted for infringement (Compl. ¶23).
• Willful Infringement: Willfulness is alleged based on Defendant’s knowledge of the ’942 Patent as of the filing of the complaint (Compl. ¶21). The complaint also pleads willful blindness, alleging on information and belief that Defendant has a policy of not reviewing the patents of others to remain "willfully blind to the Patent-in-Suit at least as early as the issuance of the Patent-in-Suit" (Compl. ¶21).

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

• A core issue will be one of definitional scope: can the term "co-located at an enterprise software gateway," described in a 2013-priority patent, be construed to cover the distributed, hybrid cloud-and-appliance architecture of Defendant’s modern security products?
• A second key issue will be one of technical implementation: what evidence will demonstrate that the accused CloudGuard WAF and its associated services perform the specific, sequential method steps of Claim 22, particularly the discrete acts of "generating a copy" of API elements and "providing" that copy to a separate "rules execution engine" for analysis?