Google LLC v. Jenam Tech LLC

1. Case Identification

• Case #: IPR2021-00630
• Patent #: 10,075,565
• Filed: March 15, 2021
• Petitioner(s): Google LLC
• Patent Owner(s): Jenam Tech, LLC
• Challenged Claims: 25 and 28

2. Patent Overview

• Title: Sharing Information for Detecting an Idle TCP Connection
• Brief Description: The ’565 patent discloses methods for managing network connections to detect and handle idle periods. The system involves a first node sending idle time period (ITP) information within a TCP packet header to a second node, which then uses this information to monitor the connection's state.

3. Grounds for Unpatentability

Ground 1: Claims 25 and 28 are obvious over Wookey in view of Berg.

• Prior Art Relied Upon: Wookey (Application # 2007/0171921) and Berg (Patent 6,674,713).
• Core Argument for this Ground:

  • Prior Art Mapping: Petitioner argued that Wookey, the primary reference, discloses the core architecture of the challenged claims. Wookey teaches a client-server system where a first server computer communicates with a client computer over a standard TCP connection. The server sends "code," such as an HTML page containing encoded URLs, to the client. When a user interacts with this code, it causes the client computer to establish a second connection with another server computer. Wookey suggests this second connection can use various protocols, including non-TCP protocols like IPX, to provide access to a remote resource. However, Petitioner contended Wookey does not explicitly detail how to manage this second connection to ensure reliability, particularly concerning idle timeouts and disconnections.

    Petitioner asserted that Berg supplies the missing details. Berg describes a Reliable User Datagram Protocol (RUDP), which is a non-TCP protocol designed to provide reliable connections over inherently unreliable IP networks. Crucially, Berg’s RUDP allows nodes to negotiate specific timeout parameters on a per-connection basis. These negotiable parameters include a "null segment timeout value" and a "transfer state timeout value," which Petitioner mapped to the claimed "metadata" specifying an "idle time period." Petitioner argued that in the combined system, the client would receive a packet (a RUDP SYN segment) containing these timeout values, use them to set timers, and detect an idle period upon timer expiration, as required by independent claim 25. Berg’s RUDP protocol operates at the transport layer, above IP and below the application layer (e.g., HTTP), thus satisfying further limitations. Dependent claim 28, which requires fetching the code via HTTP, was argued to be taught by Wookey’s disclosure of the first server acting as a web server communicating with the client’s web browser.

  • Motivation to Combine: Petitioner argued a person of ordinary skill in the art (POSITA) would combine Wookey and Berg to solve a known problem. Both references address establishing and maintaining reliable network connections. Wookey identifies desired characteristics for its second connection, such as handling disconnections and specifying inactive times, but lacks a specific implementation. Berg provides a ready-made solution with its RUDP, which is explicitly designed to be a flexible and reliable non-TCP protocol with configurable timeout parameters to prevent connection loss. A POSITA would have been motivated to incorporate Berg’s robust RUDP into Wookey’s system to improve the reliability of the second connection, thereby achieving the predictable result of a more stable network application.

  • Expectation of Success: Petitioner asserted a POSITA would have had a reasonable expectation of success. The combination involved applying a known protocol (Berg's RUDP) to improve a known system (Wookey's architecture) to achieve a predictable benefit (enhanced reliability through configurable timeouts). This was presented as a straightforward substitution of one known communication protocol for another from a finite number of available options to solve a well-understood problem.

4. Key Claim Construction Positions

• Petitioner argued that no express claim constructions were necessary. However, it contended that the term "[a/the] second protocol that is different from the TCP" is a central element of the claims. Petitioner asserted that Berg’s RUDP is unequivocally a non-TCP protocol and thus satisfies this limitation under any reasonable interpretation. This position was critical to the application of Berg as a secondary reference.

5. Arguments Regarding Discretionary Denial

• Petitioner argued against discretionary denial under 35 U.S.C. §314(a) based on the Fintiv factors, asserting that the factors weighed in favor of institution.
  • Trial Proximity & Stays: Petitioner emphasized that no trial date had been set in the parallel district court litigation (Jenam Tech, LLC v. Google LLC, W.D. Tex.). Furthermore, the court had stayed the case pending a decision on Google’s motion to transfer, making any potential trial date highly speculative and likely to occur well after the Final Written Decision (FWD) deadline for the inter partes review (IPR).
  • Investment in Parallel Proceeding: Petitioner contended that investment in the parallel litigation was minimal. The case was in its earliest stages, with discovery not yet commenced and no substantive rulings on validity or claim construction.
  • Overlap and Merits: Petitioner argued that since the district court case was stayed and validity contentions had not been served, there was minimal overlap between the proceedings. The petition presented a strong, meritorious challenge that, if successful, would simplify issues in the parallel case and promote efficiency.

6. Relief Requested

• Petitioner requests institution of an IPR and cancellation of claims 25 and 28 of Patent 10,075,565 as unpatentable.