Jenam Tech LLC v. Google LLC

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: Jenam Tech, LLC (Texas)
  • Defendant: Google LLC (Delaware)
  • Plaintiff's Counsel: Devlin Law Firm LLC
• Case Identification: 4:21-cv-07994, N.D. Cal., 01/28/2022
• Venue Allegations: Venue is alleged to be proper in the Northern District of California because Google maintains an established place of business within the judicial district.
• Core Dispute: Plaintiff alleges that Defendant's websites, software, and hardware products, which utilize the QUIC network protocol, infringe a portfolio of nine U.S. patents related to detecting and managing idle network connections.
• Technical Context: The technology addresses methods for efficiently managing network resources by detecting when a Transmission Control Protocol (TCP) connection, or a variant thereof, is idle and modifying its timeout attributes accordingly.
• Key Procedural History: The action is a consolidated lead case, suggesting the combination of multiple previously filed lawsuits. Several of the patents-in-suit have been the subject of Inter Partes Review (IPR) proceedings before the U.S. Patent and Trademark Office. Notably, these proceedings resulted in the cancellation or disclaimer of numerous claims across the asserted patent family, including claims in the lead '945 and '564 patents. However, the specific claims asserted in this complaint-Claim 104 of the '945 patent and Claim 1 of the '564 patent-were not among those cancelled. The outcomes of these IPRs may inform the court's analysis of the validity and scope of the surviving claims.

Case Timeline

