PTAB

IPR2014-01398

Riverbed Technology Inc v. Parallel Networks LLC

Log In
Key Events
Petition
petition

1. Case Identification

2. Patent Overview

  • Title: Method and System for Uniform Resource Locator Transformation
  • Brief Description: The ’570 patent describes a method for caching different versions of web content that vary based on information in an HTTP request header. The system transforms an original Uniform Resource Locator (URL) by incorporating header data to create a new, unique URL that is then used to cache and retrieve the header-dependent content.

3. Grounds for Unpatentability

Ground 1: Obviousness over Hu and Mattis - Claims 1-5, 7-12, 14-19, and 21 are obvious over Hu in view of Mattis.

  • Prior Art Relied Upon: Hu (Patent 6,173,322) and Mattis (Patent 6,292,880).
  • Core Argument for this Ground:
    • Prior Art Mapping: Petitioner argued that Hu taught a network request manager that acts as an intermediary, receives client requests containing a URL and header data ("client data"), and uses a "rules module" to transform the request based on that data. Hu’s rules could append a new string to the URL based on a pattern found in the header data. Hu also disclosed a data cache for storing content. However, Petitioner contended Hu did not explicitly teach that the cache lookup for retrieving content was performed "based on" the newly transformed URL. Mattis was asserted to supply this teaching. Mattis described a proxy cache system for handling "alternates" (different versions) of content for the same URL. To manage this, Mattis taught transforming the original URL by concatenating header information (e.g., the "User-Agent" header) with the URL to form a new "name key," which was then used to locate and retrieve the specific content version from the cache.
    • Motivation to Combine: Petitioner asserted a person of ordinary skill in the art (POSITA) would combine Hu and Mattis because Hu described its cache as operating according to "conventional data caching principles." Mattis provided a detailed example of such a conventional system for the exact problem of caching header-dependent content. A POSITA looking to implement Hu's system would have looked to references like Mattis to understand how a conventional cache handles content variants, leading them to use Mattis's technique of caching based on a transformed URL.
    • Expectation of Success: The combination would have yielded predictable results. It amounted to substituting one known caching technique (Mattis) into a system designed to use such a technique (Hu), thereby ensuring that the correct, header-specific version of a document was retrieved from the cache.

Ground 2: Obviousness over Rosenberg and Apache - Claims 1-21 are obvious over Rosenberg in view of Apache.

  • Prior Art Relied Upon: Rosenberg (Patent 5,740,430) and Apache ("URL Manipulation with Apache" by Engelschall et al.).
  • Core Argument for this Ground:
    • Prior Art Mapping: Petitioner argued that Rosenberg disclosed all claim limitations except for the specific mechanism of the URL transformation. Rosenberg taught a server that receives a standard file request (URL plus header data), transforms it into a "Customized Uniform Resource Locator" (CURL) by combining the original URL with an attribute like browser type, and then uses the CURL to cache and retrieve customized pages. However, Rosenberg did not specify how the transformation rules were implemented. The Apache publication was alleged to disclose this missing element. Apache described its mod_rewrite engine, which used a set of configurable rules—consisting of a pattern (regular expression) and a substitution string—to rewrite URLs. Crucially, Apache’s rules could be conditioned on HTTP header information, such as the "user-agent" field, to transform a URL based on both the original URL and header data.
    • Motivation to Combine: The motivation was exceptionally strong, as Rosenberg explicitly identified the Apache web server as a well-known server on which its invention could be implemented. A POSITA tasked with implementing Rosenberg's abstract URL transformation on an Apache server would have naturally and obviously turned to Apache's own mod_rewrite module, which was designed for precisely this function.
    • Expectation of Success: Success would be expected because mod_rewrite was a mature and documented tool designed to work seamlessly with the Apache server mentioned in Rosenberg. Combining the two involved using a known tool to implement a disclosed function within its intended environment, leading to the predictable result of a functioning URL transformation system.

Ground 3: Incremental Obviousness over Hu, Mattis, and Cohen - Claims 6, 13, and 20 are obvious over Hu and Mattis, in further view of Cohen.

  • Prior Art Relied Upon: Hu (Patent 6,173,322), Mattis (Patent 6,292,880), and Cohen (Patent 6,654,741).
  • Core Argument for this Ground:
    • Prior Art Mapping: This ground built upon the Hu/Mattis combination to address the additional limitation in claims 6, 13, and 20 requiring that the specific transform "utilizes a lookup table." While Hu taught a "rules module," it did not specify how the rules were stored or implemented. Cohen was introduced to disclose a URL-mapping system where transformation rules were explicitly stored and implemented in a table format. Cohen's Figure 5 showed a rule cache table with columns for "Input Expression" and "Output Expression," demonstrating a direct mapping that functions as a lookup table. Cohen also taught that its system could use other inputs, such as data from an HTTP header.
    • Motivation to Combine: A POSITA implementing Hu's abstract "rules module" would be motivated to seek out known, concrete implementations for storing and applying transformation rules. This search would have led to well-known techniques like the lookup table structure described in Cohen, representing a routine design choice for implementing a rule-based system.
    • Expectation of Success: The combination was predictable because it involved implementing an abstract module (Hu's rules module) with a standard and well-understood data structure (Cohen's lookup table). This would not alter the functionality of the underlying Hu/Mattis system.

4. Key Claim Construction Positions

  • "means for..." limitations (e.g., claims 8-10, 14): Petitioner argued that the ’570 patent recited twelve distinct means-plus-function limitations but failed to disclose corresponding structure for each function with sufficient detail as required under §112, para. 6. Petitioner contended that the patent specification only ever described a single general structure—the "cache server 16"—as performing all the recited functions. While proposing constructions for the purpose of the IPR, Petitioner reserved the right to argue these claims were indefinite for lacking corresponding structure.

5. Relief Requested

  • Petitioner requested institution of an inter partes review and cancellation of claims 1-21 of Patent 8,352,570 as unpatentable.