Derivative works — US Patent 11589142

Here is the Defensive Disclosure document for US Patent 11,589,142.

Publication Date: May 14, 2026
Title: Methods and Systems for Enhanced Virtual Network Segmentation in Shared Optical Access Architectures
Keywords: Passive Optical Network (PON), Virtual Routing and Forwarding (VRF), Segment Routing (SRv6), Quantum Key Distribution (QKD), Software Defined Networking (SDN), P4 Programmable Switches, Network Function Virtualization (NFV), Industrial IoT (IIoT), System-on-Chip (SoC) Networking.

Introduction

This document discloses a series of methods, systems, and architectural variations that build upon the concepts of virtualized routing in passive optical networks. The purpose is to preemptively place in the public domain a wide range of derivative implementations, thereby rendering them obvious to a person skilled in the art. The disclosures that follow expand upon the core concept of using logically separate routing tables (such as those created by VRF) to isolate traffic for different users or tenants on a shared physical PON infrastructure.

Part 1: Derivative Disclosures for Hierarchical Router Architectures with Encapsulated Transport (Based on Claim 1)

1.1. Material & Component Substitution

1.1.1. Substitution of MPLS with Segment Routing (SRv6)

Enabling Description: The primary PON interface router encapsulates the IP data packages from a specific VRF instance directly into an IPv6 header containing a Segment Routing Header (SRH). Instead of swapping MPLS labels, the secondary router and any intermediate network elements simply forward the packet based on the active segment in the SRH. The secondary router, as the final segment endpoint, processes the SRH, removes the outer IPv6 header, and forwards the original IP package to the OLT. This simplifies the transport network by eliminating the LDP/RSVP-TE protocols required for MPLS and allows for network programming and service chaining by encoding the entire packet journey in the IPv6 header at the primary router. The primary router's VRF table is mapped to a specific SRv6 policy.

Mermaid Diagram:

sequenceDiagram
    participant UserDevice as User Device
    participant ONU
    participant OLT
    participant RouterSecondary as Secondary Router (SRv6 Endpoint)
    participant RouterPrimary as Primary Router (SRv6 Headend)

    UserDevice->>RouterPrimary: IP Packet
    activate RouterPrimary
    RouterPrimary->>RouterPrimary: Lookup VRF, apply SRv6 Policy
    RouterPrimary-->>RouterSecondary: Encapsulated IPv6 Packet with SRH
    deactivate RouterPrimary
    activate RouterSecondary
    RouterSecondary->>RouterSecondary: Process SRH, decapsulate
    RouterSecondary-->>OLT: Original IP Packet
    deactivate RouterSecondary
    OLT-->>ONU: Aggregated Optical Signal
    ONU-->>UserDevice: Extracted IP Packet

1.1.2. Quantum Key Distribution (QKD) for Primary-to-Secondary Router Link Security

Enabling Description: The physical communication link between the primary and secondary PON interface routers is secured using a Quantum Key Distribution (QKD) system. The QKD system generates and distributes provably random, single-use symmetric encryption keys to both routers. The primary router encrypts its outgoing data streams (containing MPLS or SRv6 encapsulated packets) using the quantum-derived key before transmission. The secondary router uses the corresponding key to decrypt the traffic. Any attempt to eavesdrop on the fiber link between the routers would disturb the quantum state of the photons, which is immediately detected by the QKD system, triggering an alarm and a key refresh. This provides physical layer security that is independent of and complementary to the logical separation provided by VRF.

Mermaid Diagram:

flowchart TD
    subgraph Primary Router
        A[VRF Separation] --> B{IP Packet}
    end
    subgraph Secondary Router
        G[Decryption] --> H[Forward to OLT]
    end
    subgraph QKD System
        K1[QKD Tx]
        K2[QKD Rx]
        K1 <--> K2
        K1 --> C
        K2 --> G
    end
    B --> C[AES-256 Encryption];
    C --> D(Fiber Link);
    D --> F[Encrypted Packet Reception];
    F --> G;

    style QKD System fill:#f9f,stroke:#333,stroke-width:2px

1.2. Operational Parameter Expansion

1.2.1. System-on-Chip (SoC) Implementation for Embedded Systems

Enabling Description: The entire architecture of primary router, secondary router, and a micro-OLT is miniaturized and implemented on a single System-on-Chip (SoC). This "PON-on-a-Chip" is designed for harsh, low-power environments like autonomous vehicles or drones. The primary router function, handling VRFs for critical subsystems (e.g., flight control, sensor data, communication), and the secondary router function are implemented as dedicated hardware blocks on the SoC. The link between them is an on-chip, high-speed serial interconnect (SerDes) that uses a lightweight MPLS or segment routing protocol. The micro-OLT block drives a small number of short-range optical or polymer fiber outputs to connect to various subsystems, each with its own micro-ONU. This provides robust, high-bandwidth, electrically isolated internal networking.

