NetNut Ltd v. Bright Data Ltd

1. Case Identification

• Case #: IPR2021-00458
• Patent #: 9,241,044
• Filed: January 22, 2021
• Petitioner(s): NetNut Ltd.
• Patent Owner(s): Luminati Networks Ltd.
• Challenged Claims: 81-82, 87-100, 108

2. Patent Overview

• Title: System and Method for Accelerating Data Retrieval
• Brief Description: The ’044 patent relates to a method for retrieving internet content via a network of intermediary devices. The system uses a first server (an "acceleration server") to provide a client with an identifier for a second, intermediary device (a "tunnel device" or proxy), which the client then uses to request content from a second server (an origin server).

3. Grounds for Unpatentability

Ground 1: Obviousness of Claims 81, 87, 89, 92-100, and 108 over Shribman

• Prior Art Relied Upon: Shribman (Application # 2011/0087733).
• Core Argument for this Ground:
  • Prior Art Mapping: Petitioner argued that Shribman, an earlier publication by the same inventors as the ’044 patent, discloses a nearly identical architecture for accelerating data retrieval. Shribman teaches a client registering with an "acceleration server" to obtain a list of "agent" devices (proxies). The client then sends an "original request" to an agent that includes both a content identifier (e.g., /index.html) and a server identifier (e.g., www.aol.com), which functions as the claimed "third identifier." The agent retrieves the content from the origin web server and provides it to the client. Petitioner contended this process directly maps to the client-side steps of independent claim 81 and the corresponding proxy-side steps of independent claim 108.
  • Motivation to Combine (for §103 grounds): Not applicable, as this is a single-reference obviousness ground.
  • Key Aspects: The core of this ground is that every element of the challenged claims was allegedly disclosed in a single, architecturally similar prior art reference from the patent's own inventors, to which priority was not claimed.

Ground 2: Obviousness of Claims 81, 82, and 108 over VIP72.com in view of RFC 2616 and RFC 1928

• Prior Art Relied Upon: VIP72.com (a 2011 YouTube video demonstrating a commercial proxy service), RFC 2616 (Hypertext Transfer Protocol -- HTTP/1.1), and RFC 1928 (Socks Protocol Version 5).
• Core Argument for this Ground:
  • Prior Art Mapping: Petitioner asserted that the VIP72 video demonstrates the claimed method. The video shows a user logging into a main server ("first server") to obtain the IP address ("second identifier") of an available Socks5 proxy ("second device"). The user's browser is then configured to route traffic through this proxy. When the user requests a webpage (e.g., http://www.hackforums.net/index.php), the browser sends a standard HTTP request to the selected proxy. This request inherently contains both the content identifier (/index.php) and the server identifier (www.hackforums.net) in the Host header, which Petitioner mapped to the "first" and "third" identifiers, respectively. The proxy forwards the request and returns the content, fulfilling the limitations of claims 81 and 108.
  • Motivation to Combine (for §103 grounds): A POSITA would naturally interpret the functionality shown in the VIP72 video through the lens of foundational internet standards. RFC 2616 and RFC 1928 provide the necessary technical underpinnings to understand how the demonstrated HTTP-over-Socks5 proxy service operates.
  • Expectation of Success: The combination involved applying well-known, standardized internet protocols to understand a demonstrated commercial service, creating a high expectation that the system would function as alleged.

Ground 3: Obviousness of Claims 81, 82, and 108 over Sharp KK in view of RFC 2616

• Prior Art Relied Upon: Sharp KK (European Application # EP 2 597 869 A1) and RFC 2616.

• Core Argument for this Ground:

  • Prior Art Mapping: Petitioner argued Sharp KK discloses a system where a server assigns a proxy to a client to handle content requests. Sharp KK was cited for its explicit teaching of a client sending a request to a proxy that includes an absolute URI (e.g., GET http://example.com/content1), which contains both a content identifier (/content1) and a server identifier (example.com). While Sharp KK's main embodiment combines the proxy-assigning and content-serving functionalities into one server, Petitioner argued it taught the possibility of separating these functions and that doing so would have been an obvious design choice for modularity.
  • Motivation to Combine (for §103 grounds): A POSITA would be motivated to apply the standard HTTP request formats defined in RFC 2616 to the proxy communication system of Sharp KK, as both documents address fundamental web communication protocols.
  • Expectation of Success: Integrating the standard HTTP protocol within the proxy architecture disclosed by Sharp KK was presented as a routine and predictable task for a skilled artisan.

• Additional Grounds: Petitioner asserted further obviousness challenges, including claim 82 over Shribman in view of RFC 2616; claim 88 over Shribman in view of Squid; claims 90-91 over Shribman in view of Luotonen; and claims 81-82 over Prince in view of RFC 2616. These grounds primarily relied on combining Shribman's base system with well-known teachings on HTTP headers, concurrent proxy retrievals, and DNS-based proxy assignment.

4. Key Claim Construction Positions

• Petitioner argued for the plain and ordinary meaning of the key claim phrase "the second request includes the first content identifier and the third identifier."
• The core of this position was that the claim only requires the presence of both identifiers in the request, without imposing any specific format, arrangement, or representation.
• Citing a prior District Court ruling, Petitioner argued the "third identifier" is distinct from other identifiers and is not limited to an IP address but could be any identifier sufficient to locate the server, such as a domain name. This construction was critical to mapping prior art where a standard HTTP GET request includes both a path (content identifier) and a Host header (server identifier).

5. Arguments Regarding Discretionary Denial

• Petitioner argued that discretionary denial under 35 U.S.C. §325(d) and the General Plastic factors was inappropriate. Petitioner stressed that this was not a "serial petition" by the same party, as a prior IPR on the ’044 patent (IPR2020-00166) was filed by a different entity (BI Science) and was terminated before an institution decision.
• Petitioner also argued against denial under §314(a) and the Fintiv factors. It asserted that the parallel district court litigation involving the ’044 patent was effectively stayed, limited only to a post-judgment motion and potential appeal. Therefore, Petitioner contended there was no practical risk of conflicting decisions or wasted resources that would justify denying institution.

6. Relief Requested

• Petitioner requests institution of an inter partes review and cancellation of claims 81-82, 87-100, and 108 of Patent 9,241,044 as unpatentable.