US 9560177

Here is a concise summary of US patent 9560177:

• Title: Network system and network flow tracing method
• Assignee: Cloud Byte LLC
• Inventor: Masaharu Morimoto
• Filing Date: March 17, 2016
• Issue Date: January 31, 2017
• Abstract: The patent describes a switch apparatus that includes storage for rules and actions, and a controller with a memory and processor. This processor receives rules and actions from a control apparatus, identifies incoming packets based on these rules, and if a packet is targeted for encapsulation, it duplicates part of its header to create an additional header. The identified packet is then encapsulated with this additional header and processed according to the defined actions.

Plain-Language Overview of Independent Claims:

• Independent Claim 1 (Switch Apparatus): This claim describes a network switch that contains a storage for network rules and corresponding actions. It also has a controller with a processor that is programmed to receive these rules and actions from a central control unit. When the switch receives a packet, its processor identifies the packet using the rules. If the packet is meant to be encapsulated, the processor duplicates a portion of the packet's original header to create a new "additional header." The packet is then encapsulated using this additional header, and finally, the switch processes the packet according to the predetermined actions.

• Independent Claim 7 (Communication System): This claim outlines a communication system that includes a central control apparatus, which manages several switch apparatuses. Each of these switch apparatuses is configured similarly to the one in Claim 1. They each have storage for rules and actions, and a controller with a processor. This processor receives instructions from the central control, identifies incoming packets, creates a duplicate "additional header" for packets needing encapsulation, performs the encapsulation, and then processes the packet based on the actions.

• Independent Claim 13 (Communication Method): This claim describes a method for network communication. The steps involve receiving rules and actions from a network controller, then identifying a received packet based on these rules. If the packet is a target for encapsulation, a part of its existing header is duplicated to form an "additional header." The packet is then encapsulated using this additional header, and finally, the packet is processed according to the specified actions.

• Independent Claim 19 (Non-Transitory Recording Medium): This claim covers a non-transitory computer-readable recording medium that stores a program. When this program is executed by a switch, it enables the switch to perform the method described in Claim 13. This includes receiving rules and actions from a controller, identifying a packet, duplicating a header for encapsulation, encapsulating the packet, and processing it based on the actions.

Uncertainty Regarding CAFC Dockets:
As of April 26, 2026, a search of the CAFC 2026 dockets did not return any scheduled cases specifically listing US patent 9560177. Therefore, there is no authoritative information currently available from the CAFC dockets indicating active litigation for this patent in 2026.

Known litigation involving US patent 9560177 includes the following:

Patent Trial and Appeal Board (PTAB) Case

• Case Number: IPR2025-01285
• Jurisdiction: Patent Trial and Appeal Board (PTAB)
• Filing Date: 2025-07-14
• Plaintiff(s) (Petitioner): Dell Technologies, Inc., and Dell, Inc.
• Defendant(s) (Patent Owner): Cloud Byte LLC (current assignee of US9560177B2 as of 2024-06-27)
• Outcome or Current Status: Not Instituted - Procedural

US District Court Cases

Two cases have been filed in the Texas Eastern District Court:

1. Case Number: 2:26-cv-00150

   • Jurisdiction: Texas Eastern District Court
   • Filing Date: The case number indicates a 2026 filing year.
   • Plaintiff(s): Not explicitly stated in the provided information.
   • Defendant(s): Not explicitly stated in the provided information.
   • Outcome or Current Status: Filed

2. Case Number: 2:24-cv-00637

   • Jurisdiction: Texas Eastern District Court
   • Filing Date: The case number indicates a 2024 filing year.
   • Plaintiff(s): Not explicitly stated in the provided information.
   • Defendant(s): Not explicitly stated in the provided information.
   • Outcome or Current Status: Filed

Proceedings overview

One AIA trial proceeding has been filed against US patent 9560177. The proceeding is IPR2025-01285, which received a discretionary denial. This means the patent's claims remain untested and unhardened by PTAB review.

IPR2025-01285 — [Dell Technologies Inc. et al](/litigations/by-defendant/Dell%20Technologies%20Inc.%20et%20al). v. Cloud Byte LLC

• Type: Inter Partes Review
• Filed: 2025-07-14
• Status: Discretionary Denial. This indicates the PTAB declined to institute the IPR based on discretionary factors, rather than the merits of the petition's patentability challenges.
• Judge panel: Not publicly available at this time.
• Petition grounds: Not publicly available given the discretionary denial, as the merits were not fully adjudicated.
• Institution decision: Denied (Discretionary Denial). The petition was denied on 2026-01-15 due to procedural reasons.
• Final Written Decision: Not applicable, as institution was denied.
• Settlement / termination: Not applicable, as institution was denied.
• Appeal: Not applicable, as institution was denied.
• Defensive value: The patent owner prevailed, meaning the patent's claims have not been challenged or altered through this IPR. An IPR-based defense will be harder for future petitioners if the basis for the discretionary denial is applicable to their own circumstances.

Strategic summary

All claims of US patent 9560177 remain untested by PTAB review because the sole IPR filed against it, IPR2025-01285, was denied institution on discretionary grounds. There are no canceled or sustained claims as a result of PTAB proceedings.

The estoppel landscape is minimal due to the discretionary denial. Dell Technologies Inc. and its privies would be estopped under § 315(e)(2) from raising the specific grounds they raised in IPR2025-01285. However, because the denial was discretionary and not on the merits of the prior art, the specific prior-art grounds and statutory bases (§ 102 / § 103) were not fully adjudicated. Other potential petitioners would likely not be estopped from challenging the claims of 9560177 on any grounds, including those raised in the denied petition, provided they are not in privy with Dell Technologies Inc. et al.

There is no pattern of PTAB activity to observe beyond this single discretionary denial. The patent owner, Cloud Byte LLC, has not had to defend the patent on the merits before the PTAB. The petitioner was Dell Technologies Inc. et al., suggesting a defensive aggregator like Unified Patents was involved, as Unified Patents is listed as the petitioner for IPR2025-01285 in the Google Patents litigation data.

Recommended next steps

The PTAB proceeding IPR2025-01285 was denied institution on discretionary grounds on 2026-01-15. This means the patent claims were not evaluated on their merits. For a defendant facing assertion of this patent, the full breadth of prior-art grounds remains available for a potential IPR challenge. Any future IPR petition would need to carefully consider and address the specific reasons for the discretionary denial in IPR2025-01285 to avoid a similar outcome.

