PTAB

IPR2025-01285

Dell Technologies Inc v. Cloud Byte LLC

Log In
Key Events
Petition
petition

1. Case Identification

2. Patent Overview

  • Title: Network System and Network Flow Tracing Method
  • Brief Description: The ’177 patent discloses a network system and method for tracing packet flow. The system uses a controller and switch apparatuses that can identify, duplicate part of a packet header to create an additional header, and encapsulate the packet with this new header to facilitate network monitoring and control.

3. Grounds for Unpatentability

Ground 1: Obviousness over Rijhsinghani - Claims 1, 5-7, 11-13, and 19 are obvious over Rijhsinghani.

  • Prior Art Relied Upon: Rijhsinghani (Patent 6,526,052).
  • Core Argument for this Ground:
    • Prior Art Mapping: Petitioner argued that Rijhsinghani, which discloses a system for managing Virtual Local Area Networks (VLANs), teaches all limitations of the independent claims. Rijhsinghani’s programmable switches, controlled by a central Network Management Station (NMS), function as the claimed "switch apparatus" and "control apparatus." The switches receive configuration instructions (rules and actions) from the NMS and store them in memory. Petitioner contended it would have been obvious to a person of ordinary skill in the art (POSITA) to store these rules in a table, a common practice for switches. When a switch receives a packet, it identifies the correct VLAN based on the rules. To forward the packet, the switch encapsulates it by adding a VLAN header. Critically, this VLAN header is created by duplicating parts of the original packet's header (e.g., source and destination addresses), thus teaching the "duplicate a part of a header...as an additional header" limitation. The switch then processes the packet by forwarding it according to the established VLAN rules.
    • Motivation to Combine: Not applicable for a single-reference ground.
    • Expectation of Success: Not applicable for a single-reference ground.

Ground 2: Obviousness over Rijhsinghani and RFC-5474 - Claims 2-4, 8-10, 12, 14-18, and 20 are obvious over Rijhsinghani in view of RFC-5474.

  • Prior Art Relied Upon: Rijhsinghani (Patent 6,526,052) and RFC-5474 ("A Framework for Packet Selection and Reporting," Mar. 2009).
  • Core Argument for this Ground:
    • Prior Art Mapping: This ground addressed dependent claims requiring the switch to send header information to the control apparatus after encapsulation. While Rijhsinghani teaches a control apparatus (NMS) sending instructions to switches, it does not explicitly disclose the switches sending monitoring data back. Petitioner asserted that RFC-5474, which describes the standardized Packet Sampling (PSAMP) protocol, remedies this. RFC-5474 teaches network devices selecting packets and sending "Packet Reports," which include the packet header and any encapsulation headers, to a central "Collector." In the proposed combination, Rijhsinghani's switch would act as the PSAMP device, and its NMS would act as the Collector, thereby receiving the required header information.
    • Motivation to Combine: A POSITA implementing Rijhsinghani’s VLAN system would be motivated to monitor network traffic to effectively configure, manage, and troubleshoot the network. RFCs are a primary source for standardized network techniques, and a POSITA would naturally look to a well-known protocol like PSAMP, described in RFC-5474, to implement such monitoring. The explicit purpose of PSAMP is to provide measurement-based support for network management, directly aligning with the goals of Rijhsinghani’s system.
    • Expectation of Success: Because PSAMP was a standardized and widely understood protocol for network elements, a POSITA would have a reasonable expectation of success in implementing its reporting functions within the switches of Rijhsinghani's established VLAN architecture.

Ground 3: Obviousness over Rijhsinghani and Lean - Claims 2-4, 8-10, 12, 14-18, and 20 are obvious over Rijhsinghani in view of Lean.

  • Prior Art Relied Upon: Rijhsinghani (Patent 6,526,052) and Lean (Application # 2008/0031141).

  • Core Argument for this Ground:

    • Prior Art Mapping: Similar to Ground 2, this combination addressed the dependent claims requiring the switch to send header information to an external controller. Lean discloses methods for monitoring high-bandwidth IP networks, including tunneled traffic, by using "taps" to passively copy packets and forward the entire copied packet (including headers) to an external processor for analysis. Petitioner argued a POSITA would modify Rijhsinghani's switches to incorporate Lean's packet-copying functionality, thereby sending copies of encapsulated packets to the NMS (the external controller) for traffic analysis.
    • Motivation to Combine: A POSITA would combine these references for the same core reason as in Ground 2: to enable network traffic monitoring for better management of Rijhsinghani's VLAN system. Lean provides a common and well-known technique (packet copying) to achieve this. A POSITA would have recognized that integrating this copying function directly into the network switches, rather than using separate taps, would provide superior and more complete visibility into network traffic.
    • Expectation of Success: Packet copying for network analysis was a conventional technique. Implementing this known functionality within a switch architecture like Rijhsinghani's would have been a straightforward modification for a POSITA, with a high likelihood of success.

  • Additional Grounds: Petitioner asserted additional obviousness challenges (Grounds 4-6) by adding the Computer Networking textbook to the combinations in Grounds 1-3. These grounds argued that if Rijhsinghani were found not to explicitly teach storing rules and actions in a table, the Computer Networking textbook clearly establishes that using forwarding tables was a fundamental, well-known technique in network routers and switches, making it obvious to implement in Rijhsinghani's system.

4. Key Claim Construction Positions

  • "encapsulate" / "decapsulate": Petitioner argued a POSITA would understand these terms by their plain meaning in the networking context. "Encapsulate" means appending an additional header to a data packet, and "decapsulate" means removing that additional header. This construction is central to mapping Rijhsinghani's addition of a VLAN header to the claimed "encapsulation" step.
  • "[duplicate/duplicating] a part of a header of the identified packet as an additional header": Petitioner proposed this phrase means that when a packet is identified as a target for encapsulation, a portion of its existing header is copied to be used as part of the new encapsulation header. This construction is crucial to the argument that Rijhsinghani's copying of source/destination addresses into a new VLAN header meets this specific claim limitation.

5. Relief Requested

  • Petitioner requests institution of an inter partes review (IPR) and cancellation of claims 1-20 of the ’177 patent as unpatentable.