Mermaid Diagram:

graph TD
    subgraph Vehicle/Drone SoC
        direction LR
        PR[Primary Router Block<br>(VRFs for Subsystems)]
        SR[Secondary Router Block]
        mOLT[Micro-OLT Block]
        PR -- On-Chip SerDes Link<br>(Lightweight MPLS) --> SR
        SR -- On-Chip Bus --> mOLT
    end

    mOLT -- Polymer Fiber 1 --> ONU1[Micro-ONU<br>(Flight Control)]
    mOLT -- Polymer Fiber 2 --> ONU2[Micro-ONU<br>(Payload Sensors)]
    mOLT -- Polymer Fiber 3 --> ONU3[Micro-ONU<br>(Communications)]

1.3. Cross-Domain Application

1.3.1. Aerospace: Isolated Multi-Tenant Avionics Network

Enabling Description: On a large commercial aircraft, a primary router is located in the main avionics bay. It creates separate VRFs for: 1) Flight-critical systems (ARINC 664), 2) Cabin systems (in-flight entertainment, lighting), and 3) Passenger Wi-Fi. Data is encapsulated via MPLS and sent over a redundant fiber backbone to secondary routers located in different zones of the aircraft (e.g., cockpit, forward cabin, aft cabin). These secondary routers decapsulate the traffic and forward it to a zonal OLT, which distributes the signals to local ONUs connected to flight displays, passenger seatback screens, or wireless access points. This architecture ensures that a security breach on the passenger Wi-Fi network cannot propagate to flight-critical systems due to the hard logical separation enforced by the VRFs from the primary router.

Mermaid Diagram:

graph TD
    subgraph AvionicsBay as Avionics Bay
        R1(Primary Router)
        R1 --> VRF_Flight[VRF: Flight Critical]
        R1 --> VRF_Cabin[VRF: Cabin Systems]
        R1 --> VRF_Guest[VRF: Passenger WiFi]
    end

    subgraph CockpitZone as Cockpit Zone
        R2_C(Secondary Router) --> OLT_C(Zonal OLT)
        OLT_C --> ONU_Display[ONU: Flight Displays]
    end

    subgraph CabinZone as Cabin Zone
        R2_P(Secondary Router) --> OLT_P(Zonal OLT)
        OLT_P --> ONU_IFE[ONU: In-Flight Entertainment]
        OLT_P --> ONU_AP[ONU: WiFi Access Point]
    end

    VRF_Flight -- MPLS over Fiber --> R2_C
    VRF_Cabin -- MPLS over Fiber --> R2_P
    VRF_Guest -- MPLS over Fiber --> R2_P

1.4. Integration with Emerging Tech

1.4.1. AI-Driven Dynamic VRF and MPLS Path Provisioning

Enabling Description: A centralized AI/ML controller monitors network traffic patterns and security telemetry from the primary and secondary routers. When the AI detects anomalous traffic from a device within a specific VRF (e.g., a potential malware infection), it automatically triggers a policy change. The AI instructs the primary router to modify the MPLS path for that VRF to redirect its traffic through a virtualized network function (VNF) chain that includes a firewall, intrusion detection system (IDS), and packet capture service for forensic analysis. Once the threat is neutralized, the AI can restore the original, more direct MPLS path to reduce latency. This creates a self-defending network that responds to threats in real-time.

Mermaid Diagram:

sequenceDiagram
    participant AI as AI/ML Controller
    participant RouterPrimary as Primary Router
    participant VNF_IDS as IDS/Firewall VNF
    participant RouterSecondary as Secondary Router

    loop Continuous Monitoring
        RouterPrimary->>AI: Telemetry for VRF-A
    end

    AI->>AI: Detect Anomaly in VRF-A
    AI-->>RouterPrimary: API Call: "Modify VRF-A Path"
    activate RouterPrimary
    RouterPrimary->>RouterPrimary: Change MPLS labels for VRF-A
    deactivate RouterPrimary

    Note right of RouterPrimary: Traffic from VRF-A is now<br/>redirected to IDS/Firewall
    RouterPrimary->>VNF_IDS: MPLS-redirected Traffic
    VNF_IDS->>VNF_IDS: Inspect & Sanitize
    VNF_IDS-->>RouterSecondary: Clean Traffic

1.5. The "Inverse" or Failure Mode

1.5.1. Graceful Degradation upon Primary Router Failure

