Athena Security LLP v. Google LLC

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: Athena Security, LLP (Nevada)
  • Defendant: Google LLC (Delaware)
  • Plaintiff's Counsel: Russ August & Kabat
• Case Identification: 7:26-cv-00158, W.D. Tex., 07/16/2026
• Venue Allegations: Plaintiff alleges venue is proper in the Western District of Texas because Google maintains an established place of business in the District, has transacted business there, and has committed alleged acts of infringement within the District.
• Core Dispute: Plaintiff alleges that Defendant's cloud networking, data center switching, and security operations products infringe four U.S. patents related to secure network tunneling, network load balancing, remote memory access, and automated security event management.
• Technical Context: The technologies at issue relate to foundational aspects of modern large-scale cloud infrastructure, addressing performance, security, and reliability in data center networks and services.
• Key Procedural History: The complaint does not reference prior litigation or administrative proceedings. However, it extensively cites Google's own technical publications and blog posts, framing them as confirmations of the technological problems addressed by the patents and the non-conventional nature of the solutions, which may be intended to preemptively counter potential invalidity arguments.

Case Timeline

Date	Event
2000-09-13	'357 Patent Priority Date
2005-01-18	'742 Patent Priority Date
2006-08-11	'880 Patent Priority Date
2010-04-20	'742 Patent Issued
2011-06-28	'880 Patent Issued
2012-08-21	'357 Patent Issued
2014-03-17	'421 Patent Priority Date
2016-11-22	'421 Patent Issued
2026-07-16	Complaint Filing Date

II. Technology and Patent(s)-in-Suit Analysis

U.S. Patent No. 8,250,357 - "Tunnel interface for securing traffic over a network"

• Patent Identification: U.S. Patent No. 8,250,357, titled "Tunnel interface for securing traffic over a network," issued on August 21, 2012.

The Invention Explained

• Problem Addressed: The patent describes a performance penalty in conventional Internet Protocol Security (IPSEC) transmissions, where every individual packet must be examined at both the sending and receiving ends to determine if it requires encryption or decryption Compl. ¶11 '357 Patent, col. 4:4-9
• The Patented Solution: The invention proposes a method where the decision to encrypt traffic is offloaded to the network infrastructure itself Compl. ¶12 A routing node within a service provider's network receives data packets and, based on its configuration for a virtual private network, automatically encrypts them before forwarding, without the original packets needing any specific indication that they require encryption '357 Patent, abstract '357 Patent, cl. 1 This centralizes the security function within the provider network.
• Technical Importance: This method aims to improve the performance and efficiency of secure network communications, a critical function for creating Virtual Private Networks (VPNs) in enterprise and cloud environments Compl. ¶12

Key Claims at a Glance

• The complaint asserts independent claim 1 Compl. ¶17
• The essential elements of independent claim 1 include:
  • Establishing first and second routing nodes in first and second processing systems.
  • Establishing an IP connection path between them that involves a service provider network.
  • Receiving a plurality of data packets into the first routing node.
  • Forwarding the packets to a selected service provider router.
  • Encrypting the packets within the service provider router to form encrypted packets, "without regard to any indication regarding encryption" in the received packets.
  • Sending the encrypted packets to the second routing node.
  • Receiving and decrypting the encrypted packets at the second routing node.
  • Sending the decrypted packets to a destination.
• The complaint also asserts dependent claims 2, 3, and 4 Compl. ¶17

U.S. Patent No. 7,969,880 - "Device and method for relaying packets"

• Patent Identification: U.S. Patent No. 7,969,880, titled "Device and method for relaying packets," issued on June 28, 2011.

The Invention Explained

• Problem Addressed: In network systems, particularly where relay devices are directly connected, an imbalance in communication load can occur, which may lead to "appreciable communication load imbalance" and degraded performance Compl. ¶22 '880 Patent, col. 1:30-37 This is often due to hash polarization in multi-stage switch fabrics.
• The Patented Solution: The patent describes a network relay device that includes a "modifying module." This module can alter the "computational expression" (e.g., a hash function) used to determine a packet's path, but does so "without modifying the associations between computation results and output physical ports" '880 Patent, cl. 1 This allows the device to dynamically change its load-balancing behavior to alleviate traffic imbalances without reconfiguring its fundamental port forwarding logic '880 Patent, abstract
• Technical Importance: This technology provides a mechanism for sophisticated, dynamic load balancing in large-scale datacenter networks, which is critical for maintaining high performance and reliability Compl. ¶25

