Patent 12150105

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-flash

Derivative works

Defensive disclosure: derivative variations of each claim designed to render future incremental improvements obvious or non-novel.

✓ Generated

Defensive Disclosure for US Patent 12150105

This document outlines derivative variations of the core claims of US Patent 12150105. The purpose is to establish prior art, rendering future incremental improvements by competitors obvious or non-novel, thereby limiting their patentability landscape in the domain of wireless communication in overlapping basic service sets.

Derivations for Independent Claim 1

Claim 1: A wireless communication terminal that communicates wirelessly, the wireless communication terminal comprising: a transceiver; and a processor configured to transmit a BSS color indicating a BSS including the wireless communication terminal when communicating with another wireless communication terminal through the transceiver, and transmit a predetermined value as the BSS color when the wireless communication terminal fails to receive information signaling the BSS color.

Derivative 1.1: Material & Component Substitution - Reconfigurable RF Front-End with Cognitive BSS Color Management

Enabling Description:
A wireless communication terminal integrates a reconfigurable radio frequency (RF) front-end, employing a software-defined radio (SDR) architecture with a Field-Programmable Gate Array (FPGA) or a high-performance Digital Signal Processor (DSP) based processor for BSS color management. The transceiver utilizes a gallium nitride (GaN) power amplifier and a microelectromechanical systems (MEMS) tunable filter array to dynamically adjust transmission parameters across a wide spectrum (e.g., 2.4 GHz, 5 GHz, 6 GHz, and 60 GHz bands, up to THz), including the BSS color signaling. The processor, implemented on a dedicated hardware acceleration unit within the SoC, is configured to monitor spectrum occupancy and interference levels. Upon failing to receive an explicit BSS color from its associated Access Point (AP) or during an Independent BSS (IBSS) setup without a designated color, it defaults to transmitting a pre-defined BSS color value (e.g., '0x00' as specified in IEEE 802.11be for certain scenarios) using a low-power, wide-coverage beacon frame to minimize interference while advertising an unassigned status. The GaN amplifier allows for highly efficient power scaling, and the MEMS filters enable precise channel selection even in extremely dense environments.

Combination Prior Art:

  1. OpenWrt (Open-source router firmware): An OpenWrt-enabled access point or station could implement the dynamic BSS color assignment logic, including the fallback to a predetermined value, by extending its existing Wi-Fi driver and MAC layer functionalities.
  2. Linux kernel IEEE 802.11 drivers (e.g., ath11k for Qualcomm Wi-Fi 6/6E): The low-level control plane of these drivers can be modified to directly interface with the reconfigurable RF front-end, manage the HE-SIG-A BSS Color field, and implement the logic for transmitting the predetermined BSS color value in the absence of explicit assignment.
  3. GNU Radio (Software Defined Radio framework): A GNU Radio-based SDR platform could simulate or implement the entire cognitive BSS color management, including spectrum sensing, dynamic parameter adjustment via GaN/MEMS components (if abstracted), and the explicit transmission of the default BSS color.
flowchart TD
    A[Wireless Terminal] --> B{Transceiver: GaN PA, MEMS Filter};
    B --> C[Processor: FPGA/DSP SoC];
    C --> D{Monitor Spectrum/Interference};
    D -- No BSS Color Rx'd --> E[Transmit Predetermined BSS Color (e.g., 0x00)];
    D -- BSS Color Rx'd --> F[Transmit Assigned BSS Color];
    E --> G(Low-Power Beacon);
    F --> H(Standard Data PPDU);
    C -- Control --> B;

Derivative 1.2: Operational Parameter Expansion - Terahertz (THz) Range Communication in Extreme Density

Enabling Description:
This derivative applies the BSS color transmission mechanism to wireless communication terminals operating within the Terahertz (THz) frequency range (e.g., 100 GHz to 10 THz) in extremely dense, short-range environments, such as within a single data center rack or specialized industrial automation zones. Due to the very high path loss and oxygen absorption at THz frequencies, communication links are highly directional and extremely short, resulting in hundreds or thousands of overlapping basic service sets within a small physical area (e.g., 1 cubic meter). The processor transmits an extended BSS color field (e.g., 12-bit or 16-bit to support a larger range of unique identifiers) within custom THz PHY layer signaling. When the terminal fails to acquire a BSS color due to transient link failures or highly localized interference, it broadcasts a designated "unassigned/default" BSS color (e.g., all 1s or a specific reserved pattern) within its directional beam. This default value prompts neighboring terminals to initiate a more aggressive discovery protocol or to temporarily increase their deference sensitivity to avoid potential hidden node issues exacerbated by THz directionality.

