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: 6:21-cv-271, W.D. Tex., 03/17/2021
• Venue Allegations: Plaintiff alleges venue is proper in the Western District of Texas because Google maintains a regular and established place of business in Austin, Texas.
• Core Dispute: Plaintiff alleges that a wide range of Google's software and hardware products, which utilize network connections, infringes a patent related to the cooperative management of network connection states and timeouts between two nodes.
• Technical Context: The technology addresses the efficient management of network resources by enabling endpoints of a connection to share information and coordinate when a connection should be considered idle or terminated.
• Key Procedural History: The patent-in-suit, U.S. Patent No. 10,951,742, descends from a long chain of continuation applications with an earliest priority date in 2010. The complaint was filed one day after the patent issued. Notably, on March 16, 2022, approximately one year after the complaint was filed, the patent owner filed a disclaimer for all asserted independent claims (1 and 78), among others. This post-filing event raises fundamental questions about the ongoing viability of the specific infringement counts alleged in the original complaint.

Case Timeline

Date	Event
2010-02-27	'742 Patent Earliest Priority Date
2020-10-23	'742 Patent Application Filing Date
2021-03-16	'742 Patent Issue Date
2021-03-17	Complaint Filing Date

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

U.S. Patent No. 10,951,742 - "Methods, Systems, and Computer Program Products for Sharing Information for Detecting at Least One Time Period for a Connection"

The Invention Explained