Key Claims at a Glance

• The complaint asserts independent claims 1, 9, 17, and 18 Compl. ¶29
• The essential elements of independent claim 1 (a device claim) include:
  • An interface module with physical ports.
  • A computing module that executes a computing process with a computational expression (e.g., a hash) using seed information from a packet (e.g., source/destination info).
  • A destination search module to select a physical port for transmission based on the computation's result and pre-existing associations between results and ports.
  • A modifying module configured to modify the computational expression without modifying the associations between computation results and output physical ports.
• The complaint also asserts numerous dependent claims Compl. ¶29

U.S. Patent No. 7,702,742 - "Mechanism for enabling memory transactions to be conducted across a lossy network"

• Patent Identification: U.S. Patent No. 7,702,742, titled "Mechanism for enabling memory transactions to be conducted across a lossy network," issued on April 20, 2010.
• Technology Synopsis: The patent addresses the difficulty of implementing remote programmed I/O over standard, "lossy" commodity networks where packets can be dropped Compl. ¶34 '742 Patent, col. 2:13-23 The invention provides a mechanism at the network interface that assigns sending priorities to memory transaction messages (MTMs), encapsulates them, and uses ordering rules to ensure that the remote node receives every message in the proper order, creating a reliable memory transaction layer on top of an unreliable network '742 Patent, abstract Compl. ¶35
• Asserted Claims: Independent claims 1 and 14 are asserted Compl. ¶40
• Accused Features: The complaint accuses Google Cloud instances and related components that deploy Intel Xeon 6 or AMD EPYC processors with CXL 2.0 support, which enable high-speed remote memory access Compl. ¶38

U.S. Patent No. 9,503,421 - "Security information and event management"

• Patent Identification: U.S. Patent No. 9,503,421, titled "Security information and event management," issued on November 22, 2016.
• Technology Synopsis: The patent identifies a need for better coordination among disparate security devices, as their tasks are often independent and results cannot be easily transferred Compl. ¶45 '421 Patent, col. 1:37-46 The invention describes a Security Information and Event Management (SIEM) device that automates complex security management by creating and executing a "work flow," which is a defined sequence of tasks scheduled across one or more security devices to protect a network, with the SIEM device collecting the results '421 Patent, abstract Compl. ¶46
• Asserted Claims: Independent claims 1 and 15 are asserted Compl. ¶51
• Accused Features: The complaint targets Google Security Operations (SecOps), particularly its "playbooks" feature, which is alleged to be an automation process that executes a series of actions to respond to security alerts (Compl. ¶¶47; Compl. ¶49).

III. The Accused Instrumentality

Product Identification

The complaint names four distinct categories of accused instrumentalities:

1. Google Cloud VPN: This includes related services such as High Availability (HA) VPN, Cloud VPN gateways, tunnels, and Cloud Router Compl. ¶15
2. Google Jupiter Datacenter Switches: This includes Google's internal datacenter network fabric and associated packet-switching components and control software Compl. ¶27
3. Google Cloud CXL Instances: This includes Google Cloud instances and components that use Intel Xeon 6 and AMD EPYC processors with Compute Express Link (CXL) 2.0 support, such as C4, C4D, N4D, and H4D instances Compl. ¶38
4. Google Security Operations (SecOps): This includes the Google SecOps SIEM and SOAR platforms, with a focus on the "playbooks" feature Compl. ¶49

Functionality and Market Context

• The complaint alleges these products are central to Google's cloud and internal infrastructure. The Cloud VPN products are alleged to provide secure networking for customers Compl. ¶¶15-16 The Jupiter switches are alleged to form the backbone of Google's massive-scale data centers Compl. ¶25 The CXL-enabled instances are alleged to provide customers with cutting-edge, high-performance computing capabilities for remote memory access Compl. ¶38 The SecOps platform is alleged to provide customers with automated security orchestration and response capabilities Compl. ¶47
• The complaint repeatedly cites Google's own marketing and technical documents to assert the commercial and technical importance of these functionalities, for example, noting Google's claims that its hashing functionality supports "good ECMP load balancing" Compl. ¶25 and that its SecOps playbooks can "orchestrate hundreds of tools" Compl. ¶47
• A diagram from the complaint's Exhibit 6 shows a "Flex Bus Port Example," illustrating how a CPU can use a flexible port to connect to either a PCIe or a CXL device, which is central to the infringement allegations against the '742 patent Compl., Ex. 6, p. 9