Enabling Description: The primary and secondary routers maintain a heartbeat protocol. If the secondary router detects a failure of the primary router, it initiates a "graceful degradation" mode. It bypasses its MPLS processing logic and reconfigures its OLT-facing interface to operate as a simple Layer 2 switch. It broadcasts a "Limited Functionality" message to all ONUs. All traffic is mapped to a single, pre-configured VLAN with no inter-tenant isolation and heavily rate-limited access only to essential services (e.g., DNS and a status webpage). This ensures that while the high-security, multi-tenant functionality is lost, basic connectivity for fault diagnosis or emergency communication is maintained until the primary router can be restored.

Mermaid Diagram:

stateDiagram-v2
    [*] --> Normal
    Normal: Primary Router Active<br>VRF & MPLS Enabled
    Degraded: Primary Router Failed<br>Basic L2 Switching<br>Single VLAN, Rate Limited

    Normal --> Degraded: Heartbeat Timeout
    Degraded --> Normal: Primary Router Restored

Part 2: Derivative Disclosures for Integrated Router-OLT Architectures (Based on Claims 5 & 8)

2.1. Material & Component Substitution

2.1.1. VRF on a P4-Programmable Switching ASIC

Enabling Description: The functions of the PON interface router are implemented not on a general-purpose CPU, but directly in the data plane of a P4-programmable switching ASIC. A P4 program defines the parsing, matching, and action tables to implement VRF. Each incoming packet is matched based on its ingress port or VLAN tag, mapped to a logical routing table identifier, and processed according to that table's forwarding rules. Because this occurs at line rate in hardware, it offers significantly lower latency and higher throughput than a CPU-based router. The P4 program can be dynamically updated by a central SDN controller to add, remove, or modify tenants without service interruption. The output of the P4 switch connects directly to the OLT.

Mermaid Diagram:

flowchart TD
    subgraph P4 Switch
        A[Ingress Port] --> B{Packet Parser}
        B --> C{Match: Ingress Port/VLAN}
        C -- Tenant A --> D1[Action: Use VRF-A Table] --> E{Egress Processing}
        C -- Tenant B --> D2[Action: Use VRF-B Table] --> E
        C -- Tenant C --> D3[Action: Use VRF-C Table] --> E
    end
    E --> F[OLT]

2.2. Operational Parameter Expansion

2.2.1. Cryogenic Data Management for Quantum Computing

Enabling Description: A PON interface router operates at room temperature, while the quantum computer and its control/readout electronics are in a cryogenic environment. The router is configured with dozens of VRFs, each dedicated to a specific qubit control channel, readout amplifier, or cryogenic sensor. This isolates the high-frequency control signals from sensitive measurement data. A single down-linking fiber carries this multi-tenant data stream from the OLT to a cryogenic-compatible optical splitter and array of ONUs co-packaged with the quantum processor. This minimizes the number of wires penetrating the cryogenic vessel, reducing the heat load, which is a critical limiting factor in scaling quantum computers.

Mermaid Diagram:

graph TD
    subgraph Room Temperature
        Router[PON Router]
        OLT
        Router --> VRF_Q1[VRF: Qubit 1 Control]
        Router --> VRF_R1[VRF: Qubit 1 Readout]
        Router --> VRF_T[VRF: Temp Sensors]
        VRF_Q1 & VRF_R1 & VRF_T --> OLT
    end

    subgraph Cryostat
        Splitter[Cryo-Splitter]
        ONU_Q1[Cryo-ONU: Qubit 1]
        ONU_T[Cryo-ONU: Sensors]
        Splitter --> ONU_Q1
        Splitter --> ONU_T
    end

    OLT -- Penetrating Fiber --> Splitter

2.3. Cross-Domain Application

2.3.1. Hospital Network with HIPAA-Compliant Segmentation

Enabling Description: A hospital uses a building-wide PON. A central router creates VRFs to enforce security policies and HIPAA compliance. A "Patient_Records" VRF allows access only to authenticated EMR terminals. A "Medical_Imaging" VRF provides high-bandwidth, low-latency paths for PACS workstations and imaging devices (MRI, CT). A "Guest_WiFi" VRF is completely isolated with internet access only. A "Building_Mgmt" VRF connects HVAC and security systems. The OLT aggregates these logically separated streams onto a single fiber backbone. ONUs in patient rooms, labs, and offices extract only the traffic relevant to the devices connected to them (e.g., an ONU in a radiology lab would be configured to primarily serve the Medical_Imaging VRF).

Mermaid Diagram:

