Dell Technologies Inc.  et al.

Prosecution History analysis

Examiner Search analysis

Invalidity Framework analysis

Petition

Petition Analysis

## 1. Case Identification
- Case #: [IPR2025-01285](https://ai-lab.exparte.com/case/ptab/IPR2025-01285)
- Patent #: [9,560,177](https://ai-lab.exparte.com/patent/9560177)
- Petitioner(s): [Dell Technologies Inc.](https://ai-lab.exparte.com/party/dell-inc) and Dell Inc.
- Patent Owner(s): [Cloud Byte LLC](https://ai-lab.exparte.com/party/cloud-byte-llc)
- Challenged Claims: 1-20

## 2. Patent Overview
- Title: Network System and Network Flow Tracing Method
- Brief Description: The ’177 patent describes a network system and method for tracing packet flow. The system uses a central controller that communicates with network switches and a header translating unit to monitor and control packet flow, even when a packet's header is changed by network equipment.

## 3. Grounds for Unpatentability
#### Ground 1: Claims 1, 5-7, 11-13, and 19 are obvious over Rijhsinghani.
  - **Prior Art Relied Upon:** [Rijhsinghani](https://ai-lab.exparte.com/case/ptab/IPR2025-01285/doc/1005) (Patent 6,526,052).
  - **Core Argument for this Ground:**
    - **Prior Art Mapping:** Petitioner argued that Rijhsinghani discloses a Virtual Local Area Network (VLAN) system with programmable switches controlled by a Network Management Station (NMS), which functions as the claimed "control apparatus." The NMS sends instructions (claimed "rules and actions") to the switches, which then identify received packets based on characteristics like source/destination address. For packets that are targets for VLAN tagging, the switches add a new VLAN header. Critically, Rijhsinghani explicitly teaches duplicating the source and destination addresses from the original packet's header to create part of the new VLAN header, thereby teaching the claimed "duplicating" and "encapsulating" limitations.
    - **Motivation to Combine (for §103 grounds):** This ground is based on a single reference. However, Petitioner argued it would have been obvious to a Person of Ordinary Skill in the Art (POSITA) to implement Rijhsinghani's rules and actions in a "table," as claimed. Storing routing information in tables was a common, predictable, and finite design choice for network switches at the time.
    - **Expectation of Success (for §103 grounds):** A POSITA would have a reasonable expectation of success in implementing the VLAN configuration rules in a table structure, as this was a standard and well-understood technique for managing packet routing decisions in network switches.

#### Ground 2: 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](https://ai-lab.exparte.com/case/ptab/IPR2025-01285/doc/1006) (“A Framework for Packet Selection and Reporting”).
  - **Core Argument for this Ground:**
    - **Prior Art Mapping:** This ground addresses dependent claims requiring the switch to send header information to the external control apparatus. While Rijhsinghani describes the NMS sending instructions *to* the switches, it does not explicitly disclose the switches sending information *back*. RFC-5474 remedies this by disclosing the Packet Sampling (PSAMP) protocol, a standardized framework for network devices to select packets, create reports on them (which must include the packet header), and export those reports to a "Collector" (an external controller, like Rijhsinghani's NMS). The combination thus teaches a switch that sends header information of encapsulated packets to a control apparatus.
    - **Motivation to Combine (for §103 grounds):** A POSITA would combine Rijhsinghani with RFC-5474 to add standardized network traffic analysis and monitoring to the VLAN system. Rijhsinghani teaches the need to reconfigure networks based on traffic patterns, and RFC-5474 provides a well-known, standard protocol (PSAMP) for gathering the necessary traffic data, which would improve network management, troubleshooting, and interoperability.
    - **Expectation of Success (for §103 grounds):** Implementing a known, standardized protocol like PSAMP in the switches of a system like Rijhsinghani's would have been a straightforward task for a POSITA with a high expectation of success.

#### Ground 3: 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](https://ai-lab.exparte.com/case/ptab/IPR2025-01285/doc/1007) (Application # 2008/0031141).
  - **Core Argument for this Ground:**
    - **Prior Art Mapping:** Similar to Ground 2, this ground targets claims requiring the switch to send header information to an external controller. Lean discloses methods and systems for monitoring IP network traffic by using "taps" to passively copy entire packets (including their headers) and send the copied stream to a remote processor for analysis. Modifying Rijhsinghani's switches to perform the packet-copying function of Lean's taps would result in a switch that sends header information of encapsulated packets to the NMS for traffic analysis.
    - **Motivation to Combine (for §103 grounds):** A POSITA would combine the references to fulfill the need for network traffic analysis suggested by Rijhsinghani. Lean provides a known technique for collecting this traffic data. A POSITA would have been motivated to integrate Lean's packet-copying functionality directly into Rijhsinghani's switches, rather than using separate taps, to gain superior and more complete visibility into the traffic flowing through the network.
    - **Expectation of Success (for §103 grounds):** Incorporating known packet-copying functionality into a network switch was a well-understood technique, and a POSITA would have a reasonable expectation of success in doing so.

- **Additional Grounds:** Petitioner asserted additional obviousness challenges (Grounds 4-6) based on combinations of Rijhsinghani with RFC-5474 or Lean, further adding [Computer Networking](https://ai-lab.exparte.com/case/ptab/IPR2025-01285/doc/1008) (a 2008 textbook) to argue that even if Rijhsinghani did not explicitly disclose a "table," implementing rule-based forwarding in a table structure was a fundamental and well-known design choice.

## 4. Key Claim Construction Positions
- **“encapsulate”/“encapsulating”/“encapsulation”:** Petitioner argued a POSITA would understand these terms to mean appending an additional header to a data packet. This construction aligns Rijhsinghani's disclosure of adding a VLAN header with the claim language.
- **“[duplicate/duplicating] a part of a header of the identified packet as an additional header”:** Petitioner argued this means that when a packet is identified for encapsulation, a part of its existing header is copied for use in the new, additional header. This construction is central to mapping Rijhsinghani, which explicitly describes duplicating source and destination addresses from a received packet into the new VLAN header.

## 7. Relief Requested
- Petitioner requests institution of an inter partes review for claims 1-20 of Patent 9,560,177 and cancellation of those claims as unpatentable.

Dell targets network flow tracing patent: All 20 claims challenged as obvious over Rijhsinghani's VLAN encapsulation & RFC-5474 monitoring art.