PTAB
IPR2013-00091
Oracle Corp v. Clouding IP LLC
Key Events
Petition
Table of Contents
petition
1. Case Identification
- Case #: IPR2013-00091
- Patent #: 5,678,042
- Filed: December 17, 2012
- Petitioner(s): Oracle Corporation
- Patent Owner(s): Clouding IP, LLC
- Challenged Claims: 1-4
2. Patent Overview
- Title: Network Management System Having Historical Virtual Catalog Snapshots For Overview of Historical Changes To Files Distributively Stored Across Network Domain
- Brief Description: The ’042 patent discloses a network management method for monitoring file servers. The system periodically collects "snapshots" of the contents of local file server catalogs, stores this information in a central "historical database," and automatically tracks changes over time to manage the network.
3. Grounds for Unpatentability
Ground 1: Obviousness over Reference Model, Floyd, and ESA - Claims 1-4
- Prior Art Relied Upon: Reference Model (a 1990 IEEE publication), Floyd (a 1989 Ph.D. thesis), and ESA (a 1991 publication, Essential System Administration).
- Core Argument for this Ground:
- Prior Art Mapping: Petitioner argued that Reference Model taught the core network architecture, including collecting snapshots of file server contents (as "bit string descriptors") and maintaining this information in a historical database (a "descriptor table"). However, Reference Model did not explicitly teach storing local catalogs on their respective storage devices or automating the snapshot and tracking process. Petitioner asserted that Floyd taught storing file properties in a "property list" together with the file on its storage device. ESA was argued to supply the missing automation, teaching the use of well-known scripts (e.g.,
cron,ckdsk) to periodically take snapshots of disk usage and compare them to previous snapshots to automatically track changes. - Motivation to Combine: A POSITA would combine Floyd’s approach with Reference Model to improve the management and monitoring capabilities of the network system. Furthermore, a POSITA would have found it obvious to implement the well-known automation scripts from ESA into the Reference Model system to perform the routine tasks of collecting snapshots over time and tracking changes, as these were common administrative functions.
- Expectation of Success: Petitioner contended that a POSITA would have had a high expectation of success because Reference Model described a generic architecture applicable to conventional hardware and software, and ESA taught standard, widely used commands and scripts for system administration that could be easily incorporated.
- Prior Art Mapping: Petitioner argued that Reference Model taught the core network architecture, including collecting snapshots of file server contents (as "bit string descriptors") and maintaining this information in a historical database (a "descriptor table"). However, Reference Model did not explicitly teach storing local catalogs on their respective storage devices or automating the snapshot and tracking process. Petitioner asserted that Floyd taught storing file properties in a "property list" together with the file on its storage device. ESA was argued to supply the missing automation, teaching the use of well-known scripts (e.g.,
Ground 2: Obviousness over Caccavale, Reference Model, Floyd, and ESA - Claims 1-4
- Prior Art Relied Upon: Caccavale (Patent 5,664,106), Reference Model, Floyd, and ESA.
- Core Argument for this Ground:
- Prior Art Mapping: This ground presented an alternative combination where Caccavale provided the primary framework. Petitioner argued that Caccavale taught a method for improving server performance by collecting snapshots of server behavior data over time and automatically tracking changes to implement tuning. While Caccavale did not explicitly mention file server catalogs, it was argued that a POSITA would find it obvious to apply this performance monitoring method to a file server environment, such as the one described in Reference Model and Floyd. In this context, local catalog information (e.g., storage capacity) is a key parameter of server performance. ESA again supplied the teachings for specific, well-known scripts to automate the data collection and tracking processes.
- Motivation to Combine: The primary motivation was to enhance Caccavale’s server performance monitoring system. Since information in local file catalogs is representative of key performance metrics like storage capacity, a POSITA would combine the teachings of Reference Model/Floyd with Caccavale to further Caccavale's stated goal. The combination would create a more robust system for monitoring file server performance.
- Expectation of Success: Success would have been expected because the combination involved applying a known monitoring methodology (Caccavale) to a known system architecture (Reference Model/Floyd) using standard automation tools (ESA).
Ground 3: Obviousness over Robins, Reference Model, and Floyd - Claims 1-4
- Prior Art Relied Upon: Robins (Patent 5,079,873), Reference Model, and Floyd.
- Core Argument for this Ground:
- Prior Art Mapping: Petitioner asserted that Robins taught the core claimed method but in a different technical context—a communications network rather than a file server network. Robins disclosed collecting snapshots of data from network nodes (e.g., configuration databases, event logs) and automatically tracking changes in that data. Petitioner argued that this system was analogous to the claimed invention. Reference Model and Floyd were relied upon to provide the specific teachings of a file server environment containing local catalogs on distributed storage devices.
- Motivation to Combine: A POSITA would combine these references because file server nodes and the communication switching nodes in Robins are functionally analogous; both are designed to store, process, and transmit data across a network. Therefore, a POSITA would have been motivated to apply the established network management and monitoring techniques from Robins to the known file server architecture of Reference Model.
- Expectation of Success: Petitioner argued success would be predictable and expected, as it would merely involve applying a known management method to an analogous type of network environment.
4. Key Claim Construction Positions
- local catalog: Petitioner argued this term should be construed as "a listing of the contents of a storage device including at least the name and location of files stored on the data storage device in any suitable format." This construction was based on the patent's specification.
- snapshot: Proposed as "the combined content of all the local catalogs in the system." This construction was derived from the specification's description of a domain-wide scan that interrogates each local catalog.
- historical database: Argued to be "a collection of historical information from the snapshots collected," without limitation to a specific database structure. This interpretation was based on the specification referring to the data as a "historical collection."
5. Relief Requested
- Petitioner requests institution of an inter partes review and cancellation of claims 1-4 of the ’042 patent as unpatentable.
Analysis metadata