DCT
4:24-cv-04927
Swarm Technology LLC v. Hewlett Packard Enterprises Co
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: Swarm Technology LLC (Arizona)
- Defendant: Hewlett Packard Enterprise Company (Delaware)
- Plaintiff’s Counsel: Newman Jones, PLLC; THE LAMBERSON LAW FIRM, PC
- Case Identification: 4:24-cv-04927, S.D. Tex., 04/02/2025
- Venue Allegations: Plaintiff alleges venue is proper because Defendant's principal place of business is located within the Southern District of Texas, and it maintains other regular and established places of business in Texas.
- Core Dispute: Plaintiff alleges that Defendant’s Aruba cloud networking products and services infringe patents related to a decentralized parallel processing architecture where autonomous co-processors proactively retrieve tasks from a shared pool.
- Technical Context: The technology addresses inefficiencies in traditional client-server computing architectures by creating a "swarm intelligence" model, a concept particularly relevant to the management of large-scale Internet of Things (IoT) and distributed cloud networks.
- Key Procedural History: The operative First Amended Complaint supersedes an original complaint filed on December 16, 2024. Plaintiff alleges it provided Defendant with actual notice of infringement upon service of the original complaint on January 30, 2025. The complaint also references a 2019 written offer to license two other patents from the same family to the Defendant.
Case Timeline
| Date | Event |
|---|---|
| 2013-01-25 | Earliest Priority Date for ’275 and ’161 Patents |
| 2014-01-17 | Plaintiff Swarm Technology, LLC Founded |
| 2015-01-01 | Defendant HPE Incorporated (approx.) |
| 2015-09-29 | Issue Date of Related ’777 Patent |
| 2015-01-01 | Approximate Date Plaintiff Alleges Infringement Began |
| 2019-01-01 | Plaintiff Offered to License Related Patents to Defendant (approx.) |
| 2020-03-17 | U.S. Patent No. 10,592,275 Issues |
| 2024-12-03 | U.S. Patent No. 12,159,161 Issues |
| 2024-12-16 | Original Complaint Filed |
| 2025-01-30 | Defendant Served with Original Complaint (Actual Notice Alleged) |
| 2025-04-02 | First Amended Complaint Filed |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 10,592,275 - “System and Method for Swarm Collaborative Intelligence Using Dynamically Configurable Proactive Autonomous Agents,” Issued March 17, 2020
The Invention Explained
- Problem Addressed: The patent describes conventional parallel processing systems as inefficient due to the central processing unit (CPU) acting as a bottleneck (Compl. ¶4). This "controller/responder" model consumes significant CPU bandwidth distributing tasks, waiting for their completion, and responding to interrupts, leaving co-processors idle and making the system vulnerable to controller overload or disconnection (’275 Patent, col. 1:60-2:8).
- The Patented Solution: The invention interposes an intelligent "task pool" between the controller (CPU) and the co-processors (Compl. ¶6). The controller populates this pool with tasks, and the co-processors, acting as "autonomous agents," proactively retrieve tasks from the pool on their own initiative without direct commands from the controller (’275 Patent, col. 2:19-36; Compl. ¶7). The complaint provides a block diagram illustrating the patented architecture, showing a "Controller" that populates a "Task Pool," from which multiple "Co-Processors" proactively retrieve tasks (Compl. p. 5). This decouples the components, allowing for more efficient resource use and "plug-and-play" scalability (’275 Patent, col. 3:42-50).
- Technical Importance: This decentralized architecture was designed to improve the scalability, efficiency, and resilience of distributed computing systems, particularly for managing large networks of disparate devices as found in the Internet of Things (IoT) (’275 Patent, col. 1:24-34; Compl. ¶13).
Key Claims at a Glance
- The complaint asserts independent Claim 1 (Compl. ¶55).
- The essential elements of Claim 1 include:
- A collaborative intelligence system comprising a task pool, a controller, a first co-processor, and a second co-processor.
- The controller is configured to populate the task pool with pluralities of first and second tasks.
- The first and second co-processors are each configured to successively and proactively retrieve their respective tasks from the task pool, process them, and update the task pool upon completion.
- This task retrieval and processing occurs "all without any communication between the... co-processor and the controller."
- The system is configured to "dynamically accept" co-processors on a "plug-and-play basis without any communication with the controller."
- The tasks share a "common objective," and the co-processors "autonomously work together in solidarity with the task pool" to complete it.
- The complaint reserves the right to assert dependent claims 2-4, 6-7, and 9-17 (Compl. ¶55).
U.S. Patent No. 12,159,161 - “System and Method For Swarm Collaborative Intelligence Using Dynamically Configurable Proactive Autonomous Agents,” Issued December 3, 2024
The Invention Explained
- Problem Addressed: The patent addresses the same fundamental inefficiencies in centralized computing architectures as the ’275 Patent, with the complaint noting the specifications are "substantially identical" (Compl. p. 3, fn. 1). The specific problem highlighted is the static nature of co-processor functions.
- The Patented Solution: The ’161 Patent builds on the task pool architecture by introducing a "device function reconfiguration task" (Compl. ¶10). A co-processor ("cell") can proactively retrieve and process this specific type of task, which reconfigures the co-processor itself to enable it to perform a new, second type of task it was previously incapable of performing (’161 Patent, col. 21:32-36). This allows the system's capabilities to be extended dynamically without direct intervention from the controller (Compl. ¶106).
- Technical Importance: This solution adds a layer of dynamic functional adaptability to the swarm intelligence model, allowing a distributed network to evolve its capabilities in real-time to meet changing computational demands (’161 Patent, col. 2:9-12).
Key Claims at a Glance
- The complaint asserts independent Claim 37 (Compl. ¶57).
- The essential elements of Claim 37 include:
- A system for dynamically controlling processing resources in a network, comprising a task pool, a primary controller, and a first cell.
- The primary controller populates the task pool with a plurality of tasks, each having a task type.
- The first cell is programmed to process a first task (of a first task type) and send a notification to the task pool upon completion.
- The first cell includes a "first agent" configured to proactively search for and retrieve tasks of its type from the pool.
- A key limitation states: "the first task type comprises a device function reconfiguration task; and the first task comprises a reconfiguration of a device function of the device to perform a second task from the plurality of tasks having a second task type."
- The complaint reserves the right to assert dependent claims 1-36 and 38-44 (Compl. ¶57).
III. The Accused Instrumentality
Product Identification
- The complaint identifies HPE’s cloud computing products and services, with a specific focus on the "HPE Aruba networking products" line, which includes the "Aruba GreenLake Platform" and "Aruba Central" (Compl. ¶¶141-142).
Functionality and Market Context
- The complaint alleges that the accused products provide a cloud-based networking solution for managing network infrastructure, such as access points and switches (Compl. ¶142, Refs. 3, 8). In this system, a central cloud portal (alleged to be the "controller" and/or "task pool") is used to manage and configure numerous distributed network devices (alleged to be the "co-processors"). The complaint alleges that HPE has migrated from a traditional "controller/responder" model to this new distributed architecture, which it contends is the same as that claimed in the patents-in-suit (Compl. ¶13).
IV. Analysis of Infringement Allegations
’275 Patent Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| A collaborative intelligence system, comprising: a task pool; a controller configured to populate the task pool... | HPE's Aruba GreenLake Platform and Aruba Central are alleged to be the "collaborative intelligence system." Aruba Central is alleged to be the "task pool," and HPE's software tools (e.g., mobile apps) that allow users to manage the network are the "controller." | ¶143-145 | col. 14:24-27 |
| a first co-processor configured to successively: proactively retrieve a first task from the task pool... | HPE network devices (e.g., access points) are alleged to be the "co-processors" that automatically and proactively retrieve configuration tasks from the Aruba Central platform. | ¶153-154 | col. 2:19-23 |
| ...all without any communication between the first co-processor and the controller... | The complaint alleges that the Aruba devices retrieve tasks from the central platform without direct communication with the user-operated controller (e.g., the mobile app). | ¶157 | col. 14:32-33 |
| wherein the collaborative intelligence system is configured to dynamically accept the first co-processor... on a plug-and-play basis without any communication with the controller... | The Aruba system allegedly allows new network devices to be added to the network ("plug-and-play") and begin communicating with the Aruba Central platform without direct communication with the end-user's controller device. | ¶159 | col. 3:42-50 |
| the first and second co-processors autonomously work together in solidarity with the task pool to complete the common objective. | The complaint alleges that the various Aruba devices work together autonomously to achieve a common network management objective as defined by user goals in the Aruba Central platform. | ¶161 | col. 2:28-36 |
- Identified Points of Contention:
- Scope Question: A primary issue for the court will be whether the "without any communication between the... co-processor and the controller" limitation is met by HPE’s architecture. The analysis may turn on whether this requires an absolute absence of data exchange or merely the absence of a direct, synchronous command to retrieve a specific task.
- Technical Question: What evidence demonstrates that the accused Aruba network devices "proactively retrieve" tasks, versus the Aruba Central cloud platform pushing configurations and tasks to the devices in a more conventional, centrally managed manner? The distinction between a "pull" and a "push" architecture will be critical.
’161 Patent Infringement Allegations
| Claim Element (from Independent Claim 37) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| A system for dynamically controlling processing resources in a network, the system comprising: a task pool; a primary controller... | The accused HPE Aruba networking products are alleged to be the "system," with Aruba Central as the "task pool" and HPE software tools as the "primary controller." | ¶162-164 | col. 21:14-18 |
| a first cell programmed to... process a first task... send a notification to the task pool... and include a first agent configured to: proactively search within the task pool... | Aruba network devices are alleged to be the "first cell." Their automated configuration retrieval functionality is alleged to be the "first agent" that proactively searches for and processes tasks from Aruba Central. | ¶170, ¶172 | col. 2:16-24 |
| wherein: the first cell is further configured to operate a device; | An Aruba Access Point or switch is alleged to be the "first cell" that operates a network "device." | ¶175 | col. 21:30-31 |
| the first task type comprises a device function reconfiguration task; and the first task comprises a reconfiguration of a device function... to perform a second task... | The complaint alleges that tasks such as firmware updates or new configuration profiles sent from Aruba Central serve as "device function reconfiguration tasks" that enable the network device to perform new functions. | ¶176-177 | col. 21:32-36 |
- Identified Points of Contention:
- Scope Question: The central dispute for this patent will likely concern the meaning of a "device function reconfiguration task." The court will need to determine if a standard firmware update or the application of a new configuration profile, which enables new features on an existing device, meets this definition.
- Technical Question: Does an update to an Aruba device enable it to perform a fundamentally "second task type," or does it merely alter the parameters of the single, pre-existing task type of "network data processing"? The answer may depend on the degree of functional change enabled by the accused tasks.
V. Key Claim Terms for Construction
For the ’275 Patent:
- The Term: "proactively retrieve a first task from the task pool... all without any communication between the first co-processor and the controller"
- Context and Importance: This phrase is the core of the alleged invention, distinguishing it from prior art centralized controllers. The term "without any communication" is an absolute negative limitation, making its construction critical to the infringement analysis. Defendant will likely argue that any data exchange between the device and the central management platform violates this term, while Plaintiff may argue it refers only to the absence of a specific command from the user-operated controller to initiate the task retrieval.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The specification describes the system as one where the CPU "communicates indirectly with the co-processors through the task pool" (’275 Patent, col. 2:25-27), which may support an interpretation that "communication" in the claim means only direct, synchronous command-and-control instructions.
- Evidence for a Narrower Interpretation: The plain language "without any communication" is unambiguous. The specification also states that in some embodiments, co-processors may communicate directly with the CPU, suggesting that when this communication is explicitly excluded by a claim, the exclusion is intended to be complete (’275 Patent, col. 3:5-6).
For the ’161 Patent:
- The Term: "device function reconfiguration task"
- Context and Importance: The infringement case for the ’161 patent hinges on whether routine network management activities, like applying updates or new configurations, qualify as this specific type of task. Practitioners may focus on this term because it appears to require more than a simple parameter change.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The patent describes a wide range of functions that co-processors can perform, from "simple switching and control functions to complex programs and algorithms" (’161 Patent, col. 4:17-21). This could support a reading where adding any new capability, such as a new network protocol via a software update, constitutes a "reconfiguration."
- Evidence for a Narrower Interpretation: The specification discusses configuring a "general-purpose processor... to perform specialized tasks" (’161 Patent, col. 6:11-15). This may support a narrower view that the task must fundamentally change the operational nature of the device (e.g., from a router to a firewall), rather than just enabling a new feature on a multi-function device.
VI. Other Allegations
- Indirect Infringement: The complaint alleges that HPE induces infringement by providing customers with mobile apps, documentation, and marketing materials that instruct them to use the Aruba networking products in a manner that directly infringes the patents (Compl. ¶¶151, 169). It further alleges contributory infringement, asserting that the system components, particularly the controller software, have no substantial non-infringing use when combined in the accused system (Compl. ¶¶150, 168).
- Willful Infringement: The willfulness claim is based on alleged knowledge from two events: (1) pre-suit correspondence in 2019 where Plaintiff allegedly offered to license related patents to HPE, and (2) actual notice of the patents-in-suit via service of the original complaint on January 30, 2025, after which HPE allegedly continued its infringing activities unabated (Compl. ¶¶16, 53, 183, 191).
VII. Analyst’s Conclusion: Key Questions for the Case
- A central issue will be one of operational equivalence: Does HPE's cloud-based architecture, where a central management platform sends configurations to network devices, meet the strict claim requirement of co-processors that "proactively retrieve" tasks "without any communication" with the controller, or is this a fundamentally different, centrally-driven "push" model?
- A key definitional question for the ’161 Patent will be whether a standard software update or new configuration profile in the accused Aruba system constitutes a "device function reconfiguration task" that enables a device to perform a new "task type," or if this is merely a parameter change within the device's pre-existing functional scope.
- An important evidentiary question for damages will be one of pre-suit knowledge: Is the alleged 2019 notice regarding related patents from the same family sufficient to establish that any infringement of the later-issued patents-in-suit was willful from the outset, or can willfulness only be established from the date of actual notice of the asserted patents?