Combination Prior Art:

  1. IEEE 802.11ad/ay open standards (WiGig): While not THz, these standards (60 GHz) provide a basis for directional communication, beamforming, and associated MAC/PHY adaptations that could be extended to the THz range for BSS color signaling.
  2. OpenAirInterface (OAI - Open-source 5G/LTE stack): OAI's flexible architecture for PHY/MAC layer experimentation could be adapted to simulate or implement THz-specific physical layer mechanisms for BSS color encoding and decoding, including the handling of a predetermined default value in high-density scenarios.
  3. OPenWiMAX (Open-source WiMAX implementation): The dynamic channel access and resource allocation schemes of WiMAX, though for lower frequencies, offer principles that could be adapted for managing spatial reuse and interference avoidance in highly dynamic THz environments, informing the logic for BSS color utilization and default behaviors.
graph TD
    A[Wireless Terminal (THz)] --> B(THz Transceiver);
    B --> C[THz MAC/PHY Processor];
    C --> D{BSS Color Assigned?};
    D -- Yes --> E[Transmit PPDU with Assigned THz BSS Color];
    D -- No (Failure) --> F[Transmit PPDU with Predetermined THz BSS Color];
    E -- Directional Beam --> G[Neighboring Terminals];
    F -- Directional Beam --> G;
    G -- Interpret BSS Color --> H{Channel Access Decision};

Derivative 1.3: Cross-Domain Application - Agricultural Drone Swarm Management

Enabling Description:
In smart agriculture, a swarm of autonomous drones (wireless communication terminals) performs tasks like crop monitoring or targeted pesticide application. Each drone is part of a dynamic "field BSS" managed by a local ground station (AP). The drones transmit their assigned BSS color to identify which field segment they belong to, enabling efficient spatial reuse of communication channels and preventing interference between adjacent field BSSs. If a drone loses communication with its ground station or enters a new, unassigned field segment (fails to receive BSS color information), its processor automatically transmits a predetermined "unassigned zone" BSS color (e.g., a specific hexadecimal value like 0xFFF0). This predetermined value signals to other drones and ground stations that the drone is operating autonomously or is out of its designated operational zone, prompting other devices to treat its transmissions with higher deference (as Inter-BSS traffic) or to flag it for re-assignment by a central swarm controller.

Combination Prior Art:

  1. PX4 Autopilot (Open-source drone flight control stack): The communication module within PX4 could be extended to manage the BSS color transmission logic and integrate it with the drone's mission planning and geo-fencing capabilities.
  2. ROS (Robot Operating System): ROS nodes running on individual drones could manage the high-level decision-making for BSS color assignment, re-assignment, and the fallback to a predetermined value, coordinating with lower-level Wi-Fi modules.
  3. LoRaWAN (Long Range Wide Area Network) open protocol: For long-range, low-bandwidth signaling in agricultural settings, a LoRaWAN-enabled drone could use a similar concept, where a specific LoRaWAN frame header or payload value acts as the "BSS color" for identifying operational zones, defaulting to a reserved value when unassigned.
sequenceDiagram
    participant D as Drone (Terminal)
    participant G as Ground Station (AP)
    participant C as Central Swarm Controller
    G->>D: Assign BSS Color (e.g., Field-1 color)
    D->>D: Store BSS Color
    loop Operational Flight
        D->>D: Check BSS Color status
        alt BSS Color Available
            D->>G: Transmit PPDU (Field-1 color)
        else BSS Color Not Received
            D->>D: Default to Predetermined BSS Color (e.g., Unassigned)
            D->>G: Transmit PPDU (Unassigned color)
            G->>C: Alert: Drone in Unassigned Zone
            C->>G: Request Re-assignment / Re-initiate pairing
        end
    end

Derivative 1.4: Integration with Emerging Tech - AI-Driven Dynamic BSS Color Negotiation

Enabling Description:
A wireless communication terminal integrates an embedded AI module (e.g., a lightweight neural network inference engine) to dynamically negotiate and adapt its BSS color in highly dynamic overlapping BSS (OBSS) environments. Instead of passively receiving a BSS color, the terminal's processor, using reinforcement learning, observes channel conditions, interference patterns, and neighboring BSS color transmissions. When initially failing to receive a BSS color or detecting a BSS color collision, the AI module predicts an optimal "safe" predetermined BSS color from a pre-allocated pool of reserved values (e.g., 0x01 to 0x0F for AI-managed defaults). This predicted value is transmitted. The AI then iteratively refines this choice based on subsequent network feedback (e.g., lower Clear Channel Assessment (CCA) deferral rates, successful data transmissions). This process transforms the "predetermined value" from a static fallback into an actively chosen, AI-optimized default, allowing for more intelligent integration into an OBSS. The AI also triggers a more robust BSS color request mechanism if the chosen default leads to poor performance.

Combination Prior Art:

  1. OpenAI Gym/TensorFlow Lite (AI frameworks): The AI module could be trained using simulation environments (like OpenAI Gym) and deployed on resource-constrained embedded systems using TensorFlow Lite, integrating with standard Wi-Fi hardware abstraction layers.
  2. OpenFlow (Software-Defined Networking standard): The SDN controller could receive real-time network telemetry, informing the AI module's training data and allowing it to push optimized BSS color policies to terminals.
  3. RIoT (Robust IoT operating system): RIoT OS, designed for secure and low-power IoT devices, could host the AI inference engine and manage the secure transmission of BSS color information, including the AI-determined predetermined values.
