PTAB

IPR2018-00804

Cloudflare Inc v. Blackbird Tech LLC

Log In
Key Events
Petition
petition

1. Case Identification

2. Patent Overview

  • Title: Method and Apparatus for Providing an Internet Third Party Data Channel
  • Brief Description: The ’335 patent describes a system for modifying data communications between an internet server and client. A "processing device," distinct from the server, monitors the data channel for a communication with a predetermined property and, upon detection, obtains data from a third-party source to modify or replace the original communication before sending it to the intended recipient.

3. Grounds for Unpatentability

Ground 1: Anticipation by Luotonen - Claims 1-2, 5-7, 9, 18-20, 22-23, and 25 are anticipated by Luotonen under 35 U.S.C. §102.

  • Prior Art Relied Upon: Luotonen (a 1994 journal article titled "World-Wide Web Proxies").
  • Core Argument:
    • Prior Art Mapping: Petitioner argued that Luotonen disclosed every limitation of the challenged claims. Luotonen described a caching proxy server (a "processing device") that sits within the data channel between a client and a remote web server. The proxy monitored communications for a specific HTTP response from the server—a "special result code" indicating a requested document was not modified—which constituted a "predetermined property." Upon detecting this code, the proxy accessed its local document cache (a "data source distinct from said internet server") to obtain the cached version of the document ("third party data"). It then replaced the server's result-code response with the cached document and sent this "resultant data communication" to the client. This architecture and functionality were alleged to map directly onto the elements of independent claims 1 and 18.

Ground 2: Obviousness over Luotonen in view of RFC 2068 - Claims 1-9 and 18-25 are obvious over Luotonen in view of RFC 2068.

  • Prior Art Relied Upon: Luotonen and RFC 2068 (a 1997 IETF standard for HTTP/1.1).
  • Core Argument:
    • Prior Art Mapping: Petitioner asserted that Luotonen taught the core caching proxy architecture, and RFC 2068 provided specific, standardized details for its implementation. RFC 2068 explicitly defined the HTTP status codes (e.g., 304 Not Modified, 4xx client errors, 5xx server errors) that a server should send in response to a conditional GET request when the full document is not being returned. These standardized codes served as the "predetermined data code" that would trigger the Luotonen proxy to serve a document from its cache. The combination thus taught monitoring for specific HTTP status codes to decide when to use the third-party data channel (the cache).
    • Motivation to Combine: A Person of Ordinary Skill in the Art (POSITA) implementing the caching proxy system described in Luotonen would have been motivated to consult RFC 2068, the then-current HTTP protocol standard, to ensure proper functionality and interoperability. Luotonen itself was based on extending the HTTP protocol, making the official standard a natural and necessary reference for implementation. The ’335 patent itself cited RFC 2068, acknowledging its relevance.
    • Expectation of Success: A POSITA would have had a high expectation of success in combining the references because RFC 2068 provided a standardized, well-defined protocol for the very caching and conditional request functionality that Luotonen described at a higher level. The combination represented a straightforward implementation of a known concept using a public standard.

Ground 3: Obviousness over Fox I in view of Fox II - Claims 8 and 24 are obvious over Fox I in view of Fox II.

  • Prior Art Relied Upon: Fox I (a 1996 article, "Reducing WWW Latency and Bandwidth Requirements by Real-Time Distillation") and Fox II (a 1996 conference paper, "Adapting to network and client variability via on-demand dynamic distillation").

  • Core Argument:

    • Prior Art Mapping: This combination was argued to render obvious claims 8 and 24, which require transmitting data on the third-party channel only when the server-to-client data transmission rate is "below a predetermined threshold." Fox I disclosed a proxy ("Pythia") that "distilled" (compressed) images to reduce latency, but based its decisions on a static, user-specified connection speed. Fox II improved upon this by introducing a Network Connection Monitor (NCM) that automatically and continuously measured the actual end-to-end bandwidth. The combined system would use the real-time bandwidth measurement from Fox II to determine if distillation was necessary. If the measured bandwidth was sufficient to transmit an image within a user's latency tolerance (i.e., above a threshold), the proxy would send the original image; if the bandwidth was insufficient (below the threshold), the proxy would distill the image and send the compressed version via the third-party channel.
    • Motivation to Combine: A POSITA would have been motivated to combine the automatic bandwidth monitor of Fox II with the distilling proxy of Fox I to create a more robust and efficient system. Fox I identified latency as the problem but relied on potentially inaccurate, user-provided data. Fox II, an extension of Fox I by the same authors, directly addressed this deficiency by providing a mechanism for real-time, accurate network measurements. The motivation was to improve the accuracy and effectiveness of the distillation decisions in Fox I by using the superior, automated measurements from Fox II.
    • Expectation of Success: Success was expected because Fox II was presented as a natural evolution of Fox I. Integrating an automated monitoring component into the proxy architecture was a predictable design choice to enhance performance and overcome the limitations of relying on static user input.

  • Additional Grounds: Petitioner also asserted that claims 1-7, 9, 18-23, and 25 were anticipated by Fox I alone.

4. Key Claim Construction Positions

  • "data channel": Petitioner proposed construing this term as any logical or physical path for transferring data between two entities, consistent with the specification's examples.
  • "internet client": Petitioner proposed this term meant software used to access the internet, such as a web browser or a module of a browser.
  • "predetermined property": Petitioner argued this should be construed broadly as any property of a data communication that can be monitored by the processing device to trigger functionality, not just a specific "data code."

5. Relief Requested

  • Petitioner requested the institution of an inter partes review and cancellation of claims 1-9 and 18-25 of the ’335 patent as unpatentable.