graph LR
    Router --> VRF_EMR[VRF: EMR (HIPAA)]
    Router --> VRF_PACS[VRF: Medical Imaging]
    Router --> VRF_Guest[VRF: Guest WiFi]
    Router --> VRF_BMS[VRF: Building Systems]

    subgraph PON Infrastructure
        VRF_EMR & VRF_PACS & VRF_Guest & VRF_BMS --> OLT --> Splitter
    end

    Splitter --> ONU_Radiology[ONU: Radiology Dept<br>(Accesses VRF_PACS)]
    Splitter --> ONU_PatientRoom[ONU: Patient Room<br>(Accesses VRF_Guest)]
    Splitter --> ONU_NurseStation[ONU: Nurse Station<br>(Accesses VRF_EMR)]

2.4. Integration with Emerging Tech

2.4.1. Blockchain-Audited VRF Policy Management

Enabling Description: The PON interface router is coupled with a node on a private, permissioned blockchain (e.g., Hyperledger Fabric). Every time an administrator creates, modifies, or deletes a VRF, or changes a routing policy within a VRF, the router generates a cryptographically signed log of the change transaction. This transaction, containing the "before" and "after" state, is committed to the blockchain. This creates an immutable, tamper-proof audit trail of all network segmentation policies. This is critically useful for regulatory compliance (e.g., proving tenant isolation in a multi-tenant data center) and for forensic analysis after a security incident.

Mermaid Diagram:

sequenceDiagram
    participant Admin
    participant Router
    participant Blockchain as Blockchain Node

    Admin->>Router: API Call: "Create VRF for Tenant-X"
    activate Router
    Router->>Router: Generate Signed Transaction {Action: Create, VRF: Tenant-X, Policy: ...}
    Router-->>Blockchain: Commit Transaction
    activate Blockchain
    Blockchain->>Blockchain: Validate & Add to Ledger
    Blockchain-->>Router: Commit Confirmation
    deactivate Blockchain
    Router->>Router: Apply VRF Configuration
    Router-->>Admin: Success
    deactivate Router

2.5. The "Inverse" or Failure Mode

2.5.1. Per-VRF "Quarantine" State

Enabling Description: The router, integrated with an Intrusion Detection System (IDS), can place an entire VRF into a "quarantine" state. If a device attached to an ONU (e.g., Tenant A's PC) begins exhibiting malicious behavior (e.g., a port scan), the IDS alerts the router. The router does not shut down the tenant's connection entirely. Instead, it modifies the routing rules for Tenant A's VRF to deny all traffic except that which is destined for a "honeypot" server for analysis. All other tenants on the same PON continue to operate without interruption, securely isolated by their own VRFs. The quarantined tenant receives a notification (e.g., via a captive portal) explaining the restriction.

Mermaid Diagram:

flowchart TD
    IDS[IDS Sensor] -- Detects Threat --> Router
    subgraph Router
        direction LR
        VRF_A[VRF Tenant A<br>(Normal State)]
        VRF_B[VRF Tenant B<br>(Normal State)]
        VRF_A_Q[VRF Tenant A<br>(Quarantined State)]

        VRF_A -- Threat Detected --> VRF_A_Q
    end
    VRF_B --> OLT[To OLT]
    VRF_A_Q -- All Traffic Redirected --> Honeypot[Security Honeypot]

Part 3: Combination Prior Art Scenarios

Combination with Broadband Forum TR-384 (CloudCO): The PON interface router function described in the patent is implemented as a Virtualized Broadband Network Gateway (vBNG) VNF running on commodity servers within a Cloud Central Office architecture. Each subscriber or group of subscribers managed by the vBNG is assigned to a unique VRF instance, providing logical separation. The vBNG's output is forwarded to the OLT, which may itself be a physically disaggregated "white-box" device. This combination renders the patent's claims obvious in the context of standardizing efforts to virtualize broadband network functions.
Combination with ONF SEBA/VOLTHA: The system is integrated into the Software-Defined Networking (SDN) Enabled Broadband Access (SEBA) framework from the Open Networking Foundation. The creation and management of VRF instances on the PON interface router are not configured manually but are orchestrated by an SDN Controller (like ONOS) via the VOLTHA software layer. An application running on top of the controller allows an operator to provision a new tenant, which automatically configures the corresponding VRF on the router, the necessary VLAN tags in the OLT, and authenticates the ONU. This makes the patent's concept an obvious implementation detail within a larger, well-documented open-source SDN framework for broadband access.
Combination with Prometheus and YANG/NETCONF: The PON interface router and the OLT expose their per-VRF statistics and configurations via a standardized YANG data model. A NETCONF server on the devices allows for programmatic configuration. An open-source Prometheus "exporter" is used to scrape per-VRF traffic counters (bytes, packets, errors) in real-time. This data is stored in the Prometheus time-series database and visualized in Grafana dashboards, providing per-tenant network visibility. This combination makes the concept of separating traffic obvious for the purpose of per-tenant monitoring and SLA management using widely adopted open-source and standards-based operational tools.