Details about the IPR can be found on the Unified Patents portal: https://portal.unifiedpatents.com/ptab/case/IPR2025-01285

Inventors

• Masaharu Morimoto (NEC Corp)

No unusual patterns noted based on available information.

Original assignee

NEC Corp. It is unclear from the patent text whether NEC Corp. shipped a product embodying the claims. NEC Corporation is a Japanese multinational information technology and electronics corporation. NEC Corporation is currently operating.

Assignment timeline

• 2023-12-13 (executed) / recorded 2023-12-22 — Reel 066124/0752

  • Conveyance: Assignment
  • Assignor: NEC CORPORATION
  • Assignee: NEC ASIA PACIFIC PTE LTD.
  • Correspondent: KEVIN K. CHEN, W&H Global Law Group, 608 SW 2nd Ave, Suite 600, Portland OR 97204
  • Context: Internal reorg

• 2024-01-18 (executed) / recorded 2024-01-27 — Reel 066376/0276

  • Conveyance: Assignment
  • Assignor: NEC ASIA PACIFIC PTE LTD.
  • Assignee: IP WAVE PTE LTD.
  • Correspondent: KEVIN K. CHEN, W&H Global Law Group, 608 SW 2nd Ave, Suite 600, Portland OR 97204. This correspondent recurs in this chain.
  • Context: Transfer-to-asserter (likely)

• 2024-03-05 (executed) / recorded 2024-06-27 — Reel 067944/0332

  • Conveyance: Assignment
  • Assignor: IP WAVE PTE LTD.
  • Assignee: CLOUD BYTE LLC.
  • Correspondent: KEVIN K. CHEN, W&H Global Law Group, 608 SW 2nd Ave, Suite 600, Portland OR 97204. This correspondent recurs in this chain.
  • Context: Transfer-to-asserter (likely)

Timeline diagram

timeline
    title Ownership of US 9560177
    2016 : Filed by NEC Corp
    2017 : Issued
    2023 : Assigned to NEC Asia Pacific Pte Ltd
    2024 : Assigned to IP WAVE PTE LTD
         : Assigned to CLOUD BYTE LLC

NPE / troll-pattern signals

1. Shell-entity transfer — present. IP WAVE PTE LTD. and CLOUD BYTE LLC are likely shell entities. IP WAVE PTE LTD. is a common form for intellectual property holding companies. Cloud Byte LLC has no obvious product presence and its address is associated with a registered agent service based on common patterns, and the transfer from a known operating company to this entity.
2. Known asserter in the chain — unclear. While Cloud Byte LLC is the current assignee, it is not explicitly listed on widely known public NPE lists such as RPX or Unified Patents. However, Unified Patents records two litigation cases in the Texas Eastern District Court and an IPR filing against this patent. This strongly suggests assertion activity, even if Cloud Byte LLC isn't on a general NPE list.
3. Repeat correspondent across the chain — present. KEVIN K. CHEN of W&H Global Law Group is the correspondent for all three recorded assignments (Reel 066124/0752, Reel 066376/0276, and Reel 067944/0332).
4. Cascading transfers — present. There are three consecutive assignments within a short period: 2023-12-13 to 2024-01-18 to 2024-03-05.
5. Pre-litigation transfer — present. The assignment to CLOUD BYTE LLC was executed on 2024-03-05 and recorded on 2024-06-27. Unified Patents records a US case filed in the Texas Eastern District Court (case 2:24-cv-00637). While the exact filing date of this specific case isn't provided in the Google Patents legal events, the timeline of the assignment preceding the litigation aligns with this pattern.
6. Bankruptcy fire-sale — not present. No indication of bankruptcy for the original assignee, NEC Corp.
7. Privateering — unclear. While the patent has moved from an operating company to what appear to be licensing entities, there is no direct evidence (e.g., SEC filings) to confirm privateering activity where NEC Corp. is secretly funding the assertion.
8. Defensive aggregator (anti-NPE) — not present. The chain does not terminate at a known defensive aggregator.

Verdict

NPE — high confidence

This verdict is based on multiple strong signals: the presence of apparent shell entities (IP WAVE PTE LTD. and CLOUD BYTE LLC) in the assignment chain, the repeated appearance of the same correspondent attorney, KEVIN K. CHEN, the cascading transfers within a short timeframe, and the pre-litigation transfer to Cloud Byte LLC followed by active litigation against the patent.

Verification: https://assignmentcenter.uspto.gov/

As a technical patent analyst, I have searched the USPTO database for US patent 9560177. The patent, titled "Network system and network flow tracing method," was granted on January 31, 2017.

The patent references numerous prior art documents, which are listed in the "Citations" section of the patent document. To identify the most relevant prior art, I will focus on the references cited by the examiner, as these were considered pertinent during the patent's prosecution.

Here's an analysis of the most relevant patent citations, focusing on those that could potentially anticipate claims under 35 U.S.C. § 102:

Most Relevant Prior Art for US9560177

1. US20090138610A1 (Matsushita Electric Industrial Co., Ltd.)

   • Full Citation: US20090138610A1
   • Publication/Filing Date: Filed September 29, 2005 / Published May 28, 2009
   • Brief Description: This patent application describes an information processing system, tunnel communication device, tunnel communication method, and program, focusing on tunnel communication, which involves encapsulating packets.
   • Potential Anticipated Claim(s): This patent potentially anticipates aspects of claims 1, 7, 13, and 19 related to the encapsulation of packets and the use of an additional header when a packet is a target of encapsulation. For example, claim 1 states, "...duplicate a part of a header of the identified packet as an additional header when the identified packet comprises a target of encapsulation; encapsulate the identified packet by the additional header...". The description of US20090138610A1 regarding "tunnel communication device" and "tunnel communication method" implies the handling and encapsulation of packets, which might contain similar concepts to the "duplicating a part of a header" and "encapsulating" steps in US9560177.