stateDiagram-v2
    state "Initialize" as Init
    state "Monitor Channel" as Monitor
    state "BSS Color Received" as BSS_Rx
    state "BSS Color Not Received" as BSS_NoRx
    state "AI Negotiation" as AI_Neg
    state "Transmit Assigned BSS Color" as Tx_Assigned
    state "Transmit AI Predetermined BSS Color" as Tx_AIPredetermined
    state "Refine AI Choice" as Refine_AI

    Init --> Monitor : Start
    Monitor --> BSS_Rx : BSS Color Valid
    Monitor --> BSS_NoRx : BSS Color Missing/Collision

    BSS_Rx --> Tx_Assigned : Use BSS Color
    Tx_Assigned --> Monitor : Continue Operation

    BSS_NoRx --> AI_Neg : Trigger AI
    AI_Neg --> Tx_AIPredetermined : Select & Transmit
    Tx_AIPredetermined --> Refine_AI : Evaluate Performance
    Refine_AI --> Monitor : Update AI Model
    Refine_AI --> AI_Neg : If performance suboptimal

Derivative 1.5: The "Inverse" or Failure Mode - Emergency Beacon with Deliberately Ambiguous BSS Color

Enabling Description:
A wireless communication terminal is designed with an emergency mode (e.g., triggered by low battery, critical sensor failure, or a user-activated panic button). In this mode, its processor deliberately transmits a predetermined BSS color value that is widely recognized as "ambiguous," "emergency broadcast," or "do not spatially reuse" across all compliant wireless networks. This predetermined value (e.g., 0xFF or 0xFFFF if the field is 8 or 16 bits) is specifically chosen not to match any valid BSS color and is advertised with maximum transmit power (within regulatory limits) and a high modulation coding scheme (MCS) redundancy to ensure widespread reception. The intent is to signal all listening terminals, regardless of their BSS, to increase their Network Allocation Vector (NAV) or deferral period significantly, or to entirely disable spatial reuse operations for incoming PPDUs from this emergency transmitter. This inverse operation prevents other BSSs from attempting spatial reuse and potentially interfering with the emergency transmissions, even if it means temporarily reducing overall network throughput.

Combination Prior Art:

  1. IEEE 802.11s (Mesh Networking Standard): The emergency mode could extend mesh node functionality, allowing a failing node to broadcast its status with this special BSS color, preventing further routing through it and ensuring its emergency signals propagate.
  2. CoAP (Constrained Application Protocol): An emergency terminal could use CoAP over UDP for its emergency messages, where the CoAP header could carry the interpreted BSS color status, further detailing the emergency type even if the underlying PHY/MAC BSS color is generic.
  3. OpenV2V (Open-source Vehicle-to-Vehicle communication): In V2V contexts, a vehicle entering an emergency state (e.g., severe accident) could use this deliberately ambiguous BSS color to globally defer other vehicle-to-everything (V2X) communications in its immediate vicinity, acting as a broad area "safety zone" indicator.
graph LR
    A[Terminal in Normal Mode] --> B{Emergency Trigger?};
    B -- Yes --> C[Enter Emergency Mode];
    B -- No --> A;
    C --> D[Processor Configured];
    D --> E[Select Predetermined BSS Color (e.g., 0xFF)];
    E --> F[Transmit PPDU with Predetermined BSS Color at Max Power/Redundancy];
    F --> G[All Neighboring Terminals Receive];
    G --> H{Recognize Predetermined BSS Color};
    H --> I[Increase NAV / Disable Spatial Reuse];
    I --> J[Prioritize Emergency Transmissions];
    C --> K[Perform Emergency Function (e.g., transmit vital signs)];

Derivations for Independent Claim 7

Claim 7: A wireless communication terminal that communicates wirelessly, the wireless communication terminal comprising: a transceiver; and a processor configured to receive a PLCP Protocol Data Unit (PPDU) through the transceiver and access a channel based on whether the PPDU is an Inter-BSS PPDU or an Intra-BSS PPDU, the Intra-BSS PPDU indicates a PPDU transmitted from the same BSS as the BSS including the wireless communication terminal, and the Inter-BSS PPDU indicates a PPDU transmitted from a BSS other than the BSS including the wireless communication terminal.

Derivative 7.1: Material & Component Substitution - Multi-Gigabit Optical Transceiver with Hybrid RF/Optical PPDU Classification