IV. Analysis of Infringement Allegations

'357 Patent Infringement Allegations

Claim Element (from Independent Claim 1)	Alleged Infringing Functionality	Complaint Citation	Patent Citation
establishing a first routing node within a first processing system	Google Cloud VPN establishes a first routing node, such as an HA VPN gateway or a Cloud Router, within a first VPC network (processing system).	¶17; Ex. 2, p. 3	col. 5:10-21
establishing a second routing node within a second processing system	Google Cloud VPN establishes a second HA VPN gateway in a second VPC network.	¶17; Ex. 2, p. 4	col. 5:22-26
establishing an internet protocol (IP) connection communications path between the first processing system and the second processing system that includes the first routing node and the second routing node	An IP connection is established between the two VPC networks, which includes the respective HA VPN gateways. A diagram in the complaint illustrates this topology.	¶17; Ex. 2, p. 5	col. 5:27-35
encrypting the received plurality of data packets to form encrypted packets within the selected service provider router, without regard to any indication regarding encryption in the received plurality of data packets	Route-based IPsec VPN tunnels in Google Cloud VPN encrypt all traffic forwarded to them by the Cloud Router, regardless of any encryption indication in the original packets.	¶17; Ex. 2, p. 19	col. 8:1-12
decrypting the received encrypted packets...to form decrypted packets	The second HA VPN gateway receives the encrypted packets and decrypts them to form the original data packets.	¶17; Ex. 2, p. 27	col. 8:13-17
sending the decrypted packets to a destination in the second processing system	The decrypted packets are routed to their final destination within the second VPC network.	¶17; Ex. 2, p. 30	col. 8:18-20

• Identified Points of Contention:
  • Scope Question: A potential point of contention is whether Google's distributed architecture, comprising customer-configured VPCs, Cloud Routers, and HA VPN gateways, constitutes a "service provider network" with a "service provider router" as contemplated by the patent. The patent's figures and description suggest a more centralized hardware platform managed by an Internet Service Provider (ISP) '357 Patent, Fig. 1 The litigation may explore whether a cloud provider's infrastructure-as-a-service offering fits within this definitional scope.
  • Technical Question: The complaint alleges that a Cloud Router forwards packets to a selected service provider router where they are encrypted Compl., Ex. 2, pp. 15-19 A question may arise as to whether the Cloud Router and the HA VPN gateway (which performs encryption) are distinct components or a single functional "router" under the patent's claims.

'880 Patent Infringement Allegations

Claim Element (from Independent Claim 1)	Alleged Infringing Functionality	Complaint Citation	Patent Citation
an interface module including a plurality of physical ports for connection to lines	The accused Jupiter switches include interface modules with multiple physical ports for connecting to other switches or servers.	¶29; Ex. 4, p. 5	col. 4:2-4
a computing module configured to execute a computing process with a computational expression using seed information...associated with a received packet	Google's Jupiter switches use ECMP/WCMP hashing, a computational process that uses packet header fields (e.g., source/destination IP and port) as seed information to determine the packet's path.	¶29; Ex. 4, p. 12	col. 1:43-52
a destination search module configured to...select a physical port for transmission...from a plurality of candidate ports	Based on the hash result, the switch's destination search module selects an egress port from an ECMP group of candidate ports.	¶29; Ex. 4, p. 17	col. 2:10-18
a modifying module configured to modify the computational expression without modifying the associations between computation results and output physical ports	The complaint alleges Google employs a "color recombining" technique, managed by its Orion SDN control plane, which modifies the hash functions used at different stages to de-correlate traffic, thereby modifying the overall computational expression without changing the port forwarding tables.	¶29; Ex. 4, p. 24	col. 2:14-18