2. JP2005210518A (Matsushita Electric Works Ltd)

   • Full Citation: JP2005210518A
   • Publication/Filing Date: Filed January 23, 2004 / Published August 4, 2005
   • Brief Description: This Japanese patent discloses a transmission source tracing data providing apparatus and a transmission source tracing apparatus, specifically as an apparatus which carries out IP trace-back. The background art section of US9560177 discusses this patent literature as a method for IP trace-back, noting that it requires a mechanism in the header translating unit to transmit address translation data to the outside, which is a difficulty the present invention aims to overcome.
   • Potential Anticipated Claim(s): This prior art could potentially anticipate elements related to the overall goal of "network flow tracing" and "sending header information to the control apparatus" as described in claims 2, 8, 14, and 20. While JP2005210518A addresses trace-back, the method of achieving it differs, particularly in requiring modification of the header translating unit, which US9560177 seeks to avoid. However, the fundamental concept of tracing and providing translation data is present.

3. US20100161795A1 (Kindsight)

   • Full Citation: US20100161795A1
   • Publication/Filing Date: Filed December 22, 2008 / Published June 24, 2010
   • Brief Description: This patent application describes an apparatus and method for multi-user NAT session identification and tracking. This directly relates to the problem US9560177 addresses regarding header translation (NAT/NAPT) and maintaining flow visibility.
   • Potential Anticipated Claim(s): This reference is highly relevant to claims 2, 6, 8, 11, 12, 14, 17, and 18, which deal with sending header information (including before and after translation) to a control apparatus and the translation of header data. The stated objective of "multi-user NAT session identification and tracking" aligns closely with the problem US9560177 aims to solve by acquiring header translation data without modifying the header translating unit.

4. WO2010090182A1 (NEC Corporation)

   • Full Citation: WO2010090182A1
   • Publication/Filing Date: Filed February 3, 2009 / Published August 12, 2010
   • Brief Description: This international patent application by the original assignee (NEC Corp) of US9560177, describes an application switch system and an application switch method. This indicates previous work by the same entity in related areas of network control and switching.
   • Potential Anticipated Claim(s): Given the common assignee, this document likely shares foundational concepts with US9560177. It could potentially anticipate aspects of claims 1, 7, 13, and 19 related to the overall "switch apparatus" and "communication system" with a controller receiving rules and actions, identifying packets, and processing them based on actions. The specific "encapsulation" aspect might be a distinguishing feature.

5. WO2010103909A1 (NEC Corporation)

   • Full Citation: WO2010103909A1
   • Publication/Filing Date: Filed March 9, 2009 / Published September 16, 2010
   • Brief Description: Another international patent application by NEC Corporation, this describes an OpenFlow communication system and OpenFlow communication method. US9560177 specifically references OpenFlow network systems as an example of a CU separation type network system it deals with.
   • Potential Anticipated Claim(s): This is highly relevant to the entire patent, particularly claims concerning the network system, switch apparatus, and communication method, as US9560177 is explicitly designed for OpenFlow environments. It could anticipate various aspects of the system's architecture and packet handling within an OpenFlow context, potentially requiring a closer examination of the specific encapsulation and header translation data acquisition features to differentiate.

These references highlight that the problems of flow tracing and header translation in complex networks, particularly in OpenFlow environments, were known prior to US9560177. The inventiveness of US9560177 largely rests on its specific method of using a duplicate header for encapsulation to acquire translation data without modifying the header translating unit, thereby allowing for end-to-end flow tracing.

Obviousness Analysis of US Patent 9560177 Under 35 U.S.C. § 103

This analysis identifies combinations of prior art references that would render the claims of US patent 9560177 obvious to a person having ordinary skill in the art (PHOSITA) at the time of the invention (priority date of February 17, 2011). The primary references considered are Non-Patent Literature 1 ("OpenFlow Switch Specification, Version 1.0.0") and Patent Literature 1 (JP 2005-210518A), both cited in US9560177B2.

Background and Problem Addressed by US9560177B2

US9560177B2 addresses the challenge of tracing network flows in complex environments, particularly when packets pass through network appliances like Network Address Translation (NAT) and Network Address Port Translation (NAPT) units. These "header translating units" modify packet headers, making it difficult to monitor and control end-to-end flows. The patent notes that existing solutions, such as referring to address translation tables or using IP trace-back (as in JP 2005-210518A), typically require modifications to the header translating units themselves, which is often impractical or difficult to realize.

The stated object of US9560177B2 is "to provide a network system and a network flow tracing method in which a packet is encapsulated by using the same header as a current header in a switch, and has two kinds of headers before translation and after the translation after passing through a network appliance" without remodeling the network appliance.

Obviousness Argument

A PHOSITA in 2011 would have been well-versed in network systems, including the emerging concepts of Software-Defined Networking (SDN) and OpenFlow, as well as traditional networking challenges like NAT traversal and flow tracing.

Combination of Non-Patent Literature 1 and General Knowledge of Encapsulation for Solving a Known Problem:

• Non-Patent Literature 1 (NPL1): "OpenFlow Switch Specification, Version 1.0.0" (December 31, 2009)
  NPL1 describes the core components and operations of an OpenFlow network system. This includes a controller that sets rules and actions in flow tables of switches, and switches that process packets based on these rules and actions. NPL1 teaches that OpenFlow switches can perform various actions, including "rewriting a header". This document establishes the foundational programmable network infrastructure.

• General Knowledge of Network Address Translation (NAT/NAPT) and Encapsulation:
  The background of US9560177B2 itself acknowledges that "equipments having a function of NAT (Network Address Translation) and NAPT (Network Address Port Translation) translate a packet header." It also states that "a method of using header translation data retained by the header translating unit is known." The concept of encapsulation (also known as tunneling), where one packet is wrapped inside another packet, was a well-established networking technique for various purposes like creating Virtual Private Networks (VPNs) or enabling communication between incompatible networks. The patent even mentions Generic Routing Encapsulation (GRE) as a method for encapsulation.

• Motivation to Combine:
  A PHOSITA would have been motivated to combine the programmable capabilities of an OpenFlow network (NPL1) with the known techniques of encapsulation to address the recognized problem of tracing flows through header translating units (NAT/NAPT) without requiring modifications to those units. The challenge presented by NAT/NAPT altering headers and breaking end-to-end flow visibility was a known concern in network management.

  Given that NAT/NAPT devices primarily modify the outermost header of a packet, a PHOSITA seeking to preserve the original header information for tracing purposes would find it obvious to encapsulate the original packet within another packet. To effectively link the pre-translation and post-translation flows, the original header (or a critical part of it) would need to be preserved. Duplicating the original header and using it as an inner header within an encapsulated packet would be a logical and straightforward way to achieve this preservation.

  The programmable nature of OpenFlow switches (NPL1), which allows for flexible packet processing and header manipulation (e.g., "rewriting a header"), provides the means to implement such encapsulation and decapsulation operations. The controller (NPL1) could instruct an upstream OpenFlow switch to perform this encapsulation for specific flows identified as needing tracing, and a downstream OpenFlow switch to decapsulate and extract the translation information.