• Problem Addressed: The patent's background section describes inefficiencies in how network connections based on the Transmission Control Protocol (TCP) are managed. Specifically, it notes that the common "keep-alive" feature is not part of the formal TCP standard, leading to a lack of cooperation between connection endpoints. This can result in wasted network bandwidth or premature connection termination by network intermediaries (e.g., firewalls) that attempt to close connections they deem idle ('742 Patent, col. 2:5-38). The patent identifies a need for a mechanism to allow connection endpoints to cooperate in detecting and managing idle or dead connections ('742 Patent, col. 2:42-48).
• The Patented Solution: The invention provides a method for two nodes to explicitly share information to coordinate connection management. As described in the abstract and detailed description, a first node can generate a packet containing "metadata" that specifies parameters for an idle time period. This packet is sent to a second node, which can then use this metadata to determine its own corresponding timeout duration. This creates a cooperative framework for managing the connection state, rather than relying on uncoordinated, unilateral actions ('742 Patent, Abstract; col. 6:18-34).
• Technical Importance: The described technology aims to solve a long-standing problem in networking by creating a formal mechanism for coordination, potentially improving resource efficiency and connection stability in complex network environments with devices like firewalls and Network Address Translators (NATs) ('742 Patent, col. 2:32-38).

Key Claims at a Glance

• The complaint asserts independent claims 1 and 78 ('742 Patent, col. 25:4-28:65; Compl. ¶17).
• Independent Claim 1 recites an apparatus comprising a processor and memory to perform steps including:
  • Identifying information for a "first duration" for detecting a time period.
  • Allocating a resource for a "first non-TCP connection".
  • Generating a "first non-TCP packet" with metadata for determining a "second duration".
  • Setting up the connection by sending the packet to a second node.
  • Partially closing the connection based on detecting a time period using the "first duration".
  • Partially closing the connection based on detecting a time period using the "second duration".
  • Partially closing the connection based on detecting a time period using a "third duration", where the third duration is determined by a "first algorithm" that is different from a "second algorithm" used to determine the second duration.
• Independent Claim 78 recites a method with nearly identical steps to claim 1, but for a "TCP-variant connection" rather than a "non-TCP connection."

III. The Accused Instrumentality

Product Identification

The complaint broadly accuses a wide range of Google's products and services, designated as "Accused Software" and "Accused Products" (Compl. ¶7). This includes, but is not limited to, Google Cloud, Android, Chrome, Google Maps, YouTube, and hardware such as Pixel phones and Chromebooks (Compl. ¶7).

Functionality and Market Context

The complaint alleges that these products and services make, use, sell, or import systems that implement network connection functionalities (Compl. ¶7, ¶13). However, the complaint does not provide specific technical details about how any particular accused product operates. It instead makes a blanket assertion that the functionalities of the enumerated products fall within the scope of the patent claims (Compl. ¶17). The complaint does not contain sufficient detail for a specific analysis of the accused products' technical operation.

IV. Analysis of Infringement Allegations

The complaint states that a claim chart demonstrating infringement is attached as Exhibit B (Compl. ¶16, ¶17). This exhibit was not provided. The narrative infringement theory is that the "Accused Software and Accused Products" contain "each and every element of at least claims 1 and 78 of the '742 patent" (Compl. ¶17). Without the claim chart or more detailed allegations, a tabular analysis of the infringement contentions is not possible.

No probative visual evidence provided in complaint.

Identified Points of Contention:

• Scope Questions: The asserted claims are directed to "non-TCP connection" (Claim 1) and "TCP-variant connection" (Claim 78). A central dispute may be whether the networking protocols used by Google's products (e.g., standard TCP, QUIC) fall within the scope of these terms, which the patent appears to distinguish from standard TCP.
• Technical Questions: The claims require a complex, multi-stage process involving first, second, and third timeout durations, where the third is determined by an algorithm different from that used for the second. A key question for the court will be whether the complaint provides plausible factual allegations that Google's products perform this specific, algorithmically differentiated timeout management, or if the allegations are merely a recitation of the claim language.

V. Key Claim Terms for Construction

"non-TCP connection" (from Claim 1)

• Context and Importance: The construction of this term is critical for determining infringement of Claim 1. The complaint accuses a wide array of products that likely use standard TCP or modern protocols like QUIC. Practitioners may focus on this term because its definition will determine whether the claim can read on Google's conventional networking stacks.
• Intrinsic Evidence for a Broader Interpretation: A party might argue that the term should be broadly construed to mean any connection-oriented protocol that is not strictly compliant with the original TCP specification (RFC 793), thereby capturing modern implementations with various extensions.
• Intrinsic Evidence for a Narrower Interpretation: The patent’s abstract lists "a non-TCP connection, a TCP-variant connection, not a Transmission Control Protocol connection, etc." as distinct examples, suggesting "non-TCP" is intended to mean something other than TCP or its variants ('742 Patent, Abstract). A party could argue the patentee defined the term to exclude TCP.

"TCP-variant connection" (from Claim 78)

• Context and Importance: This term is central to infringement of Claim 78. Its scope will determine whether protocols like QUIC (which provides TCP-like reliability over UDP) or other proprietary Google protocols can be considered a "variant" of TCP.
• Intrinsic Evidence for a Broader Interpretation: A party could argue this term encompasses any protocol that provides TCP-like features (e.g., reliable, in-order delivery) or that modifies or extends the principles of TCP, even if the underlying transport is different.
• Intrinsic Evidence for a Narrower Interpretation: The specification does not explicitly define what constitutes a "variant." A party may argue the term is limited to protocols that are direct modifications of the TCP protocol itself, rather than entirely new protocols designed to replace it.

VI. Other Allegations

• Indirect Infringement: The complaint alleges Google induces infringement by distributing the accused products and providing related materials and services with the specific intent to cause infringement by partners and customers (Compl. ¶18-19).
• Willful Infringement: The complaint alleges willful infringement based on Google’s purported knowledge of the '742 patent, stating that this knowledge exists "at least as early as the date of service of this Complaint" (Compl. ¶21).

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

• A threshold question of viability: Given the patent owner's post-filing disclaimer of both asserted independent claims, the most significant issue is whether the lawsuit has any remaining legal or factual basis, or if it will require dismissal or substantial amendment to proceed.
• A core issue will be one of definitional scope: can the terms "non-TCP connection" and "TCP-variant connection", which the patent appears to distinguish from standard TCP, be construed to cover the widely-used networking protocols implemented in Google’s vast and diverse ecosystem of accused products?
• A key evidentiary question will be one of functional complexity: what evidence, if any, demonstrates that the accused products implement the specific multi-stage timeout determination process of the claims, particularly the requirement for a "third duration" to be calculated using an algorithm that is "different from" the algorithm used for the "second duration"?