Enabling Description:
A wireless communication terminal incorporates a hybrid transceiver capable of both radio frequency (RF) and free-space optical (FSO) communication. The processor receives PLCP Protocol Data Units (PPDUs) via either the RF (e.g., 60 GHz WiGig) or FSO (e.g., visible light communication, VLC, or infrared) medium. The classification of Inter-BSS vs. Intra-BSS PPDU is performed by a dedicated hardware module, potentially an application-specific integrated circuit (ASIC), that rapidly parses the BSS color field (for RF PPDUs) or a designated optical signaling preamble (for FSO PPDUs). For FSO, different light wavelengths or modulation patterns could represent distinct "BSS colors." When an FSO PPDU is received, the ASIC identifies whether its optical signature corresponds to an "Intra-BSS" wavelength/pattern or an "Inter-BSS" one. The channel access logic then adapts, for example, by immediately initiating an FSO transmission if the received PPDU is Inter-BSS (assuming non-interfering FSO beams), or deferring if it's Intra-BSS and the terminal is not the intended recipient. This allows for spatial reuse benefits even when using optical communication, leveraging the inherent directionality.

Combination Prior Art:

  1. Li-Fi (Light Fidelity) open standards (e.g., IEEE 802.11bb): The principles of VLC (Visible Light Communication) and Li-Fi MAC/PHY would provide the foundation for encoding BSS identification into optical signals and the associated channel access mechanisms.
  2. OpenStack (Cloud computing platform): For managing communication within a data center, OpenStack could control virtualized FSO "BSSs" and dynamically provision optical wavelengths/patterns for Intra-BSS identification, with terminals classifying PPDUs accordingly.
  3. ONOS (Open Network Operating System - SDN controller): ONOS could be extended to manage hybrid RF/FSO networks, allowing a central controller to define and distribute BSS color policies (both RF and optical) to terminals, enabling consistent channel access decisions.
graph TD
    A[Wireless Terminal] --> B{Hybrid Transceiver};
    B --> C1[RF Receiver];
    B --> C2[FSO Receiver];
    C1 --> D[Processor (ASIC)];
    C2 --> D;
    D -- RF PPDU --> E{Parse BSS Color Field};
    D -- FSO PPDU --> F{Parse Optical Signature};
    E -- Match Intra-BSS Color --> G[Intra-BSS PPDU];
    E -- Mismatch BSS Color --> H[Inter-BSS PPDU];
    F -- Match Intra-BSS Signature --> G;
    F -- Mismatch BSS Signature --> H;
    G --> I[Channel Access Policy: Intra-BSS];
    H --> J[Channel Access Policy: Inter-BSS];
    I --> K[Access Channel];
    J --> K;

Derivative 7.2: Operational Parameter Expansion - Extremely Low Frequency (ELF) Seismic Communication

Enabling Description:
A wireless communication terminal is adapted for long-range, low-bandwidth communication using Extremely Low Frequency (ELF) seismic waves for applications like underground geological monitoring or long-distance submarine communications. The "PPDU" in this context is a modulated seismic signal burst. The processor uses specialized seismic transceivers (e.g., piezoelectric arrays) to receive these PPDUs. Due to the extremely slow propagation speeds of seismic waves, channel access decisions must be made with significant temporal offsets. The "BSS color" is encoded as a unique, low-frequency modulation pattern or a characteristic frequency shift within the seismic signal. The processor classifies received seismic PPDUs as "Intra-BSS" (e.g., from its own geological survey network) or "Inter-BSS" (from a neighboring or external seismic network) based on this encoded signature. Channel access involves scheduling seismic transmissions to avoid long-duration overlap, with Intra-BSS priority often deferring to critical Inter-BSS warnings (e.g., tectonic activity alerts) or vice-versa, depending on the mission profile.

Combination Prior Art:

  1. Open Seismic Data Format (e.g., SEG-Y): While not a communication protocol, open standards for seismic data could provide a framework for defining the "PPDU" structure and the metadata needed to encode "BSS color" information into seismic signal headers.
  2. Opencast (Open-source seismic processing software): Opencast or similar open-source tools could be adapted to process raw seismic signals, extract the "BSS color" information, and feed it to the channel access decision logic.
  3. OpenThread (Low-power mesh networking for IoT): The mesh networking principles of OpenThread could inspire a distributed coordination scheme for seismic sensor nodes, where "BSS colors" would help manage channel contention over extremely long propagation delays.
stateDiagram-v2
    state "Idle" as Idle
    state "Receive Seismic PPDU" as Rx_Seismic
    state "Extract BSS Signature" as Extract_Sig
    state "Classify PPDU" as Classify
    state "Access Channel (Intra-BSS Policy)" as Access_Intra
    state "Access Channel (Inter-BSS Policy)" as Access_Inter

    Idle --> Rx_Seismic : Detect Seismic Signal
    Rx_Seismic --> Extract_Sig : Process Raw Seismic Data
    Extract_Sig --> Classify : Compare Signature
    Classify --> Access_Intra : If Intra-BSS PPDU
    Classify --> Access_Inter : If Inter-BSS PPDU
    Access_Intra --> Idle : Transmission/Deferral complete
    Access_Inter --> Idle : Transmission/Deferral complete