Addressing Independent Claims:

All independent claims (Claim 1, Claim 7, Claim 13, and Claim 19) share the core inventive concept of a switch or method performing the steps of identifying a packet, duplicating part of its header, and encapsulating the packet with the duplicated header.

• "a storage storing a table, the table including rules and actions corresponding to the rules": This is directly taught by OpenFlow specification (NPL1), which describes flow tables, rules, and actions.
• "a controller comprising: a memory storing instructions; and a processor configured to execute the instructions to: receive the rules and the actions from a control apparatus": These are standard components and functionalities of an OpenFlow switch under the control of an OpenFlow controller (NPL1).
• "identify, based on the rules, a received packet": An intrinsic function of an OpenFlow switch (NPL1).
• "duplicate a part of a header of the identified packet as an additional header when the identified packet comprises a target of encapsulation" and "encapsulate the identified packet by the additional header": While NPL1 does not explicitly detail duplicating headers for tracing, a PHOSITA motivated to overcome the NAT/NAPT tracing problem would find this obvious. Knowing that NAT/NAPT modifies the outer header, and that encapsulation is a known way to "hide" or preserve inner packet content, it would be an obvious design choice to duplicate the original header to serve as the inner, untranslated header for an encapsulated packet. This ensures that the original flow information is retained through the NAT/NAPT for later comparison. The OpenFlow switch's ability to "rewrite a header" (NPL1) demonstrates the capability to modify headers for such an encapsulation task.
• "process, based on the actions, the identified packet": A fundamental operation of an OpenFlow switch (NPL1).

Regarding the "sending header information to the control apparatus when the identified packet comprises an encapsulated packet" (Claims 2, 8, 14, 20) and "decapsulate the encapsulated packet" (Claims 4, 10, 16), these would be obvious extensions once the encapsulation mechanism is in place. After a packet passes through the header translating unit, a downstream switch would naturally need to decapsulate it to extract the original header and then transmit this information (along with the newly translated outer header) to the controller for flow tracing.

Conclusion

The core inventive step of US9560177B2—duplicating a packet header for encapsulation within a switch to enable flow tracing across header translating units without modifying those units—would have been obvious to a PHOSITA by combining the known programmable network architecture of OpenFlow (NPL1) with general knowledge of encapsulation and the recognized problem of NAT/NAPT complicating flow tracing. The motivation for such a combination arises from the clear need to achieve end-to-end flow visibility in dynamic networks, a problem that existing solutions like those in JP 2005-210518A failed to solve without requiring modifications to third-party network appliances.

Patent Term Adjustments (PTA) and Extensions (PTE) for US9560177

Patent Term Adjustments (PTA)

Patent Term Adjustment (PTA) compensates patent applicants for delays incurred during the prosecution of a patent application by the United States Patent and Trademark Office (USPTO). This applies to utility and plant patents filed on or after May 29, 2000. The total PTA is added to the standard 20-year term of the patent from its earliest priority filing date.

For US patent 9560177, the Google Patents information does not explicitly state the amount of Patent Term Adjustment (PTA) granted. However, the anticipated expiration date of "2031-12-08" already reflects any granted PTA, as PTA is automatically calculated and applied at the time of patent grant.

Patent Term Extensions (PTE)

Patent Term Extension (PTE) is designed to restore patent term lost due to delays in obtaining regulatory approval for certain products, such as human drugs, medical devices, and food additives, from agencies like the FDA. This process involves a separate application by the patent holder.

Based on the available information for US patent 9560177, there is no indication that any Patent Term Extension (PTE) has been applied for or granted. This type of patent term extension is typically applicable to patents covering products requiring pre-market regulatory review, and there's no mention of such a product or regulatory approval process associated with this patent.

Continuation and Divisional Applications

• Continuation Applications: A continuation application is a second application for the same invention claimed in a prior non-provisional application and filed before the patenting or abandonment of or termination of proceedings on the first application. The later-filed application benefits from the filing date of the original application.
  US9560177B2 is identified as a Continuation Application of U.S. patent application Ser. No. 13/983,001, filed on Jul. 31, 2013. This parent application, in turn, is based on International Application No. PCT/JP2011/078439, filed on Dec. 8, 2011, which is based on Japanese Patent Application No. 2011-031752, filed on Feb. 17, 2011.

• Divisional Applications: A divisional application is a type of continuing application filed when an earlier application claimed two or more independent and distinct inventions, and the USPTO required the applicant to restrict the application to one of them. The other inventions can then be pursued in divisional applications.
  The provided information for US9560177 does not explicitly mention any divisional applications.

Related Family Members

The patent family for US9560177B2 includes several related applications and patents across different jurisdictions, all stemming from the same priority date.

• Priority Application: JP2011-031752 (filed 2011-02-17)
• International Application: PCT/JP2011/078439 (filed 2011-12-08, published as WO2012111222A1)
• Parent US Applications:
  • US13/983,001 (filed 2013-07-31, issued as US9313128B2)
• Other Published Versions/Family Members:
  • US20160198025A1 (publication of US15/072,558)
  • CN103380600B
  • EP2677705A4
  • JP5565476B2

Projected Expiration Date

The "Anticipated expiration" date listed for US patent 9560177 is 2031-12-08. This date is typically calculated as 20 years from the earliest priority date (February 17, 2011, from JP2011-031752) plus any Patent Term Adjustment (PTA) and minus any applicant delays.

It should be noted that the "Priority date" listed on Google Patents is 2011-02-17, corresponding to JP2011-031752. The International Application PCT/JP2011/078439 was filed on 2011-12-08. Given the listed expiration date, it is likely that the PTA calculation is based on the priority date of the Japanese application or the international application.

Defensive Disclosure for US Patent 9560177

