Code200 UAB v. Bright Data Ltd

1. Case Identification

• Case #: IPR2021-01502
• Patent #: 9,241,044
• Filed: September 10, 2021
• Petitioner(s): Code200, UAB; Teso LT, UAB; Metacluster LT, UAB; Oxysales, UAB; and Coretech LT, UAB
• Patent Owner(s): Bright Data Ltd.
• Challenged Claims: 81, 82, 87-100, and 108

2. Patent Overview

• Title: System for Accelerating Data Retrieval
• Brief Description: The ’044 patent describes a system for accessing content from a data server via an intermediary proxy device. A central "acceleration server" maintains a list of available proxies ("tunnel devices") and assigns one to a client device upon request, which the client then uses to retrieve the desired content from the target data 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’s "client" maps to the "first device," its "acceleration server" to the "first server," its "web server" to the "second server," and its intermediary "agent" to the "second device" (proxy). The petition asserted that Shribman teaches the claimed method steps, including the client registering with the acceleration server, requesting a list of available agents, and then sending a content request to a selected agent that includes identifiers for both the content and the target web server.
  • Motivation to Combine (for §103 grounds): As this ground is based on a single reference, the argument was that Shribman itself renders the claims obvious. Petitioner contended that while Shribman primarily discloses breaking content into multiple "chunks" for parallel download, it would have been obvious that scenarios exist where content is not chunked or only a single agent responds. In such cases, the client would receive all content from a single "second device," directly meeting the limitations of independent claim 81.

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 publication), RFC 2616 (Hypertext Transfer Protocol -- HTTP/1.1 standard), and RFC 1928 (Socks Protocol Version 5 standard).
• Core Argument for this Ground:
  • Prior Art Mapping: Petitioner asserted that a 2011 YouTube video demonstrating the VIP72.COM commercial proxy service disclosed all elements of the claimed method. The user's computer running the VIP72 client software acts as the "first device," the central VIP72.com server that brokers proxies is the "first server," an assigned Socks5 proxy is the "second device," and the target website is the "second server." The video allegedly shows the user logging in to the first server, requesting and receiving the IP address of a proxy, and configuring a browser to route requests through that proxy to a target website.
  • Motivation to Combine: A POSITA would have inherently understood the operation of the VIP72 service in the context of the fundamental internet standards that govern it. RFC 1928 defines the Socks5 protocol used by the VIP72 proxies, and RFC 2616 defines the HTTP protocol for the web requests being tunneled. Combining these references is merely applying the known rules of the internet to understand the disclosed system.
  • Expectation of Success: A POSITA would have had a high expectation of success, as combining the elements was a routine implementation of well-defined and ubiquitous internet protocols for proxying web traffic.

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

• Prior Art Relied Upon: Sharp KK (European Publication No. EP 2 597 869 A1) and RFC 2616 (HTTP/1.1 standard).

• Core Argument for this Ground:

  • Prior Art Mapping: Petitioner argued that Sharp KK discloses a system where a central server allocates HTTP proxies to clients for load balancing and content fetching, teaching the core claimed method. The "client" in Sharp KK corresponds to the "first device," the "relaying device specifying section" of its server corresponds to the "first server," and an assigned "proxy" corresponds to the "second device." Sharp KK was argued to explicitly show a client receiving proxy information from a server and then sending a content request—containing both a path identifier (first content identifier) and a "Host" header (third identifier)—to that proxy.
  • Motivation to Combine: A POSITA implementing the HTTP proxy system of Sharp KK would be required to follow the foundational HTTP/1.1 protocol defined in RFC 2616. This standard mandates the use of elements like the "Host" header in requests to proxies, making the combination not just motivated but necessary for proper function.
  • Expectation of Success: Implementing the system of Sharp KK according to the well-established rules of RFC 2616 would have been a standard design choice with entirely predictable results.

• Additional Grounds: Petitioner asserted additional obviousness challenges based on combinations of Shribman in view of Squid (for concurrent proxy retrievals), Shribman in view of Luotonen (for parallel processing), and Prince in view of RFC 2616 (for DNS-based proxy assignment).

4. Key Claim Construction Positions

• "the second request includes the first content identifier and the third identifier": Petitioner argued for the plain and ordinary meaning of this phrase, asserting it requires only that both identifiers be present within the second request. The construction posits that the claim language does not impose any specific limitations on the format, arrangement, or representation of these identifiers. This position was supported by referencing prior claim construction orders from related district court litigation involving the ’044 patent.

5. Arguments Regarding Discretionary Denial

• Petitioner argued against discretionary denial under §314(a) by filing the petition with a concurrent motion for joinder to IPR2021-00458 (NetNut Ltd. v. Bright Data Ltd.). The Board had already instituted review in that case. Petitioner asserted that the instant petition was "substantially identical" to the instituted NetNut IPR, presenting the same grounds based on the same prior art against the same claims. Joinder was therefore argued to promote administrative efficiency and avoid inconsistent results, weighing heavily against a discretionary denial.

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.