7:26-cv-00061
Athena Security LLP v. Amazon.com Inc
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: Athena Security, LLP (Nevada)
- Defendant: Amazon.com, Inc.; Amazon.com Services LLC; Amazon Web Services, Inc. (Delaware)
- Plaintiff's Counsel: Russ August & Kabat
- Case Identification: 7:26-cv-00061, W.D. Tex., 02/20/2026
- Venue Allegations: Venue is alleged to be proper based on Defendant Amazon having a regular and established place of business in the district, specifically an Amazon Tech Hub located in Austin, Texas.
- Core Dispute: Plaintiff alleges that Defendant's cloud computing products and services, including components of Amazon Web Services (AWS), infringe four U.S. patents related to security event management, network memory transactions, secure network tunneling, and policy-based content filtering.
- Technical Context: The technologies at issue cover fundamental aspects of modern cloud infrastructure, including automated security response, high-speed data center interconnects, virtual private networking, and network firewalls.
- Key Procedural History: The complaint does not reference any prior litigation, Inter Partes Review (IPR) proceedings, or licensing history related to the Asserted Patents.
Case Timeline
| Date | Event |
|---|---|
| 2000-09-13 | Priority Date for U.S. Patent No. 8,250,357 |
| 2005-01-18 | Priority Date for U.S. Patent No. 7,702,742 |
| 2005-11-22 | Priority Date for U.S. Patent No. 7,966,654 |
| 2010-04-20 | U.S. Patent No. 7,702,742 Issues |
| 2011-06-21 | U.S. Patent No. 7,966,654 Issues |
| 2012-08-21 | U.S. Patent No. 8,250,357 Issues |
| 2013-11-26 | Priority Date for U.S. Patent No. 9,503,421 |
| 2016-11-22 | U.S. Patent No. 9,503,421 Issues |
| 2026-02-20 | Complaint Filed |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 9,503,421 - "Security information and event management" (issued Nov. 22, 2016)
The Invention Explained
- Problem Addressed: The patent addresses the challenge of managing and coordinating tasks across multiple, independent security devices within a computer network to automatically achieve a comprehensive security management objective U.S. Patent No. 9,503,421, col. 1:15-46
- The Patented Solution: The invention proposes a central Security Information and Event Management (SIEM) device that creates a "work flow." This work flow defines a series of security tasks to be performed by one or more security devices on the network. The SIEM device initiates the work flow by scheduling the tasks, and then collects the results from the devices, thereby orchestrating a complex, automated security function U.S. Patent No. 9,503,421, abstract U.S. Patent No. 9,503,421, col. 2:49-55
- Technical Importance: This approach provides a framework for automating and orchestrating security responses across disparate systems, moving beyond simple event logging to proactive, workflow-based security management U.S. Patent No. 9,503,421, col. 2:41-46
Key Claims at a Glance
- Independent claim 1 is asserted in the complaint Compl. ¶13 Compl. Ex. 2
- Essential elements of claim 1 include:
- Creating, by a SIEM device, a work flow that defines a plurality of security tasks to be performed by other security devices to protect a private network.
- Starting the work flow by scheduling the security devices to perform the defined tasks.
- Collecting the results of the performed tasks by the SIEM device.
- The complaint does not explicitly reserve the right to assert dependent claims for the '421 Patent.
U.S. Patent No. 7,702,742 - "Mechanism for enabling memory transactions to be conducted across a lossy network" (issued Apr. 20, 2010)
The Invention Explained
- Problem Addressed: The patent describes that standard commodity networks, such as Ethernet, are "lossy" because they can drop packets and do not guarantee the order of delivery. This makes them unsuitable for remote "programmed I/O" (direct memory access), where a processor expects its memory transaction messages (MTMs) to be processed reliably and in an order consistent with the processor bus protocol U.S. Patent No. 7,702,742, col. 2:5-24
- The Patented Solution: The invention is a network interface that translates MTMs from a local processor bus into network packets for transmission over a lossy network. The interface assigns sending priorities to the packets based on the original MTM's transaction type (e.g., read, write, response) and organizes them into groups based on this priority. It then employs a mechanism, such as a linked-list of sent packets and acknowledgements, to ensure the packets are received by the remote node in the proper sequence, resending packets if necessary U.S. Patent No. 7,702,742, abstract U.S. Patent No. 7,702,742, col. 3:1-4 This system effectively creates a reliable, ordered memory channel over an unreliable network.
- Technical Importance: This technology allows for the disaggregation of memory from processors using standard, cost-effective networking hardware, a key concept in modern data center architecture that was previously reliant on expensive, proprietary, and non-lossy interconnects U.S. Patent No. 7,702,742, col. 2:13-24
Key Claims at a Glance
- Independent claim 1 is asserted in the complaint Compl. ¶20 Compl. Ex. 4
- Essential elements of claim 1 include:
- Receiving a plurality of MTMs conforming to a processor bus protocol.
- Determining the MTMs are destined for a remote node.
- Determining a transaction type for each MTM.
- Composing a network packet to encapsulate the MTM.
- Assigning a sending priority based on the transaction type.
- Organizing network packets into groups based on priority.
- Sending the packets into a lossy network in an order based on priority.
- Ensuring the packets are received by the remote node in a proper sequence.
- The complaint does not explicitly reserve the right to assert dependent claims for the '742 Patent.
U.S. Patent No. 8,250,357 - "Tunnel interface for securing traffic over a network" (issued Aug. 21, 2012)
- Technology Synopsis: The patent describes a method for delivering security services by establishing a secure connection (a "tunnel") over an IP connection between two different processing systems U.S. Patent No. 8,250,357, abstract The method involves establishing routing nodes in each system, connecting them to service provider routers, and configuring those routers to implement a virtual private network (VPN) between them, which involves encrypting, sending, receiving, and decrypting data packets U.S. Patent No. 8,250,357, claim 1
- Asserted Claims: Independent claim 1 is asserted Compl. ¶27 Compl. Ex. 6
- Accused Features: The complaint accuses AWS Site-to-Site VPN of infringement Compl. ¶25
U.S. Patent No. 7,966,654 - "Computerized system and method for policy-based content filtering" (issued Jun. 21, 2011)
- Technology Synopsis: The patent discloses a firewall system that processes network traffic based on defined policies U.S. Patent No. 7,966,654, abstract When an incoming connection is allowed by packet-layer firewall rules, a networking subsystem redirects it to a proxy module. This proxy retrieves a "content processing configuration scheme" associated with the matching firewall policy and uses it to process the application-level content of the packet stream, which involves reconstructing the stream and scanning it U.S. Patent No. 7,966,654, claim 13
- Asserted Claims: Independent claim 13 is asserted Compl. ¶34 Compl. Ex. 8
- Accused Features: The complaint accuses AWS Network Firewall and its related components of infringement Compl. ¶32
III. The Accused Instrumentality
- Product Identification: The accused instrumentalities are a suite of products within the Amazon Web Services (AWS) ecosystem Compl. ¶11 Compl. ¶18 Compl. ¶25 Compl. ¶32 For the '421 Patent, the products are AWS Security Hub and its related components, such as System Manager Automation and EventBridge Compl. ¶11 For the '742 Patent, they are AWS R8i/R8i-flex EC2 instances and platforms using Intel Xeon 6 processors with CXL 2.0 support Compl. ¶18 For the '357 and '654 Patents, the accused products are AWS Site-to-Site VPN and AWS Network Firewall, respectively Compl. ¶25 Compl. ¶32
- Functionality and Market Context:
- The complaint alleges that AWS Security Hub acts as a central hub for security findings, using Amazon EventBridge to create rules that define and trigger automated actions, or workflows, in response to those findings Compl. Ex. 2, p. 3 An architecture diagram in the complaint illustrates this as an "Automated Security Response on AWS architecture" Compl. Ex. 2, p. 6 These services are central to AWS's cloud security posture management offerings.
- The complaint alleges that AWS R8i EC2 instances utilize the Compute Express Link (CXL) 2.0 protocol to enable high-speed, coherent memory access between processors and remote memory devices over a PCIe physical layer Compl. Ex. 4, p. 2 Compl. Ex. 4, p. 7 A diagram provided in the complaint shows the CXL ARB/MUX layer, which is alleged to manage the multiplexing of memory transaction data Compl. Ex. 4, p. 9 This technology is critical for high-performance and memory-intensive computing workloads in the cloud.
IV. Analysis of Infringement Allegations
U.S. Patent No. 9,503,421 Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| A method comprising: creating, by a security information and event management (SIEM) device associated with a private network, a work flow... | AWS Security Hub and related components create a work flow. The complaint alleges that creating rules in Amazon EventBridge to respond automatically to Security Hub findings constitutes creating the claimed "work flow." | ¶13 | col. 8:58-67 |
| said work flow including information defining a plurality of security tasks that are to be performed by one or more security devices... | The work flow allegedly defines security tasks, such as invoking AWS Lambda functions or Amazon EC2 run commands, which are described as "automated actions" and "remediation workflows." | ¶13 | col. 8:58-67 |
| starting, by the SIEM device, the work flow by scheduling the one or more security devices to perform the plurality of security tasks defined in the work flow... | The accused system allegedly starts the work flow by using EventBridge rules to automatically trigger "runbooks" or other actions when a security event occurs. | ¶13 | col. 9:1-5 |
| collecting, by the SIEM device, results of the plurality of security tasks after they are performed by the one or more security devices. | After a remediation task is performed, the system allegedly updates the finding in AWS Security Hub with a note indicating successful remediation, which is alleged to be the "collecting" of results. | ¶13 | col. 9:6-9 |
- Identified Points of Contention:
- Scope Questions: A primary point of contention may be whether the combination of AWS Security Hub and its related components constitutes a "security information and event management (SIEM) device" as required by the claim. The complaint itself includes an AWS document stating that "Although Security Hub has some similarities to... (SIEM) tools, it is not designed as standalone a SIEM replacement" Compl. Ex. 2, p. 2 This raises the question of whether a disaggregated set of cloud services that collectively perform SIEM-like functions falls within the scope of the claimed "SIEM device."
U.S. Patent No. 7,702,742 Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| receiving, by a network interface of a computer system, a plurality of memory transaction messages (MTMs) from a local memory controller... | The accused AWS instances, which use Intel Xeon 6 processors with CXL 2.0, receive CXL.mem transaction messages from the processor's memory controller. The CXL.mem protocol defines M2S (Master to Subordinate) messages, which are alleged to be MTMs. | ¶20 | col. 6:46-55 |
| determining, by the network interface, that the plurality of MTMs are destined for a particular remote node; | The accused system's network interface, implementing the CXL protocol, uses HDM (Host-managed Device Memory) Decoders to look up the incoming address in a CXL.mem transaction and forward it to the appropriate remote port or device. | ¶20 | col. 6:56-58 |
| determining, by the network interface, for each MTM... a transaction type; | The network interface determines the transaction type by reading the "MemOpcode" field within the CXL.mem message, which specifies operations such as memory write (MemWr) or memory read (MemRd). | ¶20 | col. 6:59-61 |
| composing, by the network interface, for each MTM... a network packet... | The CXL.mem protocol encapsulates the MTM information into a fixed-size 528-bit network packet known as a "flit," which includes a header slot and generic slots for message data. | ¶20 | col. 6:62-67 |
| assigning... one of a plurality of sending priorities... | The CXL protocol's ARB/MUX component arbitrates between different request types (e.g., CXL.io vs. CXL.cache/mem) using programmable weighted round-robin arbitration, which is alleged to constitute assigning sending priorities. | ¶20 | col. 7:1-9 |
| sending, by the network interface, the network packets into a lossy network... in an order determined... upon the sending priorities... | The ARB/MUX multiplexes the data based on the arbitration results (priorities) and sends the flits over the physical link, which is alleged to be a "lossy network" that relies on a link-layer retry protocol for reliability. | ¶20 | col. 7:13-19 |
| ensuring... that a particular subset of the network packets... are received by the particular remote node in a proper sequence. | The CXL protocol implements a Link Layer Retry (LLR) mechanism with sequence numbers and error detection (CRC) to handle transmission errors and ensure flits are received correctly and in order, which is alleged to be the "ensuring" step. | ¶20 | col. 7:20-24 |
- Identified Points of Contention:
- Technical Questions: A key technical question will be whether the CXL 2.0 protocol, operating over a high-speed PCIe physical layer, constitutes a "lossy network" as that term is used in the patent. The patent's background focuses on switched networks like Ethernet U.S. Patent No. 7,702,742, col. 2:5-12 The analysis may turn on whether the CXL protocol's need for a Link Layer Retry mechanism for error correction inherently proves the underlying network is "lossy" within the patent's meaning.
- Scope Questions: The patent describes assigning priorities based on transaction types like "posted request" and "response." The analysis will question whether the CXL ARB/MUX's weighted arbitration between different protocols (e.g., CXL.io vs. CXL.mem) is functionally equivalent to the priority assignment among different transaction types within a single memory protocol as claimed.
V. Key Claim Terms for Construction
From U.S. Patent No. 9,503,421
- The Term: "security information and event management (SIEM) device"
- Context and Importance: The infringement allegation hinges on whether AWS Security Hub, in combination with other AWS services, meets the definition of a "SIEM device." As Amazon's own documentation cited in the complaint distinguishes its product from a "standalone SIEM replacement" Compl. Ex. 2, p. 2, the construction of this term will be central to the dispute.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The body of claim 1 itself provides a functional definition: a device that creates a "work flow," "start[s]" the work flow by scheduling security devices, and "collect[s]" the results U.S. Patent No. 9,503,421, claim 1 Plaintiff may argue that any system performing these three functions, regardless of its commercial name or whether it is a single appliance or a collection of services, is a "SIEM device" within the meaning of the claim.
- Evidence for a Narrower Interpretation: The patent's title and background consistently use the term "Security Information and Event Management" U.S. Patent No. 9,503,421, title U.S. Patent No. 9,503,421, col. 1:19-20 Defendant may argue this term had a well-understood meaning in the art at the time of invention, referring to a more monolithic system, and that the specification's description of "an SIEM device" U.S. Patent No. 9,503,421, col. 2:30 implies a singular entity, not a disaggregated collection of microservices.
From U.S. Patent No. 7,702,742
- The Term: "lossy network"
- Context and Importance: The patent's stated purpose is to enable memory transactions over a "lossy" network U.S. Patent No. 7,702,742, abstract The accused technology, CXL, operates over a PCIe physical interface. Whether this specific, high-speed, point-to-point interconnect qualifies as a "lossy network" will be a critical question of technical scope.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The specification defines "lossy" as a network in which "one or more packets may be dropped" and that "does not guarantee that packets sent in a particular order... will arrive at a destination in that order" U.S. Patent No. 7,702,742, col. 3:65-4:2 Plaintiff may argue that any physical transport that requires a protocol-level reliability mechanism (like CXL's Link Layer Retry) to overcome potential bit errors or other transmission failures fits this functional definition.
- Evidence for a Narrower Interpretation: The background section explicitly uses Ethernet as the primary example of a lossy network, contrasting it with proprietary, non-lossy networks like "SCI and DEC memory channel" U.S. Patent No. 7,702,742, col. 2:5-16 Defendant may argue that "lossy network" should be construed in the context of a switched, multi-device network like Ethernet, and not a dedicated, point-to-point physical interconnect like PCIe, which represents a different class of technology.
VI. Other Allegations
- Indirect Infringement: The complaint alleges induced infringement for all four asserted patents. The factual basis alleged is that Amazon encourages and instructs customers and end users to use the accused products in infringing ways through materials such as "user manuals and online instruction materials on its website" Compl. ¶12 Compl. ¶19 Compl. ¶26 Compl. ¶33
- Willful Infringement: The complaint does not contain an explicit count for willful infringement. It alleges that Defendants have had knowledge of the asserted patents "[t]hrough at least the filing and service of this Complaint" Compl. ¶12 Compl. ¶19 Compl. ¶26 Compl. ¶33 This allegation may form the basis for a claim of post-filing willfulness but does not allege pre-suit knowledge.
VII. Analyst's Conclusion: Key Questions for the Case
This case presents several fundamental questions at the intersection of patent law and the evolution of cloud computing architecture. The outcome will likely depend on the court's resolution of these key issues:
A question of definitional scope: Can the term "SIEM device," as described in a 2013-priority patent, be construed to cover a modern, disaggregated set of cloud services that collectively perform SIEM functions, particularly when the accused infringer's own documentation draws a distinction between its service and a traditional SIEM?
A question of technological translation: Does a 2005-priority patent directed at enabling memory transactions over general-purpose "lossy networks" like Ethernet read on the highly specific, modern CXL 2.0-over-PCIe protocol used for data center disaggregation? The case may turn on whether the fundamental technical principles are the same, despite the vast difference in implementation and context.
A question of portfolio strategy: The plaintiff is asserting four technologically distinct patents against four different sets of AWS products. A key issue will be whether these parallel infringement theories can be litigated efficiently as a single case or if the technical and factual distinctions will necessitate narrowing the scope of the suit or bifurcating the claims for trial.