This document outlines derivative variations and combination prior art scenarios for US patent 9560177, titled "Network system and network flow tracing method." The goal is to generate defensive disclosures that render future incremental improvements by competitors obvious or non-novel, based on the core inventive concept of duplicating a packet header for encapsulation within a switch to enable flow tracing through header translating units (NAT/NAPT) in a software-defined networking (SDN) environment like OpenFlow.

The analysis focuses on variations of the core mechanism described in independent claims 1, 7, 13, and 19. Since these claims largely cover the same inventive concept from apparatus, system, method, and computer-readable medium perspectives, the derivatives will apply broadly across these claim types.

Derivative Variations

1. Material & Component Substitution

Derivative 1.1: FPGA-Accelerated Encapsulation Module

• Enabling Description: A switch apparatus (Claim 1) or communication system (Claim 7) is implemented where the encapsulating module (21-1, 21-2) functionality, specifically the packet identification, header duplication, and encapsulation/decapsulation logic, is offloaded to a field-programmable gate array (FPGA) or an application-specific integrated circuit (ASIC) integrated directly into the network interface controller (NIC) or switch fabric. The FPGA/ASIC contains hardwired logic blocks or reconfigurable logic cells programmed in Hardware Description Language (HDL) (e.g., VHDL, Verilog) to perform header parsing, buffering, duplication, and re-assembly at line rate, significantly reducing latency and increasing throughput compared to a software-based processor execution (Claim 1, processor configured to execute instructions). The control apparatus (Claim 7) would load specific bitstreams or configurations to the FPGA/ASIC to define encapsulation targets and header duplication rules. This substitution maintains the core method (Claim 13) but optimizes the "duplicating a part of a header" and "encapsulating" steps for high-performance network segments.

flowchart TD
    A[Received Packet] --> B{Packet Identification (FPGA)};
    B -- Is Encapsulation Target? --> C{Duplicate Header Logic (FPGA)};
    C --> D[Encapsulated Packet];
    D --> E[Switch Fabric Output];
    F[Control Apparatus] --> G[FPGA/ASIC Configuration];
    G --> B;
    G --> C;

Derivative 1.2: eBPF-Managed Encapsulation

• Enabling Description: The switch apparatus (Claim 1) or communication method (Claim 13) leverages extended Berkeley Packet Filter (eBPF) programs for dynamic, in-kernel packet processing. Instead of traditional flow table entries directly controlling hardware, the control apparatus (Claim 7) compiles and loads eBPF programs into the kernel of the switch's operating system. These eBPF programs intercept packets at a specified hook point (e.g., XDP or TC), identify encapsulation targets based on predefined maps (e.g., hash maps for flow identifiers), duplicate relevant header fields (e.g., sk_buff manipulation in Linux kernel), and perform generic routing encapsulation (GRE) or Virtual Extensible LAN (VXLAN) tunneling. Decapsulation and header information extraction are also performed by eBPF programs, transmitting metadata via perf_event_output to user-space agents for relay to the controller. This substitutes the direct "processor executing instructions" for a more flexible, programmable, and efficient kernel-level packet processing mechanism.

sequenceDiagram
    participant P as Packet Ingress
    participant S as Switch Kernel (eBPF)
    participant U as User Space Agent
    participant C as Controller
    P->>S: Packet Received
    S->>S: Identify Target (eBPF Map Lookup)
    alt Encapsulation Target
        S->>S: Duplicate Header (eBPF Program)
        S->>S: Encapsulate Packet (GRE/VXLAN)
        S->>U: Send Metadata (perf_event_output)
    else Not Target
        S->>S: Forward Packet
    end
    S->>P: Packet Egress
    U->>C: Header Translation Data
    C->>S: Update eBPF Maps/Programs

Derivative 1.3: Quantum-Resistant Encapsulation Protocol

• Enabling Description: The network system (Claim 7) employs a quantum-resistant cryptographic encapsulation protocol for the additional header (Claim 1), specifically for securing the integrity and confidentiality of the duplicated header when sensitive flow tracing is required. Instead of standard GRE or VXLAN, the encapsulation involves a post-quantum cryptography (PQC) layer. For instance, the duplicated header (First Header) could be hashed using a collision-resistant PQC algorithm (e.g., a hash from the NIST PQC standardization process) and included as a metadata field in the outer (Second) header's options or a custom tunneling protocol. Alternatively, the entire encapsulated packet could be encrypted with a PQC key exchange mechanism (e.g., CRYSTALS-Kyber) and a symmetric PQC cipher, ensuring that only authorized encapsulating modules and controllers can extract or verify the original flow information, even against future quantum computing attacks. The switch processor (Claim 1) would execute PQC algorithms for secure header manipulation.

classDiagram
    class Packet {
        +OriginalHeader
        +Payload
    }
    class EncapsulatedPacket {
        +OuterHeader (PQC-Secured)
        +InnerOriginalHeader
        +Payload
    }
    class SwitchProcessor {
        +PQCKeyExchange()
        +PQCHash(data)
        +PQCEncrypt(data, key)
    }
    Packet --|> EncapsulatedPacket : is encapsulated by
    SwitchProcessor ..> Packet : processes
    SwitchProcessor ..> EncapsulatedPacket : generates/decapsulates

2. Operational Parameter Expansion

Derivative 2.1: Hyperscale Data Center Flow Tracing

• Enabling Description: The network system (Claim 7) operates within a hyperscale data center environment managing millions of concurrent flows and dynamic virtual network overlays. The switch apparatus (Claim 1) is designed to handle packet rates exceeding 1 Terabit per second (Tbps) with header duplication and encapsulation performed within 100 nanoseconds latency. This requires highly optimized packet processing pipelines, potentially utilizing specialized network processing units (NPUs) with deep packet inspection (DPI) capabilities and parallel processing cores. The control apparatus (Claim 7) employs machine learning algorithms to predict high-value flows for encapsulation, dynamically adjusting the "target of encapsulation" rules based on real-time traffic analytics and policy enforcement. The "additional header" (Claim 1) is compacted to minimize overhead, potentially using bitmasking or delta encoding for redundant fields.

graph TD
    A[Ingress 1Tbps Traffic] --> B(NPU Pipeline);
    B --> C{Flow Identify & Rule Match};
    C -- Encapsulation Target --> D{Header Duplicate & Encapsulate (100ns)};
    D --> E[Egress Packet];
    C -- Not Target --> F[Forward Packet];
    E --> G[Controller (ML-driven Policy)];
    G --> C;