• Identified Points of Contention:
  • Technical Question: The central dispute may focus on the "modifying module" limitation. The complaint alleges Google's "color-recombining" technique, where different hash functions are used at different stages of the network fabric, meets this element (Compl., Ex. 4, pp. 24-31). The defense may argue that this technique does not "modify the computational expression" itself but rather selects from a set of static expressions, or that it effectively does modify the "associations" between a given input and the final output port, thus falling outside the claim scope.
  • Scope Question: The claim recites a "modifying module." A question for construction will be whether this requires a discrete hardware or software component within a single relay device, or if it can be read on a distributed, software-defined network controller (like Google's Orion) that provides instructions to a fleet of switches, as alleged by the complaint (Compl., Ex. 4, p. 42).

V. Key Claim Terms for Construction

For U.S. Patent No. 8,250,357

• The Term: "service provider router"
• Context and Importance: This term is critical because the key claim step of "encrypting" the data packets must occur "within the selected service provider router" (Claim 1). The infringement case depends on whether Google's accused architecture, which includes Cloud Routers and HA VPN gateways within a customer's virtual network, can be characterized as a "service provider router."
• Intrinsic Evidence for Interpretation:
  • Evidence for a Broader Interpretation: The patent's abstract describes a "flexible, scalable hardware and software platform that allows a service provider to easily provide internet services." This language suggests the term is not limited to a single physical box and could encompass a distributed cloud-based system that functionally acts as a router for a service provider.
  • Evidence for a Narrower Interpretation: Figure 4 of the patent depicts the service provider network as containing discrete "IPSX 9000" hardware units within a "Service Provider Network" cloud, separate from the "Subscriber" sites '357 Patent, Fig. 4 This could support an interpretation that a "service provider router" is a specific piece of hardware owned and operated by the service provider, distinct from customer-managed resources like a VPC.

For U.S. Patent No. 7,969,880

• The Term: "modifying the computational expression without modifying the associations between computation results and output physical ports"
• Context and Importance: This term defines the core technical novelty. The infringement theory hinges on equating Google's alleged "color-recombining" and hash de-correlation techniques with this claim language. The outcome of the case may depend on whether changing which hash function is applied at a given stage is considered "modifying the computational expression" while leaving the underlying port-mapping "associations" intact.
• Intrinsic Evidence for Interpretation:
  • Evidence for a Broader Interpretation: The patent's stated object is to "provide a technology capable of alleviating communication load imbalance" '880 Patent, col. 1:41-42 This purpose-driven language may support a broader construction that covers any method of altering the hashing logic to redistribute traffic, as long as the direct mapping from a given hash result to a port is unchanged.
  • Evidence for a Narrower Interpretation: The claim recites a "modifying module" that performs this action, and the abstract refers to a "computational expression [that] is capable of modification." This could be interpreted to require a single, modifiable hash function or algorithm within one device, rather than a system-level technique of selecting different, static hash functions across multiple devices or stages, as alleged in the complaint's analysis of Google's network Compl. ¶24 Compl. Ex. 4, pp. 28-31 A diagram in the complaint shows how Google allegedly employs different hash functions at different stages, which will be a key point of analysis Compl., Ex. 4, p. 32

VI. Other Allegations

• Indirect Infringement: The complaint alleges induced infringement for all four asserted patents. The basis for these allegations is that Google publishes extensive documentation, tutorials, and marketing materials that actively encourage and instruct customers to configure and use the accused products in an infringing manner, such as creating HA VPN tunnels, deploying CXL-enabled instances, or building security automation playbooks Compl. ¶16 Compl. ¶28 Compl. ¶39 Compl. ¶50
• Willful Infringement: The complaint alleges that Google has knowledge of the asserted patents "Through at least the filing and service of this Complaint" for each of the four counts Compl. ¶16 Compl. ¶28 Compl. ¶39 Compl. ¶50 These allegations appear to support a claim for post-suit willfulness but do not allege pre-suit knowledge of the patents.

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

1. Definitional Scope: A central question across all four patents will be whether the language of the claims, drafted in an era of more discrete hardware, can be construed to read on Google's modern, distributed, software-defined cloud architecture. This will involve construing terms like "service provider router" ('357 Patent), "network relay device" ('880 Patent), "network interface" ('742 Patent), and "SIEM device" ('421 Patent) and determining if they encompass Google's disaggregated and virtualized systems.

2. Functional Mismatch: For the '880 patent concerning load balancing, a key technical issue will be whether Google's alleged "color-recombining" technique-which involves using different hash functions at different network stages-functionally meets the claim requirement of "modifying the computational expression without modifying the associations between computation results and output physical ports." The case may turn on the distinction between modifying a single algorithm versus selecting from among multiple different algorithms.

3. Evidentiary Weight of Self-Citation: A significant strategic element of the case will be the plaintiff's heavy reliance on Google's own technical papers and blog posts. A key question will be how the court treats these documents-whether they will be viewed as admissions that the problems solved by the patents were significant and non-obvious, thereby strengthening the patents against potential invalidity challenges, or as merely contextual background.