Date	Event
2010-02-27	Earliest Priority Date ('945, '564, '565, '215, '026, '995, '996 Patents)
2017-09-03	Application filing date for '995 and '996 Patents
2018-03-07	Application filing date for '945, '564, and '565 Patents
2018-03-20	Issue Date, '995 Patent; Issue Date, '996 Patent
2018-09-04	Issue Date, '945 Patent
2018-09-11	Issue Date, '564 Patent; Issue Date, '565 Patent
2018-07-19	Application filing date for '215 and '026 Patents
2019-03-28	Application filing date for '774 Patent
2019-04-03	Alleged date of Defendant's knowledge of '995 and '996 Patents
2019-05-28	Issue Date, '026 Patent
2019-08-06	Issue Date, '215 Patent
2020-08-11	Issue Date, '774 Patent; Alleged date of Defendant's knowledge of '774 Patent
2020-10-23	Application filing date for '742 Patent
2021-03-16	Issue Date, '742 Patent
2021-03-17	Alleged date of Defendant's knowledge of '742 Patent
2022-01-28	Complaint Filing Date

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

U.S. Patent No. 10,069,945 - "Methods, Systems, and Computer Program Products for Sharing Information for Detecting an Idle TCP Connection"

The Invention Explained

• Problem Addressed: The patent background describes the inefficiency and unreliability of the standard TCP "keep-alive" option for managing network connections Compl., Ex. A, col. 1:43-2:28 Because nodes in a TCP connection do not cooperate in managing idleness, resources can be wasted, or connections can be prematurely terminated by network intermediaries like firewalls Compl., Ex. A, col. 2:1-14
• The Patented Solution: The invention proposes a method where nodes in a connection can share information to cooperatively detect and manage idleness Compl., Ex. A, abstract A server provides a client with code that allows the client to operate using a secondary protocol, separate from TCP, which includes receiving a packet with an "idle time period parameter" Compl., Ex. A, col. 3:40-52 Based on metadata in this parameter, the client can create or modify a timeout attribute for the connection, preventing it from being unnecessarily dropped Compl., Ex. A, abstract The process is illustrated in the patent's message flow diagram Compl., Ex. A, Fig. 7
• Technical Importance: The technology purports to offer a more robust and cooperative mechanism for managing idle network connections than the conventional, often problematic, TCP keep-alive function.

Key Claims at a Glance

• The complaint asserts independent claim 104 Compl. ¶41
• Claim 104, a method claim, requires the following essential elements:
  • Providing access to a server computer operating a network application in accordance with a first protocol (TCP).
  • The server computer is configured to set up a TCP connection with a client computer.
  • Causing first data to be communicated from the server to the client via the TCP connection.
  • Permitting second data to be received at the server from the client via the TCP connection.
  • Providing access to code that results in the client operating in accordance with a second, different protocol to set up a second protocol connection with another server.
  • This operation involves receiving idle information, generating a second protocol packet with an idle time period parameter, and sending that packet to the other server to determine a timeout attribute.

U.S. Patent No. 10,075,564 - "Methods, Systems, and Computer Program Products for Sharing Information for Detecting an Idle TCP Connection"

The Invention Explained

• Problem Addressed: Similar to the '945 patent, the '564 patent addresses the lack of a cooperative mechanism in TCP for detecting and managing idle connections, which can lead to wasted network bandwidth or premature connection termination Compl., Ex. B, col. 1:53-2:26
• The Patented Solution: The '564 patent claims a non-transitory computer-readable medium containing code for use by a client node. This code causes the client to receive a "TCP-variant packet" from a server, detect an "idle time period parameter field" within it, and identify metadata from that field Compl., Ex. B, abstract Based on this metadata, the client modifies a timeout attribute associated with the "TCP-variant connection" to keep it active, even when no other packets are being communicated Compl., Ex. B, col. 3:1-5:6
• Technical Importance: This approach places the logic for managing idle connections on the client side, enabled by information sent from the server, to create a more efficient connection management system.

Key Claims at a Glance

• The complaint asserts independent claim 1 Compl. ¶47
• Claim 1, a computer-readable medium claim, requires code that causes a client node to perform the following essential steps:
  • Receive, from a server node, a TCP-variant packet.
  • Detect an idle time period parameter field in that packet.
  • Identify metadata in that field for an idle time period during which no packet is communicated to keep the connection active.
  • Modify, based on the metadata, a timeout attribute associated with the TCP-variant connection.

U.S. Patent No. 10,075,565

• Patent Identification: U.S. Patent No. 10,075,565, issued September 11, 2018.
• Technology Synopsis: This patent claims an apparatus (a server computer) configured to establish a standard TCP connection and then communicate code to a client computer. This code enables the client to operate using a separate, second protocol to manage idle connection timeouts with another server Compl., Ex. C, abstract
• Asserted Claims: Independent claim 1 is asserted Compl. ¶53
• Accused Features: The accused features are Google's servers and their use of the QUIC protocol, which is alleged to be the "second protocol" separate from TCP Compl. ¶52 Compl. Ex. J

U.S. Patent No. 10,375,215

• Patent Identification: U.S. Patent No. 10,375,215, issued August 6, 2019.
• Technology Synopsis: This patent claims a computer-implemented method where a server node provides a client with code. This code causes the client to receive a "TCP-variant packet," detect an "idle time period parameter field," and determine a timeout attribute based on the metadata within that field Compl., Ex. D, abstract
• Asserted Claims: Independent claim 1 is asserted Compl. ¶59
• Accused Features: The accused features involve Google's servers providing access to code (e.g., in HTML pages) that causes client devices to use the QUIC protocol to manage connection timeouts Compl. ¶58 Compl. Ex. K

U.S. Patent No. 10,306,026

• Patent Identification: U.S. Patent No. 10,306,026, issued May 28, 2019.
• Technology Synopsis: This patent claims a method performed at a node that receives a "TCP-variant packet," detects an "idle time period parameter field," identifies metadata, and modifies a timeout attribute for the connection. The technology is substantially similar to that of the '564 patent Compl., Ex. E, abstract
• Asserted Claims: Independent claim 1 is asserted Compl. ¶65
• Accused Features: The accused features are Google's instrumentalities and software (including Android) that allegedly use the QUIC protocol to perform the claimed method steps for managing idle connections Compl. ¶64 Compl. Ex. L

U.S. Patent No. 9,923,995

• Patent Identification: U.S. Patent No. 9,923,995, issued March 20, 2018.
• Technology Synopsis: This patent claims an apparatus (e.g., a server) that operates a network application using a non-TCP protocol that sits above the IP layer and below the HTTP layer. The apparatus is configured to receive, generate, and send non-TCP packets containing "idle information" to establish a connection and determine a timeout attribute Compl., Ex. F, abstract
• Asserted Claims: Independent claim 29 is asserted Compl. ¶71
• Accused Features: The accused features are Google's servers and software that use the QUIC protocol, which is alleged to be the claimed "non-TCP protocol," to negotiate and manage connection timeouts Compl. ¶70 Compl. Ex. M

U.S. Patent No. 9,923,996

• Patent Identification: U.S. Patent No. 9,923,996, issued March 20, 2018.
• Technology Synopsis: This patent claims an apparatus that establishes a standard TCP connection and is also configured to operate with a second, separate protocol (e.g., QUIC). For this second protocol, it receives packets, detects an idle time parameter, and modifies a timeout attribute for the connection Compl., Ex. G, abstract
• Asserted Claims: Independent claim 1 is asserted Compl. ¶77
• Accused Features: The accused features are Google's instrumentalities that allegedly perform a standard TCP handshake and also operate using the QUIC protocol to manage idle connections as claimed Compl. ¶76 Compl. Ex. N

U.S. Patent No. 10,742,774

• Patent Identification: U.S. Patent No. 10,742,774, issued August 11, 2020.
• Technology Synopsis: This patent claims an apparatus with instructions for receiving a "TCP-variant packet," identifying metadata in a "time period parameter field," and calculating a timeout attribute to at least partially close the connection. The technology is substantially similar to other patents in the family Compl., Ex. O, abstract
• Asserted Claims: Dependent claim 2 is asserted Compl. ¶83
• Accused Features: The accused features are Google's instrumentalities, software, and products that allegedly use the QUIC protocol to perform the functions recited in the claims Compl. ¶82 Compl. Ex. P

U.S. Patent No. 10,951,742

• Patent Identification: U.S. Patent No. 10,951,742, issued March 16, 2021.
• Technology Synopsis: This patent is directed to a computer-implemented method for sharing information to detect at least one time period for a connection, with similar mechanisms to the other asserted patents involving exchanging parameter fields and metadata Compl., Ex. Q, abstract
• Asserted Claims: Independent claims 1 and 78 are asserted Compl. ¶89
• Accused Features: The accused instrumentalities are Google's software and products that allegedly use the QUIC protocol to manage connection time periods as claimed Compl. ¶88 Compl. Ex. R

III. The Accused Instrumentality

Product Identification

• The complaint broadly identifies the accused instrumentalities as:
  • "Accused Instrumentalities": Websites and web addresses, including but not limited to www.google.com, stored or hosted on Google-controlled servers Compl. ¶7
  • "Accused Software": Software for smartphones, tablets, and other computing devices Compl. ¶7
  • "Accused Products": Devices such as Pixel phones, laptops, and Chromebooks Compl. ¶7

Functionality and Market Context

• The complaint alleges that these instrumentalities infringe by making, using, or selling systems that employ the QUIC (Quick UDP Internet Connections) protocol Compl. Ex. I, p. 3 The infringement allegations map the claimed methods and systems for managing idle connections onto the functionalities of the QUIC protocol, which is characterized as a "TCP-variant" Compl. Ex. I, p. 4 A screenshot provided in the complaint's exhibits purports to show network traffic from www.google.com using the "http/2+quic/46" protocol, which the plaintiff offers as evidence of the accused functionality Compl. Ex. I, p. 3 The complaint asserts that Google derives substantial revenue from these products and services Compl. ¶5

IV. Analysis of Infringement Allegations

'945 Patent Infringement Allegations

The complaint does not provide a claim chart exhibit for the '945 patent in the submitted documents; it references an Exhibit H that was not included. The infringement theory is summarized narratively.

The complaint alleges that Google infringes at least Claim 104 of the '945 patent by making, using, and selling the Accused Instrumentalities Compl. ¶¶40-41 The theory of infringement appears to be that Google's servers provide access to code (e.g., via websites) that causes client devices to operate using the QUIC protocol. This protocol is alleged to be the "second protocol" that is different from TCP, as recited in the claim. The exchange of information within the QUIC protocol to manage connection timeouts is alleged to meet the claim limitations regarding receiving idle information, generating packets with timeout metadata, and determining a timeout attribute Compl. ¶¶40-41

'564 Patent Infringement Allegations

Claim Element (from Independent Claim 1)	Alleged Infringing Functionality	Complaint Citation	Patent Citation
A non-transitory computer readable medium, comprising: code for use by a client node...	Google's servers allegedly store and provide code (e.g., in HTML pages) for use by a client node to communicate with servers using the QUIC protocol.	¶47	col. 23:5-13
receive, by the client node from a server node, a transmission control protocol (TCP)-variant packet;	The client node allegedly receives a QUIC negotiation packet from a server node, with QUIC being characterized as a "variant" of TCP.	¶47	col. 23:14-16
detect an idle time period parameter field in the TCP-variant packet;	The client node allegedly detects an "idle_timeout" parameter field, which is a transport parameter included in the QUIC negotiation packet.	¶47	col. 23:17-19
identify metadata in the idle time period parameter field for an idle time period, during which, no packet is communicated in a TCP-variant connection to keep the TCP-variant connection active; and	The client node allegedly identifies the metadata (a value in seconds) within the "idle_timeout" field. This metadata defines a period of inactivity for the QUIC connection.	¶47	col. 23:20-25
modify, by the client node and based on the metadata, a timeout attribute associated with the TCP-variant connection.	Based on the value in the "idle_timeout" field, the client node allegedly modifies a timeout attribute of the QUIC connection, which determines when the connection will be considered closed due to idleness.	¶47	col. 23:26-28

• Identified Points of Contention:
  • Scope Questions: A central dispute may arise over whether the QUIC protocol, which is built on UDP, constitutes a "TCP-variant" as claimed in the '564 patent. The complaint alleges QUIC "implements techniques learned from experience with TCP," which may be Plaintiff's basis for this characterization Compl. Ex. I, p. 4 The defense may argue that a UDP-based protocol is fundamentally different from and not a "variant" of TCP. This same question of scope applies to the term "TCP protocol" in the '945 patent.
  • Technical Questions: The infringement allegations rely heavily on publicly available IETF drafts describing the QUIC protocol, rather than on non-public information about Google's specific implementation Compl. Ex. I, p. 2 A point of contention may be whether Google's actual implementation of QUIC conforms to the public drafts in a way that practices every step of the asserted claims.

V. Key Claim Terms for Construction

• The Term: "transmission control protocol (TCP)-variant packet" ('564 Patent, Claim 1)

• Context and Importance: The construction of this term is critical, as the infringement allegations are predicated on a QUIC packet, which is a UDP datagram, meeting this definition. If "TCP-variant" is construed to exclude UDP-based protocols, the infringement case for this patent may fail. Practitioners may focus on this term as it is the linchpin connecting the patent's TCP-centric language to the accused UDP-based QUIC technology.

• Intrinsic Evidence for Interpretation:

  • Evidence for a Broader Interpretation: The patent does not explicitly define the term. Plaintiff may argue that the term "variant" should be given its plain and ordinary meaning, encompassing protocols that share functional characteristics with TCP, such as reliable, connection-oriented communication, even if the underlying transport is different. The patent's focus on solving problems inherent in TCP could be used to argue for a broader scope covering alternative solutions like QUIC.
  • Evidence for a Narrower Interpretation: The specification is heavily rooted in TCP, with figures adapted from the TCP specification (RFC 793) Compl. Ex. B, Fig. 8 Defendant may argue that a "TCP-variant packet" must be a packet from a protocol that is a direct derivative of TCP, not a protocol built on an entirely different transport layer like UDP. The abstract distinguishes between the claimed methods and standard TCP, but does not mention UDP, which could suggest UDP-based protocols are outside the scope of the invention.

• The Term: "a first protocol including a transmission control protocol (TCP)" '945 Patent, Claim 104

• Context and Importance: Similar to the term above, the viability of the infringement allegation for the '945 patent depends on whether the accused system, which uses both standard TCP and the UDP-based QUIC protocol, meets this limitation. The dispute will likely center on whether the combination of TCP and QUIC in the accused system constitutes operation "in accordance with a first protocol including a TCP."

• Intrinsic Evidence for Interpretation:

  • Evidence for a Broader Interpretation: Plaintiff may argue that the accused system's initial operation over TCP, followed by a transition to QUIC, means the overall system operates with a "protocol including a TCP." The patent's description of providing code to enable a "second protocol" separate from TCP supports a theory where two distinct protocols are in play Compl. Ex. A, col. 4:37-52
  • Evidence for a Narrower Interpretation: Defendant may argue that the claim requires the same protocol to include TCP, and that QUIC is a separate protocol, not part of the "first protocol." The explicit separation in the patent between a "first protocol (TCP)" and a "second protocol" could be used to argue that the features of the second protocol (QUIC) cannot satisfy limitations directed to the first.

VI. Other Allegations

• Indirect Infringement: The complaint alleges that Google induces infringement of the '742 patent by providing its partners and customers with the Accused Software and Accused Products, along with materials and services related to them Compl. ¶¶90-91 The basis for this allegation is that Google acts with specific intent or willful blindness because it has had actual knowledge of the patent Compl. ¶¶90-91
• Willful Infringement: The complaint alleges willful infringement for all patents-in-suit, based on Google's alleged actual knowledge of the patents (Compl. ¶¶42; 48; 54; 60; 66; 72; 78; 84; 92). The complaint provides specific "at least as early as" dates for this knowledge, suggesting pre-suit notice.

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

1. A core issue will be one of definitional scope: can the terms "TCP-variant packet" and "protocol including a TCP," which are rooted in the patents' descriptions of TCP, be construed to read on the accused QUIC protocol, which is fundamentally based on UDP? The outcome of this claim construction dispute may be dispositive.
2. A second central question will be one of claim validity and scope in light of extensive prosecution history: given that numerous claims across the asserted patent family have been cancelled or disclaimed in IPR proceedings, the court will likely need to carefully consider the prosecution history and the grounds for those cancellations. This history may be used to argue for a narrow construction of the surviving asserted claims or to challenge their validity under different grounds.
3. A key evidentiary question will be one of proof of infringement: does the Plaintiff's reliance on public documentation for the QUIC protocol suffice to allege infringement, or will the case turn on evidence from discovery showing that Google's specific, proprietary implementation of QUIC practices the precise steps recited in the asserted claims?