Derivative 2.2: Ultra-Low Latency Financial Trading Networks

• Enabling Description: The network flow tracing method (Claim 13) is applied to ultra-low latency financial trading networks where propagation delay is critical (e.g., sub-microsecond latency requirements). The "part of a header" to be duplicated (Claim 13) includes precise timestamping information from a network time protocol (NTP) synchronized clock source, accurate to picoseconds, captured at the ingress switch. The encapsulation process is executed with minimal jitter and deterministic latency guarantees by dedicated hardware elements. The "additional header" contains not only the original header but also a high-resolution sequence number and a cryptographic nonce, ensuring replay protection and precise ordering for audit trails. The header translation data transmitted to the controller (Claim 14) includes the original and translated headers along with ingress/egress timestamps and latency measurements, enabling precise analysis of trading flow delays induced by network appliances.

sequenceDiagram
    participant S_IN as Ingress Switch
    participant NAT as Header Translating Unit
    participant S_OUT as Egress Switch
    participant C as Controller
    S_IN->>S_IN: Receive Packet (H1, P)
    S_IN->>S_IN: Timestamp T1 (Picosecond)
    S_IN->>S_IN: Duplicate H1 as H_INNER
    S_IN->>S_IN: Encapsulate (H1, (H_INNER, P))
    S_IN->>NAT: Transmit Encapsulated Packet
    NAT->>NAT: Translate Outer H1 to H2
    NAT->>S_OUT: Transmit (H2, (H_INNER, P))
    S_OUT->>S_OUT: Receive Packet
    S_OUT->>S_OUT: Timestamp T2 (Picosecond)
    S_OUT->>S_OUT: Decapsulate, Extract H_INNER, H2
    S_OUT->>C: Send Header Translation Data (H1=H_INNER, H2, T1, T2)
    S_OUT->>S_OUT: Replace H_INNER with H2, Forward (H2, P)

Derivative 2.3: Satellite Constellation Mesh Networks

• Enabling Description: The network system (Claim 7) consists of a mesh of low Earth orbit (LEO) satellites forming an inter-satellite link (ISL) network. Each satellite functions as a switch apparatus (Claim 1) where the processor and storage are radiation-hardened components. Due to dynamic topology and varying link qualities, header duplication and encapsulation rules (Claim 1) are frequently updated by a ground-based control apparatus (Claim 7) via secure command uplinks. The "additional header" includes satellite orbital parameters, beamforming metadata, and a redundant coding scheme to ensure reliability over high-bit-error-rate ISL connections. Flow tracing is critical for link budget analysis, constellation resource allocation, and anomaly detection. The encapsulation is performed using a custom space-optimized tunneling protocol over optical or radio frequency ISLs.

graph LR
    GroundControl --> SatelliteA(LEO Switch A);
    GroundControl --> SatelliteB(LEO Switch B);
    SatelliteA -- ISL --> SatelliteB;
    SatelliteA -- Encapsulation & Tracing --> SatelliteB;
    subgraph LEO Satellite Network
        SatelliteA --> SatAppliance(Space-borne NAT/NAPT);
        SatAppliance --> SatelliteB;
    end

3. Cross-Domain Application

Derivative 3.1: Autonomous Vehicle Network Diagnostics

• Enabling Description: In an autonomous vehicle's internal network (e.g., Automotive Ethernet, CAN bus over IP), the vehicle's central gateway acts as a switch apparatus (Claim 1). It has a processor that identifies packets (e.g., sensor data, control commands) from various Electronic Control Units (ECUs). When a packet is identified as critical for diagnostics (e.g., LiDAR data, brake command) and passes through an internal translation unit (e.g., IP to proprietary bus protocol bridge, or internal NAT for legacy ECU integration), a part of its header (e.g., source ECU identifier, command ID, timestamp) is duplicated and encapsulated. This allows the vehicle's diagnostic control unit (acting as the control apparatus, Claim 7) to trace the exact original source and content of commands and data flows through internal translation layers without modifying individual ECUs or proprietary buses. This is vital for debugging, compliance, and post-incident analysis.

flowchart LR
    ECU1(LiDAR ECU) --> Gateway(Switch Apparatus);
    ECU2(Brake ECU) --> Gateway;
    Gateway --> TranslationUnit(Internal NAT/Protocol Bridge);
    TranslationUnit --> Actuators(Wheel Motors, Brakes);
    Gateway -- Encapsulate & Trace Flow --> DiagnosticUnit(Control Apparatus);

Derivative 3.2: Smart Grid SCADA Communication Integrity

• Enabling Description: Within a Smart Grid's Supervisory Control and Data Acquisition (SCADA) network, intelligent electronic devices (IEDs) and Remote Terminal Units (RTUs) communicate with a central control center. A network gateway at a substation acts as a switch apparatus (Claim 1). This gateway monitors SCADA packets (e.g., Modbus/TCP, DNP3 over IP) that might undergo NAT/NAPT translation by secure network appliances (e.g., firewalls) before reaching the control center. For critical control commands (e.g., trip breaker, change setpoint), the gateway duplicates a portion of the packet's SCADA header (e.g., function code, register address, IED ID) and encapsulates it. The control center's network monitoring system (control apparatus, Claim 7) receives the header translation data, allowing it to verify the original command parameters even after passing through security appliances, ensuring command integrity and aiding in forensic analysis of cyber-physical attacks or misconfigurations without modifying the SCADA devices or firewalls.

graph TD
    IED_RTU(Substation IED/RTU) --> SubstationGateway(Switch Apparatus);
    SubstationGateway --> Firewall(Header Translating Unit);
    Firewall --> ControlCenter(SCADA Control Apparatus);
    SubstationGateway -- Encapsulated SCADA Flow --> ControlCenter;

Derivative 3.3: High-Throughput Genomic Sequencing Data Pipelines