Derivative 7.3: Cross-Domain Application - Smart Grid Powerline Communication (PLC)

Enabling Description:
In a smart grid environment, communication terminals (e.g., smart meters, grid sensors, distribution automation devices) utilize Powerline Communication (PLC) over existing electrical lines. Each segment of the grid (e.g., a transformer's service area) forms a "BSS." The terminal's processor receives PLC PPDUs (data frames modulated onto the powerline) and identifies whether they originate from its local grid segment (Intra-BSS) or an adjacent, possibly overlapping, grid segment (Inter-BSS). This identification is based on a "BSS color" encoded in the PLC PHY header, perhaps a specific frequency hopping sequence or a unique spread spectrum code. The channel access logic then prioritizes critical grid commands (e.g., load shedding, fault detection) from its own segment over non-critical data from overlapping segments. For instance, an Inter-BSS PPDU might trigger a "listen-before-talk" mechanism with a longer deferral, while an Intra-BSS PPDU, if not for the terminal, might lead to a shorter deferral or immediate transmission if the local channel is clear.

Combination Prior Art:

  1. G.hn (ITU-T standard for home networking over any wire): G.hn provides a basis for powerline communication with mechanisms for media access control (MAC) and physical layer (PHY) that could be extended to include BSS color-like identifiers for network segmentation.
  2. OpenPLC (Open-source PLC platform): OpenPLC's software stack for programmable logic controllers could integrate the intelligence for parsing PLC PPDUs, identifying "BSS colors" within the powerline medium, and implementing adaptive channel access.
  3. Open Zigbee (Open-source Zigbee stack): While primarily RF, Zigbee's mesh networking and device association principles could be adapted to managing "BSS" equivalents in a PLC network, where devices associate with specific "color" PLC segments.
flowchart TD
    A[Grid Terminal] --> B{PLC Transceiver};
    B --> C[Processor];
    C --> D{Receive PLC PPDU};
    D --> E{Extract PLC BSS Color};
    E -- Matches Local BSS Color --> F[Intra-BSS PPDU];
    E -- Mismatches Local BSS Color --> G[Inter-BSS PPDU];
    F --> H[Apply Intra-BSS Channel Access Policy];
    G --> I[Apply Inter-BSS Channel Access Policy];
    H --> J[Access PLC Channel];
    I --> J;

Derivative 7.4: Integration with Emerging Tech - Quantum Key Distribution (QKD) Enhanced Channel Access

Enabling Description:
A wireless communication terminal for highly secure environments (e.g., financial trading networks, military communications) integrates Quantum Key Distribution (QKD) capabilities alongside its standard transceiver. The processor utilizes QKD for secure key establishment, and these keys are dynamically used to generate a unique, ephemeral "BSS color" for each secure communication session (BSS equivalent). When a PPDU is received, the processor first attempts to decrypt the BSS color field using a recently established quantum key. If successful, it verifies the "quantum BSS color" and categorizes the PPDU as Intra-BSS. If decryption fails or the BSS color is non-quantum-keyed, it's classified as Inter-BSS. Channel access is then determined based on this classification, with a strong bias towards deferring to any quantum-keyed Intra-BSS communication due to its inherent security and priority. This system could also employ a non-QKD derived, public "Inter-BSS" signature for general interference avoidance from untrusted or unauthenticated networks.

Combination Prior Art:

  1. OpenQKD (European open-source QKD initiative): The software stack from OpenQKD could provide the framework for managing quantum key generation, distribution, and integration with the PHY/MAC layer for BSS color generation.
  2. OpenSSL (Cryptography library): While not quantum-specific, OpenSSL's cryptographic primitives would be essential for handling the secure, post-quantum-key-distribution encryption/decryption of the BSS color field.
  3. Linux Kernel Networking Stack: The network stack would be extended to include quantum-secure interfaces for the transceiver, managing the prioritization and channel access decisions based on the QKD-derived BSS color status.
sequenceDiagram
    participant T as Terminal
    participant S as Secure Partner (AP/STA)
    T->>S: QKD Setup (Key Exchange)
    S->>T: QKD Setup (Key Exchange)
    T->>T: Generate Ephemeral BSS Color (from QKD key)
    S->>S: Generate Ephemeral BSS Color (from QKD key)
    loop Communication
        S->>T: Transmit PPDU (with Encrypted Q-BSS Color)
        T->>T: Receive PPDU
        T->>T: Attempt Decrypt Q-BSS Color with QKD Key
        alt Decryption Success & Q-BSS Color Valid
            T->>T: Classify as Intra-BSS PPDU
            T->>T: Apply Intra-BSS Channel Access
        else Decryption Fail or Non-QKD BSS Color
            T->>T: Classify as Inter-BSS PPDU
            T->>T: Apply Inter-BSS Channel Access
        end
    end

Derivative 7.5: The "Inverse" or Failure Mode - "Safe Deference" Channel Access in OBSS

Enabling Description:
A wireless communication terminal implements a "Safe Deference" mode, typically activated upon detection of critical system faults (e.g., memory corruption, CPU overload, or sustained channel congestion). In this mode, the processor is configured to interpret all received PPDUs as Inter-BSS PPDUs, irrespective of their actual BSS color or other identification fields. This overrides any standard Intra-BSS detection mechanisms. The channel access logic then defaults to the most conservative Inter-BSS deferral policy, typically involving a significantly longer Network Allocation Vector (NAV) setting and a higher Clear Channel Assessment (CCA) threshold. This behavior ensures that the malfunctioning terminal maximally defers to all other network traffic, minimizing its potential to cause interference or exacerbate channel congestion, thereby guaranteeing a "safe" operational failure that prioritizes network stability over its own throughput. The terminal might also broadcast a low-power "fault detected" message using a pre-defined Inter-BSS BSS color to signal its state to the network.

Combination Prior Art:

  1. Open vSwitch (Open-source virtual switch): The forwarding logic in Open vSwitch could be adapted to simulate or implement these "safe deference" rules for virtualized wireless terminals, enforcing a strict Inter-BSS policy for any endpoint flagged as faulty.
  2. Zephyr RTOS (Real-time operating system for IoT): Zephyr running on constrained IoT devices could implement a robust fault detection and recovery mechanism that includes activating this "safe deference" mode within its Wi-Fi or other wireless stacks.
  3. SNMP (Simple Network Management Protocol) open standard: The terminal, upon entering "Safe Deference" mode, could send an SNMP trap to a network management station, reporting its change in operational state and the reason for it.
graph TD
    A[Terminal (Normal State)] --> B{System Fault Detected?};
    B -- Yes --> C[Activate "Safe Deference" Mode];
    B -- No --> A;
    C --> D[Processor Configuration];
    D --> E[Override All PPDU Classifications];
    E --> F[Treat All Received PPDUs as Inter-BSS];
    F --> G[Apply Conservative Inter-BSS Channel Access Policy];
    G --> H[Maximize NAV / Increase CCA Threshold];
    H --> I[Minimally Access Channel];
    C --> J[Optionally: Broadcast "Fault Detected" Message with Generic Inter-BSS Color];

Derivations for Independent Claim 10

Claim 10: A wireless communication terminal that communicates wirelessly, the wireless communication terminal comprising: a transceiver; and a processor configured to receive a PLCP Processing Data Unit (PPDU) through the transceiver, and not to perform an operation based on the BSS color when the BSS color indicated by the PPDU is a predetermined value.

Derivative 10.1: Material & Component Substitution - Neuromorphic Processor for BSS Color Interpretation

Enabling Description:
A wireless communication terminal integrates a neuromorphic processor (e.g., IBM's TrueNorth or Intel's Loihi equivalent) specialized in pattern recognition for network packet headers. The processor's neuromorphic core is trained to recognize a "predetermined value" within the BSS color field of a received PPDU (e.g., 0b00000000 or a reserved range 0b111110xx). When this predetermined value is detected by the neuromorphic accelerator, it triggers a direct bypass of all BSS-color-dependent Spatial Reuse (SR) operations within the MAC layer. Instead of traditional sequential logic, the neuromorphic processor instantly classifies the PPDU's BSS color and, if it matches the predetermined value, forwards a specific flag to the main processor's MAC controller. This flag instructs the MAC controller to execute a fallback channel access policy that ignores BSS color for SR decisions, such as always operating with a baseline CCA threshold or treating it as an unknown external interference source (effectively disabling SR for that PPDU).

Combination Prior Art:

  1. OpenStreetMap (Open-source mapping data): In a location-aware network, if a terminal detects a predetermined BSS color, it could query OpenStreetMap data to infer if it's in a public, uncontrolled area, thus justifying a "no SR" policy.
  2. OpenCV (Open-source computer vision library): While seemingly unrelated, principles of pattern recognition from OpenCV (e.g., feature detection) could be adapted for training the neuromorphic processor to identify complex "predetermined BSS color" patterns beyond simple binary values.
  3. Project ACRN (Open-source hypervisor for IoT/embedded): ACRN could host a virtualized neuromorphic processing unit alongside a network stack, enabling real-time, low-latency BSS color analysis and subsequent "no-op" SR decisions.
flowchart TD
    A[Wireless Terminal] --> B{Transceiver};
    B --> C[Receive PPDU];
    C --> D[Neuromorphic Processor (BSS Color Detector)];
    D -- Detects BSS Color Field --> E{BSS Color Matches Predetermined Value?};
    E -- Yes --> F[Bypass SR Operations];
    E -- No --> G[Perform Standard SR Operations];
    F --> H[Apply Fallback Channel Access Policy];
    G --> I[Apply SR-based Channel Access Policy];
    H --> J[Access Channel];
    I --> J;

Derivative 10.2: Operational Parameter Expansion - High-Altitude Platform Station (HAPS) Mesh Networks

Enabling Description:
This derivative applies the "no BSS color operation" rule to wireless communication terminals acting as High-Altitude Platform Station (HAPS) nodes, forming a mesh network for regional broadband coverage. HAPS operate in a quasi-stationary manner at altitudes of 20-50 km, covering vast geographical areas. In this context, a "BSS color" identifies a logical coverage sector. If a HAPS terminal receives a PPDU where the BSS color is a predetermined value (e.g., 0x00 representing "unmanaged airspace" or "experimental zone"), its processor is configured not to perform any spatial reuse (SR) optimization based on that BSS color. This is critical for avoiding unintended interference with uncoordinated or legacy aircraft communication systems. Instead, it would default to a conservative channel access policy (e.g., maximum power and minimum spatial filtering, treating all such PPDUs as high-priority, non-deferrable signals) or forward them to a central ground controller for manual intervention, effectively disabling local SR decision-making to maintain air safety and regulatory compliance.

Combination Prior Art:

  1. Open-NMS (Open-source network management system): Open-NMS could monitor the status of HAPS terminals, receiving alerts when PPDUs with predetermined BSS colors are detected, triggering specific management policies.
  2. ETSI GR-GEO 007 (Geostationary HAPS regulation): Relevant sections of this standard (or similar open regulatory frameworks) could define what constitutes a "predetermined BSS color" in HAPS contexts and prescribe the "no operation" behavior for SR.
  3. OpenWRT (Open-source router firmware): While primarily for ground-based routers, OpenWRT's networking stack could be adapted for HAPS nodes to handle various MAC/PHY protocols, including the logic for BSS color interpretation and SR policy enforcement.
graph TD
    A[HAPS Terminal] --> B{Transceiver};
    B --> C[Receive PPDU];
    C --> D[Processor (HAPS MAC)];
    D --> E{Extract BSS Color};
    E -- Matches Predetermined Value --> F[No SR Operation Based on BSS Color];
    E -- Other Value --> G[Perform Standard SR Operation];
    F --> H[Apply Conservative Channel Access (e.g., Max Power, Min Filtering)];
    G --> I[Apply SR-Optimized Channel Access];
    H --> J[Transmit/Defer to Channel];
    I --> J;

Derivative 10.3: Cross-Domain Application - Smart Healthcare Wearable Network

Enabling Description:
In a smart healthcare setting, numerous wearable medical sensors (wireless communication terminals) form a Personal Area Network (PAN) or Body Area Network (BAN) around a patient, effectively creating a mobile BSS. These devices transmit vital patient data to a local hub (e.g., a smartphone or dedicated gateway). If a wearable sensor receives a PPDU where the BSS color is a predetermined value (e.g., 0x01 indicating "unregistered emergency device" or "rogue sensor"), its processor is specifically configured to not perform any spatial reuse (SR) operations based on that BSS color. Instead, it immediately flags the PPDU as originating from an untrusted or non-compliant source and triggers a default "maximum deferral" policy for any subsequent transmissions, or it might record the event and continue its own critical transmissions without attempting SR, ensuring that its own vital data is not compromised by unknown interference from the predetermined BSS color. This prevents a rogue or faulty device from exploiting SR mechanisms and causing critical data collisions.

Combination Prior Art:

  1. IEEE 802.15.6 (Body Area Networks standard): The MAC/PHY definitions in 802.15.6 could be extended to include BSS color-like fields and the specific handling of predetermined values for secure and reliable medical data transmission.
  2. FHIR (Fast Healthcare Interoperability Resources) open standard: FHIR could be used as the application layer protocol for the medical data, with events related to "predetermined BSS color" detection reported as part of a device's operational status.
  3. OpenMHealth (Open-source data specification for health data): This platform could standardize how a wearable device reports the detection of PPDUs with predetermined BSS colors, ensuring interoperability for incident reporting.
stateDiagram-v2
    state "Idle" as Idle
    state "Receive PPDU (Wearable)" as Rx_PPDU
    state "Extract BSS Color" as Extract_BSS_Color
    state "Check Predetermined Value" as Check_Predetermined
    state "No SR Operation" as No_SR
    state "Standard SR Operation" as Standard_SR
    state "Flag Untrusted Source" as Flag_Untrusted
    state "Apply Max Deferral" as Max_Deferral
    state "Continue Own Transmissions" as Own_Tx

    Idle --> Rx_PPDU : Detect PPDU
    Rx_PPDU --> Extract_BSS_Color : Parse Header
    Extract_BSS_Color --> Check_Predetermined : Is BSS Color Predetermined?

    Check_Predetermined --> No_SR : Yes
    No_SR --> Flag_Untrusted : Trigger Untrusted Policy
    Flag_Untrusted --> Max_Deferral : Enforce Deference
    Flag_Untrusted --> Own_Tx : OR Continue Critical Tx
    Max_Deferral --> Idle : Deferral Period
    Own_Tx --> Idle : Transmission Complete

    Check_Predetermined --> Standard_SR : No
    Standard_SR --> Idle : Perform Normal SR

Derivative 10.4: Integration with Emerging Tech - Blockchain-Verified BSS Color Enforcement

Enabling Description:
A wireless communication terminal operates within a localized, blockchain-governed network where BSS colors are dynamically assigned and immutably recorded on a distributed ledger. The processor's cryptographic module verifies the authenticity and validity of the received BSS color against the blockchain record. If the BSS color indicated by a received PPDU matches a predetermined value (e.g., a hash of a specific "unregistered device" contract, or 0xFE signaling "blockchain bypass for legacy devices"), the processor does not perform any operation based on the BSS color. Instead, it treats this PPDU as a "non-blockchain-compliant" or "legacy" transmission. This triggers a specific policy: either immediately discarding the PPDU (if unauthenticated), or applying a maximal deference (Inter-BSS) channel access policy to avoid interfering with potentially uncoordinated legacy devices, rather than attempting SR based on an unverified BSS color. The terminal might also log the detection of such predetermined BSS colors onto the blockchain, establishing an auditable record of non-compliant or legacy activity.

Combination Prior Art:

  1. Hyperledger Fabric (Open-source blockchain framework): Hyperledger Fabric could be used to host the distributed ledger for BSS color assignments and verification, with smart contracts managing dynamic allocation and predetermined value recognition.
  2. Ethereum client implementations (e.g., Geth): A lightweight Ethereum client on the terminal could interact with a public or private blockchain to verify BSS color values and trigger the "no operation" policy for predetermined/unverified ones.
  3. IPFS (InterPlanetary File System): IPFS could store the larger policy documents or configuration files related to BSS color management, with hashes stored on the blockchain, ensuring immutable and verifiable policy enforcement when a predetermined BSS color is detected.
flowchart TD
    A[Wireless Terminal] --> B{Transceiver};
    B --> C[Receive PPDU];
    C --> D[Processor (Blockchain Client + Crypto Module)];
    D --> E{Extract BSS Color};
    E -- Query Blockchain --> F{BSS Color Verified & Valid?};
    F -- No (Predetermined/Invalid) --> G[No SR Operation Based on BSS Color];
    F -- Yes --> H[Perform Standard SR Operations];
    G --> I[Apply Non-Blockchain-Compliant Policy (e.g., Discard, Max Deference)];
    H --> J[Apply SR-Optimized Channel Access];
    I --> K[Access Channel];
    J --> K;

Derivative 10.5: The "Inverse" or Failure Mode - Power Saving Mode Bypass for Predetermined BSS Colors

Enabling Description:
A wireless communication terminal features an advanced power management unit alongside its processor. Normally, the terminal enters a deep power save (doze) mode if a received Intra-BSS PPDU is not addressed to it, based on the BSS color. However, when the BSS color indicated by the received PPDU is a predetermined value (e.g., 0xFD for "universal alert" or 0x00 for "unassigned/broadcast"), the processor is specifically configured not to perform any power-saving operation that would typically be triggered by an Intra-BSS PPDU. Instead, it treats this predetermined BSS color as a special signal that requires the terminal to remain in an awake or monitoring state, potentially even forgoing scheduled doze periods. This inverse behavior ensures that critical alerts or general broadcast messages from untrusted or unassigned BSSs (identified by the predetermined BSS color) are always received and processed, even if it means temporarily consuming more power. This prioritizes universal reception of certain non-BSS-specific messages over individual power efficiency.

Combination Prior Art:

  1. OpenThread (Low-power mesh networking protocol): OpenThread's sleep/wake mechanisms could be modified to incorporate this "predetermined BSS color" bypass, ensuring critical mesh-wide alerts are received by sleeping nodes.
  2. Contiki-NG (Operating system for IoT devices): Contiki-NG's ContikiMAC or similar low-power listening protocols could be adapted to enforce this "awake" policy specifically when PPDUs with the predetermined BSS color are detected.
  3. MQTT (Message Queuing Telemetry Transport) open standard: If the predetermined BSS color signifies an MQTT "broadcast topic," the terminal could be programmed to awaken and listen specifically for that topic, bypassing normal BSS-color-driven power save.
sequenceDiagram
    participant T as Terminal
    participant AP as Access Point (or Peer)

    AP->>T: Transmit PPDU (with BSS Color)
    T->>T: Receive PPDU
    T->>T: Processor extracts BSS Color

    alt BSS Color is Predetermined Value
        T->>T: NOT perform power save operation based on BSS Color
        T->>T: Remain in Awake/Monitoring State
        T->>T: Process Universal Alert/Broadcast
    else BSS Color is a Standard Intra-BSS Color
        T->>T: Is PPDU addressed to me?
        alt Yes
            T->>T: Process PPDU
        else No
            T->>T: Enter Power Save Mode (Doze)
        end
    end
    T->>T: Continue Normal Operation

Generated 6/9/2026, 6:03:01 PM