Patent 10404366
Derivative works
Defensive disclosure: derivative variations of each claim designed to render future incremental improvements obvious or non-novel.
Active provider: Google · gemini-2.5-pro
Derivative works
Defensive disclosure: derivative variations of each claim designed to render future incremental improvements obvious or non-novel.
Defensive Disclosure for U.S. Patent 10,404,366
Title: Advanced Methods and Architectures for Dynamic Power Management in Multiplexed Signal Environments
Publication Date: April 26, 2026
Keywords: Wavelength Division Multiplexing (WDM), Optical Signal Monitoring, Dummy Light, Dynamic Thresholding, Mixed-Grid Networks, Optical Power Management, MEMS, Neuromorphic Computing, Fly-by-Light, Hyperspectral Imaging, AI-Defined Networks, OpenZR+, OpenConfig.
Abstract
This publication discloses a series of derivative inventions and improvements upon the methods described in U.S. Patent 10,404,366. The disclosed concepts aim to preemptively place into the public domain a range of modifications, applications, and integrations of the core technology, which involves using multiple, different thresholds across different wavelength bands to control the insertion of dummy signals for power stabilization. These disclosures are intended to be recognized as prior art for future patent applications in this domain. The variations span component substitutions, operation in extreme environments, cross-domain applications, integration with emerging technologies like AI and IoT, and novel failure-mode operations.
1.0 Derivative Variations: Material & Component Substitution
1.1 Quantum Dot Spectrometer-on-a-Chip Monitor
Enabling Description: The Optical Channel Monitor (OCM 500) is replaced with a solid-state spectrometer-on-a-chip based on a quantum dot (QD) array. Each QD in the array is engineered to have a specific size, causing it to absorb light in a very narrow and distinct wavelength band. The incoming WDM signal is spread across this linear array. The optical intensity in each measurement area (e.g., 5 GHz steps) is determined by measuring the photocurrent generated by the corresponding quantum dot. This provides a high-resolution, low-power, and compact alternative to traditional grating-based OCMs. The controller (CPU 600) processes the parallel photocurrent readouts from the QD array to compare against the stored thresholds for each determination area.
Mermaid Diagram:
flowchart TD subgraph Quantum Dot OCM A[Input WDM Signal] --> B{Planar Waveguide}; B --> C[Quantum Dot Array]; C --> D[Photocurrent Readout Circuitry]; end D --> E[Controller CPU/FPGA]; subgraph Stored Thresholds F[Threshold Table: Band 1 -> T1]; G[Threshold Table: Band 2 -> T2]; H[...]; I[Threshold Table: Band N -> TN]; end E -- Compares photocurrents with --> F; E -- Compares photocurrents with --> G; E -- Compares photocurrents with --> I; E --> J{Decision Logic}; J --> K[Control Signal to Dummy Light Source];
1.2 MEMS-Based Fast Switching for Dummy Light Source
Enabling Description: The switches (741-7411) within the dummy light source are implemented using Micro-Electro-Mechanical Systems (MEMS) optical switches. Each switch consists of a microscopic mirror that can be electrostatically tilted to either pass the dummy light signal from the waveguide into the optical coupler (ON state) or divert it into a beam dump (OFF state). These MEMS switches offer sub-microsecond switching times, significantly faster than thermo-optic or semiconductor optical amplifier (SOA) based gates. This rapid response is critical for mitigating power transients that can affect high-baud-rate signals during channel add/drop events. The controller (CPU 600) drives the MEMS actuators directly via high-voltage driver ICs.
Mermaid Diagram:
sequenceDiagram participant Controller participant MEMS_Driver participant MEMS_Switch participant Dummy_Light_Signal participant Optical_Coupler Controller->>MEMS_Driver: Send ON Signal for Band 'i' activate MEMS_Driver MEMS_Driver->>MEMS_Switch: Apply Actuation Voltage activate MEMS_Switch Dummy_Light_Signal->>MEMS_Switch: Optical Signal Input MEMS_Switch-->>Optical_Coupler: Mirror diverts light to output deactivate MEMS_Switch deactivate MEMS_Driver Note over Controller, Optical_Coupler: Dummy light for band 'i' is now active.
1.3 Neuromorphic Controller for Adaptive Thresholding
Enabling Description: The control logic (CPU 600) is executed on a neuromorphic processing unit (NPU) that utilizes spiking neural networks (SNNs). The NPU continuously learns patterns from the time-series data of the monitored optical intensities across all bands. It can identify correlations between subtle power fluctuations in one band and the probability of a channel failure in another. The thresholds for each band are no longer static values but are dynamic outputs of the SNN, adapting to learned network behavior, signal modulation formats, and hardware degradation patterns. For example, the NPU might learn to lower the threshold for a specific band during periods of high atmospheric scintillation in a free-space optical link.
Mermaid Diagram:
classDiagram class NeuromorphicController { -snnModel: SpikingNeuralNetwork -dynamicThresholds[]: float +processIntensityData(measurements) +updateThresholds() +getControlDecision(bandIndex) } class OCM { +readIntensities(): float[] } class DummyLightSource { +setSwitchState(bandIndex, state) } NeuromorphicController "1" -- "1" OCM : receives data from NeuromorphicController "1" -- "1" DummyLightSource : controls
2.0 Derivative Variations: Operational Parameter Expansion
2.1 On-Chip Nanophotonic Power Management
Enabling Description: The entire system is miniaturized onto a single silicon photonics integrated circuit (PIC) for on-chip optical network (OCN) applications. The "transmitters" are hundreds of micro-ring resonators (MRRs), the "multiplexer" is an arrayed waveguide grating (AWG), and the "monitor" is an array of photodetectors tapping power from the main bus waveguide. Here, the "dummy light" serves a thermal management purpose. When an MRR is inactive (no signal), it stops absorbing optical power and thus cools down, causing its resonant wavelength to drift. The controller detects the drop in power for that MRR's wavelength band and activates a corresponding "dummy heater"—a resistive element or a dedicated light-absorbing element—to dissipate an equivalent amount of power, maintaining thermal stability across the PIC and preventing thermal crosstalk. The thresholds are set based on the thermal sensitivity of the MRRs.
Mermaid Diagram:
flowchart LR subgraph Silicon Photonics IC Transmitters[MRR Array] --> MUX[AWG]; MUX --> Bus[Main Waveguide]; Bus -- Taps light --> Monitor[Photodetector Array]; Monitor --> Controller[On-Chip Controller]; Controller --> Heaters[Dummy Heater Array]; Bus --> Output; end
2.2 Deep-Space Optical Link with Temperature-Indexed Thresholds
Enabling Description: The system is used on a satellite terminal for deep-space laser communications. The operational temperature cycles between cryogenic lows during eclipse and high temperatures under direct solar exposure (-150°C to +120°C). This thermal cycling causes significant laser wavelength drift and power output fluctuations. The controller's storage (20) holds a multi-dimensional lookup table where each threshold is indexed not only by wavelength band but also by the measured temperature of the transmitter package. A temperature sensor integrated with the laser module provides the real-time index for the controller, which then selects the appropriate power threshold for the current operating temperature, ensuring accurate detection of channel loss versus predictable thermal drift.
Mermaid Diagram:
stateDiagram-v2 state "Get Measurements" as A state "Get Temperature" as B state "Select Threshold" as C state "Compare M vs T" as D state "Decision" as E [*] --> A A --> B B --> C : T = -100°C C --> D : Use Threshold_Table[-100] B --> C : T = +50°C C --> D : Use Threshold_Table[+50] D --> E : If M < T_selected E --> [*] : Insert Dummy Light D --> [*] : Else, No Action
3.0 Derivative Variations: Cross-Domain Application
3.1 Fly-by-Light Aircraft Sensor Bus Integrity Monitoring
Enabling Description: In an aircraft using a Fly-by-Light system, hundreds of Fiber Bragg Grating (FBG) sensors are multiplexed onto a single fiber bus. Each FBG reflects a specific wavelength corresponding to a physical parameter (e.g., strain on a wing spar). The returned WDM signal is monitored. Different sensors have different reflectivity and importance, warranting different power thresholds. If a sensor is damaged and its signal disappears (power drops below its specific threshold), the controller immediately inserts a dummy optical signal in that sensor's wavelength slot. This prevents the total power drop from triggering a false "fiber break" alarm in the main bus monitor, while a separate logic path flags the specific sensor ID for maintenance, ensuring the rest of the sensor network continues to be monitored correctly.
Mermaid Diagram:
flowchart TD A[Broadband Light Source] --> B(Fiber Bus); subgraph WingSensors C{FBG 1: Strain λ1} D{FBG 2: Temp λ2} E{...} end B --> C; B --> D; B --> E; C --> F(WDM Return Signal); D --> F; E --> F; F --> G[Optical Monitor]; G --> H{Controller}; H -- Check Signal λ1 --> I{Threshold T1}; H -- Check Signal λ2 --> J{Threshold T2}; H -- If Signal λ1 < T1 --> K[Activate Dummy Light at λ1]; K --> F; H --> L[Log 'Sensor 1 Fault'];
3.2 Medical Flow Cytometry Laser Health Verification
Enabling Description: A flow cytometer uses multiple lasers (e.g., 405nm, 488nm, 633nm) to excite fluorescent tags on cells. The emitted light is split by dichroic mirrors and measured by photomultiplier tubes (PMTs) in different wavelength bands. The health of each laser is critical for accurate cell counting. The patented method is adapted to monitor laser power. A small fraction of each laser's light is tapped and fed into a monitor. Each laser/band has a different minimum power threshold required for proper cell excitation. If the monitored power for the 488nm laser drops below its threshold, the controller injects a calibrated electronic pulse train (a "dummy signal") into the 488nm PMT's data acquisition path. This forces a flatline or known error pattern in the output data for that channel, preventing the system from reporting zero cells (a valid biological result) and instead triggering a "Laser 488nm Maintenance Required" alarm for the operator.
Mermaid Diagram:
sequenceDiagram participant Laser_488nm participant Monitor participant Controller participant DAQ_488nm participant System_UI loop Health Check Laser_488nm->>Monitor: Optical Power Tap Monitor->>Controller: Power Level Reading end alt Power > Threshold Controller->>DAQ_488nm: Normal Operation else Power < Threshold Controller->>DAQ_488nm: Inject Electronic Dummy Signal Controller->>System_UI: Display "Laser Fault" Alarm end
4.0 Derivative Variations: Integration with Emerging Tech
4.1 AI-Driven Predictive Power Management
Enabling Description: The controller is enhanced with an AI module, specifically a Long Short-Term Memory (LSTM) network, trained on historical optical performance data from thousands of network hours. The AI model analyzes the fine-grained (5 GHz step) measurements from the OCM not just as a single value but as a spectral shape. It learns the characteristic spectral deformations that precede a transmitter failure or "mode hopping." Based on these predictive analytics, the controller can pre-emptively insert dummy light into a band before the signal drops below a hard threshold, enabling hitless protection switching and routing traffic away from the failing component with zero downtime. The thresholds themselves become probabilistic confidence scores generated by the AI.
Mermaid Diagram:
flowchart TD OCM -- Spectral Data --> AI_Module(LSTM Model); Historical_Data -- Trains --> AI_Module; AI_Module -- "Predicts P(failure) > 0.95" --> Controller; Controller --> DummyLightSource(Pre-emptive Activation); Controller --> Network_Orchestrator(Reroute Traffic);
4.3 Blockchain-Audited SLA Enforcement in Multi-Tenant Networks
Enabling Description: In a shared optical infrastructure used by multiple carriers, the controller's actions are linked to a private blockchain. When the monitor detects a channel loss in a band leased by "Carrier A" (i.e., all measurements fall below Carrier A's contractually defined threshold), the controller performs two actions: 1) It turns on the corresponding dummy light switch to maintain system stability. 2) It creates a transaction containing the timestamp, wavelength band ID, all 10 measured power values, the threshold value, and the action taken ("Dummy Light ON"). This transaction is signed with the controller's private key and recorded on the blockchain. This creates an immutable, cryptographically verifiable record for SLA compliance, automatically proving downtime for billing adjustments without dispute.
Mermaid Diagram:
graph TD A[Monitor Detects Power < Threshold for Carrier A's Band] --> B{Controller}; B --> C[Activate Dummy Light]; B --> D[Create Transaction]; subgraph TransactionData E[Timestamp] F[Band ID] G[Measured Values] H[SLA Threshold] end D --> I{Sign Transaction}; I --> J[Broadcast to Blockchain Network]; J --> K[Add to Immutable Ledger];
5.0 Derivative Variations: The "Inverse" or Failure Mode
5.1 "Optical Fuse" Safe Failure Mode
Enabling Description: The system is designed with a watchdog timer that continuously monitors the health of the main controller (CPU 600). If the controller fails to reset the timer (e.g., due to a software crash or hardware fault), the watchdog circuitry forces the system into a pre-defined safe state. It bypasses the controller and sends a direct hardware signal to the dummy light source (700). This signal commands the source to generate a low-power, broadband ASE signal across the entire C-band. Simultaneously, it cuts power to all primary transmitters (210-260). This acts as an "optical fuse," preventing a rogue controller from driving optical amplifiers into a saturated or surging state, which could physically damage components. The resulting low-power, predictable noise signal on the line aids technicians in remote fault diagnosis.
Mermaid Diagram:
stateDiagram-v2 state "Operating" { Controller -- "resets timer" --> Watchdog } state "Safe Mode" { direction LR state "Transmitters OFF" as T_OFF state "Dummy Source ON (Broadband)" as D_ON } [*] --> Operating Operating --> Operating : Watchdog Timer Reset Watchdog : "timer expires" Operating --> Safe_Mode : Watchdog Timeout Safe_Mode --> [*] : Manual Reset
6.0 Combination Prior Art with Open Standards
6.1 Combination with OpenZR+ MSA
- Disclosure: The method of U.S. Patent 10,404,366 is applied to an optical line system populated with 400G OpenZR+ compliant pluggable modules from multiple vendors (e.g., Acacia, Ciena, Marvell). Since the OpenZR+ standard allows for some variation in transmit power and spectral shape, a single power threshold for all channels is insufficient. The line system's monitor divides the spectrum into 50 GHz bands corresponding to the OpenZR+ grid. A unique power threshold is configured for each band, tailored to the specific vendor module provisioned in that channel. For example, a band with a lower-power module might have a threshold of -25 dBm, while another with a higher-power module has a threshold of -22 dBm. This allows the system to accurately detect a failed module and insert dummy light to maintain the power balance required by the EDFA amplifiers, ensuring interoperability in a multi-vendor environment.
6.2 Combination with TIP OpenConfig/gNMI
- Disclosure: The optical signal monitor and dummy light source are implemented as disaggregated hardware components in a Telecom Infra Project (TIP) compliant architecture. The monitor continuously streams its per-band intensity measurements using the gNMI protocol (gRPC Network Management Interface) with a standardized OpenConfig YANG model for optical-impairment-monitoring. An external SDN controller subscribes to this stream. The controller's logic, which implements the multi-band, multi-threshold comparison, runs as a software application. When the logic determines a need for dummy light, it uses a gNMI
SetRPC to change the state of the dummy light switch in the separate dummy light source hardware, again using a standard OpenConfig model (e.g.,openconfig-platform). This creates a fully disaggregated, software-defined, and open standards-based implementation of the patented system.
6.3 Combination with SNMP
- Disclosure: The controller (CPU 600) is equipped with an SNMP agent. A custom Management Information Base (MIB) is defined for the device. This MIB includes a table,
dummyLightControlTable, with one row for each determination area (wavelength band). Each row contains objects (OIDs) for:bandIndex(e.g., 1 to 11),bandFrequencyRange(e.g., "193.525-193.475 THz"),powerThreshold(a settable gauge, e.g., -300 for -30.0 dBm),lastTenMeasurements(a string of the most recent power values), anddummyLightStatus(an integer enumeration: 1=off, 2=on). This allows any standard network management system (NMS), such as Nagios or SolarWinds, to poll the device via SNMP to monitor the status, graph the power levels, and receive SNMP traps whendummyLightStatuschanges. Administrators with write credentials can also use SNMPSetcommands to remotely adjust thepowerThresholdfor any band, integrating the device seamlessly into legacy network management frameworks.
Generated 5/5/2026, 6:04:34 PM