• Enabling Description: In a large-scale genomic sequencing facility, raw sequencing data (e.g., FASTQ, BAM files chunked into packets) are streamed from sequencers to high-performance computing (HPC) clusters for analysis. A specialized network switch (Claim 1) handling these data flows might encounter header translating units (e.g., specialized storage network gateways, data format converters performing header-like metadata translation). For tracing the provenance and integrity of specific genomic data streams, a portion of the original packet header (e.g., sample ID, sequencer run ID, read group) is duplicated and encapsulated. The bioinformatics workflow management system (control apparatus, Claim 7) uses this tracing method to monitor the flow of data through various network and processing stages, verifying that the correct original sample data reaches its intended analytical pipeline even if network addresses or internal identifiers are translated along the way.

flowchart TD
    Sequencer(Genomic Sequencer) --> DataSwitch(Switch Apparatus);
    DataSwitch --> StorageGateway(Header Translating Unit);
    StorageGateway --> HPC_Cluster(Bioinformatics Control Apparatus);
    DataSwitch -- Encapsulated Genomic Data Flow --> HPC_Cluster;

4. Integration with Emerging Tech

Derivative 4.1: AI-Driven Dynamic Encapsulation Policy Optimization

• Enabling Description: The network system (Claim 7) integrates an AI-driven optimization engine with the control apparatus (Claim 7). This AI engine continuously analyzes network telemetry, application performance metrics, and historical flow tracing data (header translation data from Claims 2, 8, 14, 20). Using reinforcement learning or predictive analytics, the AI dynamically adjusts the "target of encapsulation" rules (Claim 1) in real-time. For instance, if the AI detects an emerging bottleneck or an anomaly pattern indicative of a specific application flow misbehaving after passing a NAT, it automatically updates the rules in upstream switches to encapsulate and trace only that problematic flow, minimizing overhead. This optimizes resource utilization by encapsulating only when and where necessary, adapting to changing network conditions and threat landscapes.

graph TD
    A[Network Telemetry] --> B(AI Optimization Engine);
    C[Header Translation Data] --> B;
    B --> D{Dynamic Encapsulation Rules};
    D --> E[Control Apparatus];
    E --> F[Switch Apparatus (Flow Tables)];
    F -- Packet Processing --> A;
    F -- Encapsulation --> C;

Derivative 4.2: IoT Sensor-Triggered Contextual Flow Tracing

• Enabling Description: The network system (Claim 7) is deployed in an industrial IoT environment. IoT sensors (e.g., environmental, machine health) are integrated such that their state changes can trigger network flow tracing. The control apparatus (Claim 7) receives real-time alerts from IoT platforms. If a critical sensor reading (e.g., abnormal temperature, machine fault) is detected, the control apparatus correlates this with active network flows related to that IoT device or associated control systems. It then instructs the relevant switch apparatuses (Claim 1) to immediately begin duplicating headers and encapsulating packets for those specific IoT-related flows. The "additional header" (Claim 1) may also include the IoT sensor ID and trigger event timestamp. This provides contextual network visibility, allowing operators to diagnose whether a network translation issue contributed to the IoT anomaly.

stateDiagram
    state "Normal Operation" as Normal
    state "IoT Anomaly Detected" as Anomaly
    state "Contextual Tracing Active" as Tracing
    state "Tracing Data Analysis" as Analysis

    Normal --> Anomaly : IoT Sensor Alert
    Anomaly --> Tracing : Controller Activates Encapsulation Rules
    Tracing --> Analysis : Header Translation Data Sent
    Analysis --> Normal : Issue Resolved / Tracing Deactivated
    Tracing --> Anomaly : Continued Anomaly

Derivative 4.3: Blockchain-Verified Header Translation Log

• Enabling Description: The network system (Claim 7) incorporates a blockchain-based immutable ledger for storing header translation data. After the encapsulating module (Claim 1) extracts the original and translated headers (Claims 2, 6, 8, 11, 12, 14, 17, 18), this "header translation data" is hashed (e.g., SHA-256) and cryptographically signed by the switch apparatus (using a private key associated with the switch). The signed hash, along with a timestamp and a reference to the block of data, is then submitted as a transaction to a permissioned blockchain network (e.g., Hyperledger Fabric) managed by the control apparatus (Claim 7) or a distributed network of trusted nodes. This creates an auditable, tamper-proof record of all header translations, crucial for regulatory compliance, security forensics, and non-repudiation in multi-party network environments, ensuring the integrity of the flow tracing information.

flowchart TD
    A[Encapsulating Module (Decap)] --> B[Generate Header Translation Data];
    B --> C[Hash & Sign Data (Switch)];
    C --> D[Submit Transaction to Blockchain];
    D -- Block Added --> E[Immutable Translation Log];
    E --> F[Controller (Audit/Verify)];

5. The "Inverse" or Failure Mode

Derivative 5.1: Graceful Degradation of Tracing Functionality

• Enabling Description: The switch apparatus (Claim 1) implements a graceful degradation mechanism for the network flow tracing method (Claim 13) under high network load or resource contention. Instead of failing outright or dropping packets, the controller (Claim 1) is configured to dynamically adjust the granularity or frequency of header duplication and encapsulation. For example, under overload, the system might switch from full header duplication to only duplicating a critical flow identifier (e.g., flow hash, source/destination IP pair). Alternatively, it might engage in statistical sampling, encapsulating only 1% of identified target packets instead of 100%. The "additional header" could also be truncated to minimal essential fields. This ensures that some level of flow tracing data is still collected, prioritizing network throughput while providing diagnostic insights, albeit at reduced detail.

stateDiagram
    state "Full Tracing (Normal)" as Full
    state "Reduced Header Detail" as ReducedHeader
    state "Packet Sampling" as Sampling
    state "Minimal Essential Fields" as Minimal
    state "No Tracing (Critical Overload)" as Off

    Full --> ReducedHeader : High Load / Resource Contention
    ReducedHeader --> Sampling : Further Load Increase
    Sampling --> Minimal : Severe Load Increase
    Minimal --> Off : Critical Overload / Fail-Safe
    Off --> Minimal : Load Decreases
    Minimal --> Sampling : Load Decreases
    Sampling --> ReducedHeader : Load Decreases
    ReducedHeader --> Full : Load Decreases

Derivative 5.2: Privacy-Preserving Selective De-Encapsulation

• Enabling Description: The network system (Claim 7) is designed for environments requiring strict privacy compliance (e.g., GDPR, HIPAA). The egress encapsulating module (Claim 1) performs "privacy-preserving selective decapsulation" based on policies set by the control apparatus (Claim 7). When decapsulating an encapsulated packet (Claims 4, 10, 16), it inspects the "additional header" (the duplicated original header). If specific fields (e.g., sensitive personal data in the payload, certain port numbers) within this inner header match a privacy rule, those fields are immediately anonymized, masked, or redacted before the header translation data is sent to the controller (Claim 2, 8, 14, 20). Only non-sensitive or aggregated tracing information is forwarded, ensuring that end-to-end flow tracing can occur for network diagnostics without compromising user privacy.

sequenceDiagram
    participant S_OUT as Egress Switch (Encapsulating Module)
    participant C as Controller (Policy Engine)
    participant L as Local Anonymizer
    S_OUT->>S_OUT: Receive Encapsulated Packet
    S_OUT->>S_OUT: Decapsulate, Extract Original Header H_INNER
    S_OUT->>C: Request Privacy Policy for H_INNER
    C-->>S_OUT: Privacy Policy (e.g., Mask IP)
    S_OUT->>L: Apply Anonymization/Masking to H_INNER
    L-->>S_OUT: Anonymized H_INNER
    S_OUT->>C: Send Header Translation Data (Anonymized H_INNER, Translated H_OUTER)

Derivative 5.3: Low-Power/Standby Mode with Event-Driven Tracing

• Enabling Description: The switch apparatus (Claim 1) operates in a power-constrained environment (e.g., remote edge device, battery-powered network sensor). In its default "low-power" or standby mode, the header duplication and encapsulation functions are disabled to conserve energy. The switch's processor (Claim 1) only performs basic packet forwarding. However, upon a specific trigger event (e.g., detection of a predefined anomaly signature, remote command from the control apparatus, or scheduled diagnostic window), the system transitions to an "event-driven tracing" mode. In this mode, the processor (Claim 1) re-enables the encapsulation logic for a limited duration or for a specific subset of flows. Once the diagnostic period is over or the anomaly subsides, the system reverts to low-power mode, disabling intensive tracing operations. The recording medium (Claim 19) would store instructions for managing these power states and dynamic rule activation.

stateDiagram
    state "Low-Power Idle (Tracing Disabled)" as Idle
    state "Event-Driven Tracing Active" as Active

    Idle --> Active : Trigger Event Detected
    Active --> Idle : Tracing Duration Expired / Event Resolved
    Idle --> Idle : Basic Packet Forwarding
    Active --> Active : Encapsulation & Tracing for Specific Flows

---

Combination Prior Art Scenarios

Here are three scenarios combining US patent 9560177 with existing open-source standards to generate further prior art:

1. US9560177 + OpenFlow (NPL1) + RFC 7348 (VXLAN: A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks)

• Combination: A network system (Claim 7) operating on OpenFlow (NPL1) principles and switches (Claim 1) utilizes VXLAN (RFC 7348) as the encapsulation protocol for the "additional header."
• Enabling Description: An OpenFlow controller (as the control apparatus) provisions rules (Claim 1) in OpenFlow switches (switch apparatus). For flows designated as "targets of encapsulation," the switch's encapsulating module (software or hardware) duplicates the original packet's Layer 2, 3, and 4 headers. This duplicated header, along with the original payload, is then encapsulated within a VXLAN header and UDP/IP header. The VXLAN Network Identifier (VNI) in the VXLAN header can be used to tag the flow tracing context. The external IP header of the VXLAN tunnel is subject to translation by a NAT/NAPT unit. Upon reception, a downstream OpenFlow switch, also configured by the controller, performs VXLAN decapsulation, extracts the original duplicated headers, and transmits this pre-translation information (original header, translated outer VXLAN IP header) to the controller for flow tracing. VXLAN is explicitly designed for network overlays and provides a clear mechanism for encapsulating inner frames, making its application for carrying a duplicated original header a straightforward extension in an OpenFlow context.

2. US9560177 + RFC 1701 / RFC 2784 (Generic Routing Encapsulation - GRE) + IETF IPFIX (IP Flow Information Export) Protocol

• Combination: A network system (Claim 7) uses GRE (RFC 1701 / RFC 2784) for packet encapsulation (Claim 1) and sends the generated "header translation data" (Claims 2, 8, 14, 20) to the controller using the IPFIX protocol.
• Enabling Description: Within an OpenFlow-managed network, an upstream switch apparatus (Claim 1) is instructed by the controller (Claim 7) to duplicate the original IP header of a target packet. This duplicated header and payload are then encapsulated using GRE. The outer GRE header contains the dynamically translated IP header. A downstream switch apparatus, after receiving the GRE encapsulated packet that has passed through a NAT/NAPT, performs GRE decapsulation. It then constructs IPFIX flow records. These records include observed data fields for both the original (inner) IP header and the translated (outer) IP header (before decapsulation). These IPFIX records, containing the pair of pre- and post-translation headers as "header translation data," are then exported to the controller (acting as an IPFIX collector) for comprehensive flow tracing and analysis. This combines standard tunneling with a standard flow telemetry export mechanism.

3. US9560177 + IEEE 802.1Q (VLAN Tagging) + RFC 863 (Discard Protocol)

• Combination: A switch apparatus (Claim 1) uses IEEE 802.1Q VLAN tags in the duplicated header for granular flow identification, and the "additional header" (the duplicated part) is sometimes redirected to a network tap implementing the Discard Protocol (RFC 863) for debugging.
• Enabling Description: The network system (Claim 7) handles Layer 2 traffic with IEEE 802.1Q VLAN tagging. When a switch apparatus (Claim 1) receives an Ethernet frame, its processor identifies the frame based on rules that can include VLAN ID. For encapsulation targets, the switch duplicates a "part of a header" that specifically includes the original Ethernet header and its 802.1Q tag. This duplicated information is then encapsulated (e.g., within an outer Ethernet frame or a simple tunneling protocol). In a diagnostic scenario, instead of sending the full header translation data to the controller, the encapsulated packet's duplicated header (the "additional header") is sometimes extracted and redirected to a special debugging port configured as a network tap. This tap is designed to simply "discard" (RFC 863 behavior) the redirected duplicated header for high-volume, quick-check diagnostics where storage/processing of full records is undesirable. This allows for simple presence detection of specific flows without full processing overhead, particularly useful for basic connectivity and translation verification.

---