Patent 12003976

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 Document for US Patent 12003976

Date: April 26, 2026

This Defensive Disclosure document outlines derivative variations and combination prior art scenarios for US Patent 12003976, titled "Method and apparatus for processing bandwidth intensive data streams using virtual media access control and physical layers." The purpose of this document is to establish prior art that would render future incremental improvements or related inventions in this field obvious or non-novel to a Person Having Ordinary Skill in the Art (PHOSITA).

Core Claim: Claim 1 (Wireless Networking Device with Virtual MAC/PHY and Bandwidth Allocation)

Enabling Principle: The core invention of Claim 1 involves a wireless networking device that intelligently allocates portions of available bandwidth from multiple wireless transceivers to satisfy application requirements via virtual MAC and PHY layers, critically ensuring that the utilization of one portion of bandwidth does not prevent other devices from using the remaining bandwidth simultaneously.

1. Material & Component Substitution

  • Derivative 1.1: Gallium Nitride (GaN)-based Transceivers with Software-Defined Radio (SDR) Physical Layer

    • Enabling Description: As of April 26, 2026, the first and second wireless transceivers (118) are implemented using Gallium Nitride (GaN) high-electron-mobility transistor (HEMT) technology for their power amplification and low-noise amplification stages within the actual PHY layer (116). The RF block (112), forming the virtual PHY layer, now comprises a Software-Defined Radio (SDR) module, where core physical layer functionalities such as modulation, coding, and frequency synthesis are executed predominantly on reconfigurable digital signal processors (DSPs) or Field-Programmable Gate Arrays (FPGAs). This architecture enables dynamic adjustment of carrier frequencies, modulation schemes (e.g., from QPSK to 256-QAM), and sub-band allocations with enhanced power efficiency and linearity, particularly for operation in millimeter-wave (mmWave) bands (e.g., 60 GHz per IEEE 802.11ay or emerging sub-THz bands). The virtual PHY interface dynamically reprograms the SDR's baseband and RF front-end configurations to utilize identified non-contiguous frequency blocks within the GaN transceiver's broad operational bandwidth. This allows the system to operate with greater flexibility and efficiency in spectrum utilization.
    • graph TD
    APP_INT[Application Interface] --> PROC_INT(Processing Interface)
    PROC_INT --> VMAC[Virtual MAC Interface (111)]
    PROC_INT --> VPHY_1[Virtual PHY Interface 1]
    PROC_INT --> VPHY_2[Virtual PHY Interface 2]
    VMAC -- Bandwidth Info & Control --> VPHY_1
    VMAC -- Bandwidth Info & Control --> VPHY_2
    VPHY_1 -- Dynamic SDR Config --> SDR_1(SDR Module 1)
    SDR_1 -- GaN RF Control --> PHY_1{Actual PHY 1 (GaN Transceiver)}
    PHY_1 -- Radio Signals (mmWave/Sub-THz) --> WL_LINK_1((Wireless Link 1))
    VPHY_2 -- Dynamic SDR Config --> SDR_2(SDR Module 2)
    SDR_2 -- GaN RF Control --> PHY_2{Actual PHY 2 (GaN Transceiver)}
    PHY_2 -- Radio Signals (mmWave/Sub-THz) --> WL_LINK_2((Wireless Link 2))
    VMAC -- Resource Control --> AMAC_1[Actual MAC 1 (114)]
    VMAC -- Resource Control --> AMAC_2[Actual MAC 2 (114)]
    AMAC_1 <--> PHY_1
    AMAC_2 <--> PHY_2

  • Derivative 1.2: Photonic Integrated Circuit (PIC)-based Transceivers for Optical Wireless Communication (OWC)

    • Enabling Description: The first and second wireless transceivers (118) are implemented using Photonic Integrated Circuits (PICs) capable of Free-Space Optical (FSO) communication, operating in the infrared or visible light spectrum. The "radio signals" are substituted with modulated optical beams. The actual PHY layer (116) consists of these PIC-based optical transceivers, employing arrays of vertical-cavity surface-emitting lasers (VCSELs) or coherent light sources for transmission and high-speed photodiodes for reception. The processing interface, through the virtual MAC (111) and virtual PHY (112), dynamically allocates sub-bands of the optical spectrum (e.g., specific wavelengths using Wavelength Division Multiplexing - WDM) or distinct spatial streams (e.g., using optical beamforming arrays) to satisfy application bandwidth requirements. The concept of "frequencies" is translated to specific optical wavelengths or spatial channels. This enables ultra-high bandwidth in line-of-sight communication scenarios, applicable in data centers or short-range outdoor links, while ensuring independent utilization of remaining optical resources.
    • graph TD
    APP_INT[Application Interface] --> PROC_INT(Processing Interface)
    PROC_INT --> VMAC[Virtual MAC Interface (111)]
    PROC_INT --> VPHY_1[Virtual PHY Interface 1]
    PROC_INT --> VPHY_2[Virtual PHY Interface 2]
    VMAC -- Bandwidth Info & Optical Alloc --> VPHY_1
    VMAC -- Bandwidth Info & Optical Alloc --> VPHY_2
    VPHY_1 -- PIC Control (WDM/Spatial) --> PIC_1(PIC Optical Transceiver 1)
    PIC_1 -- Modulated Light Beams --> OWC_LINK_1((Optical Wireless Link 1))
    VPHY_2 -- PIC Control (WDM/Spatial) --> PIC_2(PIC Optical Transceiver 2)
    PIC_2 -- Modulated Light Beams --> OWC_LINK_2((Optical Wireless Link 2))
    VMAC -- Resource Control --> AMAC_1[Actual MAC 1 (114)]
    VMAC -- Resource Control --> AMAC_2[Actual MAC 2 (114)]
    AMAC_1 <--> PIC_1
    AMAC_2 <--> PIC_2

2. Operational Parameter Expansion

  • Derivative 1.3: Terahertz (THz) Communication for Intra-Data Center Networking

    • Enabling Description: The wireless networking device is adapted for extreme bandwidth communication within a tightly controlled data center environment, specifically utilizing Terahertz (THz) frequency bands (e0.1 THz to 10 THz). The transceivers (118) are optimized for short-range, ultra-high-speed (multi-Tbps) links, enabling wireless connectivity between server racks, individual servers, or high-performance computing clusters. The processing interface, via the virtual MAC (111) and virtual PHY (112) layers, dynamically allocates specific THz sub-bands or distinct spatial streams (e.g., using highly directional antenna arrays) to individual applications requiring massive data rates. Environmental monitoring (e.g., localized humidity and temperature sensors) feeds into the decision block (106) for real-time adaptive THz channel selection, as THz propagation is highly sensitive to atmospheric absorption and reflections within the confined data center space. This ensures that a portion of the THz bandwidth can be used for one application without impeding other applications on remaining THz resources.
    • graph TD
    APP_INT[Application Layer - Multi-Tbps Apps] --> PROC_INT(Processing Interface)
    PROC_INT --> VMAC[Virtual MAC Interface (111)]
    PROC_INT --> VPHY_1[Virtual PHY Interface 1]
    PROC_INT --> VPHY_2[Virtual PHY Interface 2]
    VMAC -- BW Allocation & THz Channeling --> VPHY_1
    VMAC -- BW Allocation & THz Channeling --> VPHY_2
    VPHY_1 -- THz Channel Config --> THz_TRCV_1(THz Transceiver 1)
    THz_TRCV_1 -- Tbps Link (Short Range) --> DC_LINK_1((Data Center Wireless Link 1))
    VPHY_2 -- THz Channel Config --> THz_TRCV_2(THz Transceiver 2)
    THz_TRCV_2 -- Tbps Link (Short Range) --> DC_LINK_2((Data Center Wireless Link 2))
    VMAC -- Resource Control --> AMAC_1[Actual MAC 1 (114)]
    VMAC -- Resource Control --> AMAC_2[Actual MAC 2 (114)]
    AMAC_1 <--> THz_TRCV_1
    AMAC_2 <--> THz_TRCV_2
    ENV_SENS[Environmental Sensors (Humidity/Temp)] --> DEC_BLOCK[Decision Block (106)]
    DEC_BLOCK -- Adaptive THz Selection --> VMAC

  • Derivative 1.4: Underwater Acoustic Communication for Deep-Sea Sensor Networks

    • Enabling Description: The wireless networking device is configured to operate in extreme deep-sea environments, replacing traditional RF transceivers with acoustic transducers (hydrophones and projectors) operating at low frequencies (e.g., kilohertz range) suitable for underwater acoustic propagation. The actual PHY layer (116) manages these acoustic transducers, implementing protocols adapted for highly variable, multipath-rich, and lossy acoustic channels. The virtual MAC (111) and virtual PHY (112) layers dynamically allocate specific acoustic frequency bands, time slots, and spatial beams (using transducer arrays) to manage data streams from subsea sensors (e.g., seismic, oceanographic, biological data). Given the severe limitations of acoustic bandwidth, sophisticated virtual layer management is crucial for optimal resource utilization, ensuring that allocated frequency portions for one sensor do not prevent other acoustic nodes from communicating on available bands or time slots, managed transparently to the application layer above.
    • graph TD
    APP_INT[Application Layer - Subsea Sensor Data] --> PROC_INT(Processing Interface)
    PROC_INT --> VMAC[Virtual MAC Interface (111)]
    PROC_INT --> VPHY_1[Virtual PHY Interface 1]
    PROC_INT --> VPHY_2[Virtual PHY Interface 2]
    VMAC -- Acoustic Channel Alloc --> VPHY_1
    VMAC -- Acoustic Channel Alloc --> VPHY_2
    VPHY_1 -- Transducer Control --> ACOUSTIC_TRCV_1(Acoustic Transducer 1)
    ACOUSTIC_TRCV_1 -- Acoustic Waves (kHz) --> UW_LINK_1((Underwater Acoustic Link 1))
    VPHY_2 -- Transducer Control --> ACOUSTIC_TRCV_2(Acoustic Transducer 2)
    ACOUSTIC_TRCV_2 -- Acoustic Waves (kHz) --> UW_LINK_2((Underwater Acoustic Link 2))
    VMAC -- Resource Control --> AMAC_1[Actual MAC 1 (114)]
    VMAC -- Resource Control --> AMAC_2[Actual MAC 2 (114)]
    AMAC_1 <--> ACOUSTIC_TRCV_1
    AMAC_2 <--> ACOUSTIC_TRCV_2
    UW_ENV[Underwater Environment] --> VPHY_1
    UW_ENV --> VPHY_2

3. Cross-Domain Application

  • Derivative 1.5: Autonomous Farming Vehicle Swarm Coordination

    • Enabling Description: The wireless networking device is integrated into each autonomous farming vehicle (e.g., drones for spraying, ground robots for planting/harvesting) to facilitate swarm coordination and data exchange. Each vehicle's device communicates with a central base station and other vehicles. The "application layer" provides tasks such as coordinated path planning, real-time sensor data collection (soil moisture, crop health via hyperspectral imaging), and synchronized robotic actions. The wireless bandwidth requirement varies dynamically (e.g., high for video analytics, low for navigation commands). The virtual MAC (111) and virtual PHY (112) layers in each vehicle dynamically manage communication links between vehicles and to the base station, allocating specific ISM band frequencies (e.g., 2.4 GHz, 5.8 GHz, or Sub-GHz for extended range) or highly directional antenna beams. This ensures high-bandwidth data transfer for critical operations (e.g., drone-based crop health mapping) while simultaneously maintaining low-bandwidth control signals for other vehicles, all managed transparently to the farming application layer.
    • graph TD
    FARM_APP[Farming Ops App (Central)] --> BASE_STA(Base Station WND)
    BASE_STA --> VMAC_BS[VMAC BS]
    BASE_STA --> VPHY_BS[VPHY BS]
    VMAC_BS -- Task Coordination & BW Alloc --> VPHY_BS
    VPHY_BS -- Radio Link 1 --> VEH_1(Autonomous Vehicle 1 WND)
    VPHY_BS -- Radio Link 2 --> VEH_2(Autonomous Vehicle 2 WND)
    VEH_1 --> VMAC_V1[VMAC V1]
    VEH_1 --> VPHY_V1[VPHY V1]
    VEH_2 --> VMAC_V2[VMAC V2]
    VEH_2 --> VPHY_V2[VPHY V2]
    VPHY_V1 --> AV_TRCV_1[Trxvr in Vehicle 1]
    VPHY_V2 --> AV_TRCV_2[Trxvr in Vehicle 2]
    AV_TRCV_1 -- Inter-Vehicle Link --> AV_TRCV_2
    SENSOR_1[Vehicle 1 Sensors] --> AV_TRCV_1
    SENSOR_2[Vehicle 2 Sensors] --> AV_TRCV_2

  • Derivative 1.6: Smart City Infrastructure Management (Traffic/Environmental Monitoring)

    • Enabling Description: The wireless networking device is deployed as a core component within smart city infrastructure, such as intelligent traffic lights, environmental monitoring stations, public safety cameras, or smart waste bins. These devices require robust, high-bandwidth wireless connectivity for video analytics, massive sensor data aggregation, and command/control functions. The "application layer" includes traffic flow optimization, air quality monitoring, public safety alerts, and waste collection logistics systems. The virtual MAC (111) and virtual PHY (112) layers dynamically allocate available wireless spectrum (e.g., licensed cellular bands, unlicensed 5.9 GHz for Vehicle-to-Everything (V2X) communication, or millimeter-wave for high-capacity backhaul). They prioritize data streams, for example, giving real-time emergency vehicle video feeds maximum aggregated bandwidth, while ambient air quality sensor data is transmitted on a lower-priority, shared portion of spectrum, all managed transparently to the various city management applications.
    • graph TD
    CITY_MGMT_APP[Smart City Mgmt App (Central)] --> CENTRAL_HUB(Central Control Hub)
    CENTRAL_HUB --> WND_A(WND A - Traffic Light)
    CENTRAL_HUB --> WND_B(WND B - Env Sensor)
    WND_A --> VMAC_A[VMAC A]
    WND_A --> VPHY_A[VPHY A]
    WND_B --> VMAC_B[VMAC B]
    WND_B --> VPHY_B[VPHY B]
    VMAC_A -- BW Alloc & Priority --> VPHY_A
    VMAC_B -- BW Alloc & Priority --> VPHY_B
    VPHY_A --> TRCV_A_1[Trxvr A1 (Video)]
    VPHY_A --> TRCV_A_2[Trxvr A2 (Control)]
    VPHY_B --> TRCV_B_1[Trxvr B1 (Sensor Data)]
    TRCV_A_1 -- Wireless Link --> CENTRAL_HUB
    TRCV_A_2 -- Wireless Link --> CENTRAL_HUB
    TRCV_B_1 -- Wireless Link --> CENTRAL_HUB

4. Integration with Emerging Tech

  • Derivative 1.7: AI-Driven Dynamic Spectrum Allocation with Real-time IoT Feedback

    • Enabling Description: The processing layer (104) is augmented with an AI-driven optimization engine. This engine, integrated into the decision block (106) and ultra-streaming block (110), utilizes machine learning (ML) models trained on historical and real-time network performance data, environmental conditions (from IoT sensors embedded in the networking device and surrounding infrastructure, such as RF environment scanners), and application-specific Quality of Service (QoS) metrics. As of April 26, 2026, the AI continuously predicts optimal bandwidth allocation strategies, including identifying contiguous/non-contiguous frequency portions and suitable transceivers for each application's data stream. IoT sensors provide real-time feedback on channel quality, interference levels, client device battery status, and local environmental factors. The virtual MAC (111) and virtual PHY (112) layers implement the AI's recommendations, dynamically reconfiguring transceiver resources in a proactive manner to maximize throughput, minimize latency, and ensure reliability, all transparently to the application.
    • graph TD
    APP_INT[Application Interface] --> PROC_INT(Processing Interface)
    PROC_INT --> AI_OPTIM(AI Optimization Engine)
    AI_OPTIM -- Resource Allocation Policy --> VMAC[Virtual MAC (111)]
    AI_OPTIM -- Resource Allocation Policy --> VPHY_1[Virtual PHY 1]
    AI_OPTIM -- Resource Allocation Policy --> VPHY_2[Virtual PHY 2]
    IOT_SENS[IoT Sensors (Env, Perf, RF Scanners)] --> AI_OPTIM
    AI_OPTIM -- Training Data --> ML_MODELS[ML Models]
    VMAC --> AMAC_1[Actual MAC 1]
    VMAC --> AMAC_2[Actual MAC 2]
    VPHY_1 --> TRCV_1[Transceiver 1]
    VPHY_2 --> TRCV_2[Transceiver 2]
    TRCV_1 -- Wireless Link --> RECIPIENT
    TRCV_2 -- Wireless Link --> RECIPIENT

  • Derivative 1.8: Edge Computing with Swarm Intelligence for Resource Management

    • Enabling Description: The processing layer (104) is distributed across multiple wireless networking devices, each functioning as an edge computing node. Instead of a single central AI, a swarm intelligence algorithm orchestrates resource allocation. Each device's decision block (106) and ultra-streaming block (110) contain lightweight software agents that communicate and cooperate with agents on neighboring devices to collectively determine optimal bandwidth distribution strategies. This decentralized approach uses local information (e.g., immediate channel conditions, local application demands) and peer-to-peer consensus to allocate portions of transceiver bandwidth dynamically. IoT sensors are embedded in each edge node to provide local environmental and performance data for agent decisions. This system dynamically adapts to localized congestion or interference, re-allocating frequency blocks and transceiver resources across the mesh of edge nodes.
    • graph TD
    APP_A[App A] --> EDGE_NODE_1(Edge Node 1 WND)
    APP_B[App B] --> EDGE_NODE_2(Edge Node 2 WND)
    EDGE_NODE_1 -- Swarm Agent --> VMAC_1[VMAC 1]
    EDGE_NODE_1 -- Swarm Agent --> VPHY_1[VPHY 1]
    EDGE_NODE_2 -- Swarm Agent --> VMAC_2[VMAC 2]
    EDGE_NODE_2 -- Swarm Agent --> VPHY_2[VPHY 2]
    VMAC_1 <--> VPHY_1
    VMAC_2 <--> VPHY_2
    VPHY_1 --> TRCV_1_1[Trxvr 1.1]
    VPHY_1 --> TRCV_1_2[Trxvr 1.2]
    VPHY_2 --> TRCV_2_1[Trxvr 2.1]
    VPHY_2 --> TRCV_2_2[Trxvr 2.2]
    TRCV_1_1 -- Wireless Link --> RECIPIENT_A
    TRCV_2_1 -- Wireless Link --> RECIPIENT_B
    VMAC_1 -- Swarm Comm --> VMAC_2
    IOT_SENS_1[IoT Sensors 1] --> EDGE_NODE_1
    IOT_SENS_2[IoT Sensors 2] --> EDGE_NODE_2

5. The "Inverse" or Failure Mode

  • Derivative 1.9: Graceful Degradation and Low-Power Emergency Mode

    • Enabling Description: Upon detection of a critical hardware failure (e.g., a transceiver module fails, power supply degradation) or severe environmental interference (e.g., jamming, extreme weather impacting RF) exceeding predefined thresholds, the processing interface (104) triggers a "graceful degradation" protocol. The decision block (106), informed by self-diagnostic routines and external IoT sensor data, reduces the allocated bandwidth for non-critical applications, potentially suspending high-bandwidth data streams entirely. It then re-allocates the remaining functional transceiver resources to maintain only essential services (e.g., emergency communication, critical telemetry, minimal control signals) in a low-power, limited-functionality mode. This could involve switching to a more robust but lower-bandwidth modulation scheme (e.g., BPSK over 64-QAM), utilizing only a single, most reliable frequency band, or reducing transmit power. The virtual MAC (111) and virtual PHY (112) layers dynamically reconfigure the operational parameters of the surviving transceivers to prioritize and sustain these critical minimal services, explicitly signaling to the application layer that reduced bandwidth is available. This ensures a safe shutdown or sustained minimal operation rather than a catastrophic system failure.
    • stateDiagram-v2
    [*] --> OPERATIONAL_MODE
    OPERATIONAL_MODE --> NORMAL_OPERATION
    NORMAL_OPERATION --> MONITOR_HEALTH: Continuous Monitoring
    MONITOR_HEALTH --> CRITICAL_FAILURE: Hardware Fail | Env Interference
    CRITICAL_FAILURE --> GRACEFUL_DEGRADATION: Trigger Protocol
    GRACEFUL_DEGRADATION --> LOW_POWER_EMERGENCY_MODE: Reallocate Resources
    LOW_POWER_EMERGENCY_MODE --> NOTIFY_APP: Signal Reduced BW
    LOW_POWER_EMERGENCY_MODE --> MONITOR_HEALTH: Continue Monitoring
    LOW_POWER_EMERGENCY_MODE --> RECOVERY_MODE: Issue Resolved
    RECOVERY_MODE --> NORMAL_OPERATION
    CRITICAL_FAILURE --> EMERGENCY_SHUTDOWN: Unrecoverable
    EMERGENCY_SHUTDOWN --> [*]
    GRACEFUL_DEGRADATION --> EMERGENCY_SHUTDOWN: Unrecoverable

    state NORMAL_OPERATION {
        VMAC_NORMAL: Virtual MAC (Full BW)
        VPHY_NORMAL: Virtual PHY (Full BW)
        TRCV_1_NORMAL: Transceiver 1 (Full BW)
        TRCV_2_NORMAL: Transceiver 2 (Full BW)
    }
    state GRACEFUL_DEGRADATION {
        VMAC_DEGRADE: Virtual MAC (Reduced BW)
        VPHY_DEGRADE: Virtual PHY (Reduced BW)
        TRCV_SURVIVING: Surviving Transceivers
        APP_PRIORITY: Prioritize Critical Apps
    }
    state LOW_POWER_EMERGENCY_MODE {
        VMAC_EMERGENCY: Virtual MAC (Minimal BW)
        VPHY_EMERGENCY: Virtual PHY (Minimal BW)
        TRCV_MINIMAL: Minimal Transceiver Use
        ROBUST_MOD: Robust Modulation
    }

  • Derivative 1.10: Beacon-Only Network Health Monitoring Mode

    • Enabling Description: If the primary bandwidth-intensive applications become inactive or experience prolonged network outages, the processing interface (104) commands the virtual MAC (111) and virtual PHY (112) layers to enter an ultra-low-power "beacon-only" network health monitoring mode. In this mode, all high-bandwidth data stream transmissions are ceased. Instead, the transceivers (118) are configured to emit only periodic, very low-power beacon signals on a pre-defined, narrow-band emergency channel. These beacons contain minimal diagnostic information (e.g., device ID, battery level, last known operational status). The virtual PHY layer orchestrates aggressive power cycling of the transceivers and, if available, utilizes highly energy-efficient radio front-ends (e.g., passive IoT radio, backscatter communication modules) to extend the device's operational life. The virtual MAC layer manages the beacon transmission schedule to minimize overall energy consumption. This mode allows the wireless networking device to remain discoverable and report its basic status for remote diagnostics and recovery efforts, without consuming significant power or network bandwidth.
    • graph LR
    APP_IDLE[Applications Idle/Failed] --> DEC_BLOCK(Decision Block 106)
    DEC_BLOCK -- Enter Monitoring Mode --> VMAC[Virtual MAC (111)]
    VMAC --> VPHY[Virtual PHY (112)]
    VPHY -- Configure Low Power --> TRCV_1(Transceiver 1)
    VPHY -- Configure Low Power --> TRCV_2(Transceiver 2)
    TRCV_1 -- Periodic Beacon (Low Power) --> NETWORK[Network Monitoring System]
    TRCV_2 -- Periodic Beacon (Low Power) --> NETWORK
    VPHY -- Power Cycle Control --> TRCV_1
    VPHY -- Power Cycle Control --> TRCV_2
    VMAC -- Schedule Management --> TRCV_1
    VMAC -- Schedule Management --> TRCV_2
    BATTERY_MON[Battery Monitor] --> DEC_BLOCK
    OUTAGE_DET[Outage Detector] --> DEC_BLOCK

Core Claim: Claim 21 (Bandwidth Aggregation for Transmission)

Enabling Principle: Building upon Claim 1, Claim 21 introduces the aggregation of bandwidth portions from multiple transceivers to simultaneously transmit a single data stream to a recipient, thereby increasing effective throughput.

1. Material & Component Substitution

  • Derivative 21.1: Millimeter-Wave Phased Array Antennas with Reconfigurable RF Front-ends
    • Enabling Description: As of April 26, 2026, the first and second wireless transceivers (118) are implemented as millimeter-wave (mmWave) phased array antenna modules, each integrating independent digital beamforming capabilities and reconfigurable RF front-ends (e.g., using SiGe BiCMOS or CMOS for tunable filters and variable gain amplifiers). The actual PHY layers (116) support dynamic configuration of antenna elements to form multiple, steerable beams simultaneously. The processing interface (104) and its virtual MAC/PHY layers (111, 112) aggregate bandwidth by dynamically partitioning and directing different data sub-streams of the first data stream via spatially distinct beams from the first transceiver, and simultaneously utilizing additional beams or orthogonal frequency channels from the second transceiver. The reconfigurable RF front-ends allow for on-the-fly adjustment to utilize non-contiguous frequency blocks within the mmWave spectrum for robust aggregation, all transparently to the application layer.
    • graph TD
    APP_INT[Application Interface] --> PROC_INT(Processing Interface)
    PROC_INT --> VMAC[Virtual MAC (111)]
    PROC_INT --> VPHY_1[Virtual PHY 1]
    PROC_INT --> VPHY_2[Virtual PHY 2]
    VMAC -- Aggregation Logic & Data Slicing --> VPHY_1
    VMAC -- Aggregation Logic & Data Slicing --> VPHY_2
    VPHY_1 -- Beamforming/RF Reconfig --> MMA_TRCV_1(mmWave Phased Array Trxvr 1)
    VPHY_2 -- Beamforming/RF Reconfig --> MMA_TRCV_2(mmWave Phased Array Trxvr 2)
    MMA_TRCV_1 -- Multiple Beams/Channels (Sub-streams) --> WL_LINK_1((Wireless Link 1))
    MMA_TRCV_2 -- Multiple Beams/Channels (Sub-streams) --> WL_LINK_2((Wireless Link 2))
    WL_LINK_1 -- Aggregated Data --> RECIPIENT(Recipient)
    WL_LINK_2 -- Aggregated Data --> RECIPIENT
    AMAC_1[Actual MAC 1] <--> MMA_TRCV_1
    AMAC_2[Actual MAC 2] <--> MMA_TRCV_2

2. Operational Parameter Expansion

  • Derivative 21.2: High-Altitude Platform Station (HAPS) for Regional Connectivity Aggregation
    • Enabling Description: The wireless networking device is deployed as a payload on a High-Altitude Platform Station (HAPS) operating in the stratosphere (e.g., at 20 km altitude). The device provides regional broadband connectivity, and its transceivers (118) are multi-band, highly directional antennas optimized for ground-to-HAPS and HAPS-to-ground links across large geographical areas. The virtual MAC (111) and virtual PHY (112) layers aggregate bandwidth from multiple distinct frequency bands (e.g., Ka-band, E-band, V-band) or different transceivers on the HAPS to serve high-demand regions or specific events. For instance, during an emergency response, the HAPS can aggregate all available bandwidth from its multiple radios to provide maximum data rates to emergency responders on the ground, simultaneously transmitting a unified, high-priority data stream. This operation occurs under extreme atmospheric conditions (low pressure, extreme temperatures), requiring robust component selection and dynamic beam steering controlled by the virtual PHY to compensate for HAPS movement and atmospheric interference.
    • graph TD
    HAPS_APP[HAPS Application Layer (Ground)] --> HAPS_WND(HAPS Wireless Networking Device)
    HAPS_WND --> VMAC_HAPS[Virtual MAC (HAPS)]
    HAPS_WND --> VPHY_HAPS[Virtual PHY (HAPS)]
    VMAC_HAPS -- BW Aggregation Logic --> VPHY_HAPS
    VPHY_HAPS --> HAPS_TRCV_1(HAPS Transceiver 1 - Ka-Band)
    VPHY_HAPS --> HAPS_TRCV_2(HAPS Transceiver 2 - E-Band)
    HAPS_TRCV_1 -- Dir Link (Sub-stream 1) --> GROUND_REGION_C(Ground Recipient Region C - High Demand)
    HAPS_TRCV_2 -- Dir Link (Sub-stream 2) --> GROUND_REGION_C
    GROUND_REGION_C -- Aggregated Data Rx --> USER_C(User C)
    ATM_COND[Atmospheric Conditions] --> VPHY_HAPS

3. Cross-Domain Application

  • Derivative 21.3: Autonomous Underwater Vehicle (AUV) for Data Offloading
    • Enabling Description: The wireless networking device is integrated into an Autonomous Underwater Vehicle (AUV) tasked with high-speed data offloading from subsea sensor arrays or other AUVs. Upon surfacing, the AUV's wireless networking device aggregates data from multiple distinct transceivers to expedite the transfer of large scientific datasets (e.g., high-resolution sonar maps, environmental profiles) to a mother ship or surface buoy. For instance, the AUV might rapidly aggregate data across its multi-band satellite (e.g., Iridium, Inmarsat) transceiver and a local high-speed RF transceiver (e.g., customized short-range Wi-Fi or directional LTE link) to simultaneously transmit collected scientific data to a surface recipient. The virtual MAC (111) and virtual PHY (112) layers dynamically allocate portions of satellite bandwidth and local RF bandwidth, transparently managing the different latencies and throughputs of each link type to form a single, high-capacity logical channel for the data offload.
    • graph TD
    AUV_APP[AUV Data Collection App] --> AUV_WND(AUV Wireless Networking Device)
    AUV_WND --> VMAC_AUV[VMAC AUV]
    AUV_WND --> VPHY_AUV[VPHY AUV]
    VMAC_AUV -- BW Aggregation Logic --> VPHY_AUV
    VPHY_AUV --> SAT_TRCV(Satellite Transceiver)
    VPHY_AUV --> RF_TRCV(Local RF Transceiver - WiFi/LTE)
    SAT_TRCV -- Satellite Link (Sub-stream 1) --> MOTHER_SHIP(Mother Ship)
    RF_TRCV -- RF Link (Sub-stream 2) --> MOTHER_SHIP
    SENSOR_DATA[AUV Sensor Data] --> AUV_APP
    MOTHER_SHIP -- Aggregated Data Rx --> DATA_PROC(Data Processing)

4. Integration with Emerging Tech

  • Derivative 21.4: AI-Optimized Multi-Path Aggregation with Blockchain for Trust
    • Enabling Description: The processing layer (104) incorporates an AI-driven optimization engine utilizing deep reinforcement learning (DRL) to optimize multi-path bandwidth aggregation. This AI, integrated into the ultra-streaming block (110), learns to dynamically partition the first data stream across multiple identified bandwidth portions from different transceivers. It factors in real-time channel conditions (obtained from embedded IoT sensors and active probing), network congestion levels, and application-specific Quality of Service (QoS) requirements (e.g., latency, jitter, packet loss). The virtual MAC (111) and virtual PHY (112) layers execute the AI's complex slicing, scheduling, and routing decisions for simultaneous transmission. A permissioned blockchain is used to create an immutable record of each aggregated data packet's path, its assigned bandwidth portion, and associated performance metrics. This allows for transparent verification of data integrity and service level agreement (SLA) compliance across the aggregated paths, enhancing trust in data delivery and providing an auditable log as of April 26, 2026.
    • graph TD
    APP_INT[Application Interface] --> PROC_INT(Processing Interface)
    PROC_INT --> AI_DRL(AI-Driven Reinforcement Learning)
    AI_DRL -- Aggregation Strategy & Data Slicing --> VMAC[Virtual MAC (111)]
    AI_DRL -- Aggregation Strategy & Data Slicing --> VPHY_1[Virtual PHY 1]
    AI_DRL -- Aggregation Strategy & Data Slicing --> VPHY_2[Virtual PHY 2]
    IOT_SENS[IoT Sensors (Channel, Congestion)] --> AI_DRL
    VMAC -- Data Stream Partitioning --> TRCV_1[Transceiver 1]
    VMAC -- Data Stream Partitioning --> TRCV_2[Transceiver 2]
    TRCV_1 -- Wireless Link 1 --> RECIPIENT
    TRCV_2 -- Wireless Link 2 --> RECIPIENT
    TRCV_1 -- Performance Metrics (Log) --> BLOCKCHAIN[Permissioned Blockchain]
    TRCV_2 -- Performance Metrics (Log) --> BLOCKCHAIN
    BLOCKCHAIN -- Verifiable QoS --> SLA_MONITOR(SLA Monitor)

5. The "Inverse" or Failure Mode

  • Derivative 21.5: Adaptive Failover with Single-Transceiver Redundancy
    • Enabling Description: In a system utilizing bandwidth aggregation for transmission, a robust failover mechanism is implemented. If one of the aggregated wireless transceivers (e.g., the second transceiver) experiences a failure (e.g., complete loss of signal, critical component malfunction) or significant performance degradation (detected by the virtual PHY's continuous monitoring of error rates and signal strength), the processing interface (104) automatically reconfigures the virtual MAC (111) and virtual PHY (112) layers. The system dynamically transfers the entire aggregated data stream to the remaining single functional transceiver (e.g., the first transceiver). This involves dynamically resizing the data stream or reducing its quality (e.g., lowering video resolution, reducing telemetry granularity) to fit within the single transceiver's capacity, while maintaining the application's connection without requiring disassociation. The decision block (106) implements logic to trigger this adaptive failover based on predefined performance thresholds or error rate spikes, ensuring continued, albeit potentially reduced, service.
    • stateDiagram-v2
    [*] --> AGGREGATION_MODE
    AGGREGATION_MODE --> MONITOR_TRCV_HEALTH: Continuous Health Check
    MONITOR_TRCV_HEALTH --> NORMAL_AGGREGATION: All Trxvr Healthy
    MONITOR_TRCV_HEALTH --> FAILURE_DETECTED: Trxvr 2 Failure/Degradation
    FAILURE_DETECTED --> FAILOVER_INITIATED: Trigger Failover Protocol
    FAILOVER_INITIATED --> SINGLE_TRCV_MODE: Reconfigure VMAC/VPHY
    SINGLE_TRCV_MODE --> REDUCED_BW_SERVICE: Prioritize Connectivity
    REDUCED_BW_SERVICE --> NOTIFY_APP: Signal Reduced BW
    SINGLE_TRCV_MODE --> REPAIR_COMPLETE: Trxvr 2 Repaired/Recovered
    REPAIR_COMPLETE --> AGGREGATION_MODE
    FAILURE_DETECTED --> CRITICAL_FAIL: Both Trxvr Fail
    CRITICAL_FAIL --> EMERGENCY_SHUTDOWN: System Halt

    state NORMAL_AGGREGATION {
        VMAC_AGG: VMAC (Aggregating)
        VPHY_AGG: VPHY (Aggregating)
        TRCV_1_ACTIVE: Trxvr 1 (Active)
        TRCV_2_ACTIVE: Trxvr 2 (Active)
    }
    state SINGLE_TRCV_MODE {
        VMAC_SINGLE: VMAC (Single Trxvr)
        VPHY_SINGLE: VPHY (Single Trxvr)
        TRCV_1_ACTIVE_ONLY: Trxvr 1 (Active Only)
        TRCV_2_INACTIVE: Trxvr 2 (Inactive/Failed)
    }

Core Claim: Claim 25 (Simultaneous Transmit/Receive)

Enabling Principle: Claim 25 extends the concept of virtualization to enable simultaneous transmission of a first data stream via a first transceiver and reception of a second data stream via a second transceiver, without requiring disassociation and allowing independent utilization of remaining bandwidth portions.

1. Material & Component Substitution

  • Derivative 25.1: Full-Duplex Wireless Transceivers with Real-Time Self-Interference Cancellation (SIC)
    • Enabling Description: As of April 26, 2026, the wireless networking device replaces the reliance on separate physical transceivers for simultaneous transmit (TX) and receive (RX) with a single "full-duplex" wireless transceiver (118) capable of transmitting and receiving simultaneously on the same frequency band. This capability is achieved through advanced real-time self-interference cancellation (SIC) implemented at the actual PHY layer (116). The processing interface (104) allocates distinct portions of this single full-duplex transceiver's bandwidth. The virtual MAC (111) and virtual PHY (112) layers dynamically configure the SIC engine parameters and assign specific frequency sub-bands or time-slots within the same physical channel for simultaneous transmit (first data stream) and receive (second data stream) operations, transparently to the application. This allows for more efficient hardware utilization while achieving the simultaneous TX/RX functionality.
    • graph TD
    APP_TX[Application TX Data Stream] --> PROC_INT(Processing Interface)
    APP_RX[Application RX Data Stream] --> PROC_INT
    PROC_INT --> VMAC[Virtual MAC (111)]
    PROC_INT --> VPHY[Virtual PHY (112)]
    VMAC -- TX/RX Resource Alloc --> VPHY
    VPHY -- SIC Control & Channel Config --> FD_TRCV(Full-Duplex Transceiver)
    FD_TRCV -- TX Data Stream (Portion 1) --> WIRELESS_LINK((Wireless Link))
    FD_TRCV -- RX Data Stream (Portion 2) --> WIRELESS_LINK
    WIRELESS_LINK -- Data to Recipient --> RECIPIENT_TX(Recipient for TX)
    RECIPIENT_RX(Recipient for RX) -- Data from Recipient --> WIRELESS_LINK
    AMAC[Actual MAC (114)] <--> FD_TRCV
    APHY[Actual PHY (116)] <--> FD_TRCV

2. Operational Parameter Expansion

  • Derivative 25.2: Satellite Constellation Management for Bi-Directional High-Throughput Links
    • Enabling Description: The simultaneous transmit/receive concept is applied to a satellite ground station managing communications with a constellation of Low Earth Orbit (LEO) or Geostationary Earth Orbit (GEO) satellites. The "wireless networking device" is the ground station, equipped with multiple steerable parabolic antennas, each acting as a wireless transceiver (118). A first antenna (first transceiver) simultaneously transmits high-bandwidth data (e.g., uplink for satellite command and control, user data) to a target satellite. Simultaneously, a second, independently steerable antenna (second transceiver) receives high-bandwidth telemetry or downlink user data from a different satellite (or the same satellite on an orthogonal frequency/polarization). The virtual MAC (111) and virtual PHY (112) layers manage precise beam steering, frequency allocation (e.g., Ku-band, Ka-band), and power control for each antenna to ensure optimal bi-directional throughput without mutual interference, transparently to the satellite operations application. This handles extreme distances, high data rates, and dynamic Doppler shifts inherent in satellite communications.
    • graph TD
    SAT_OPS_APP[Satellite Operations App] --> GROUND_STATION(Satellite Ground Station WND)
    GROUND_STATION --> VMAC_GS[VMAC Ground Station]

GROUND_STATION --> VPHY_GS[VPHY Ground Station]
VMAC_GS -- TX/RX Resource Alloc --> VPHY_GS
VPHY_GS --> ANT_1(Antenna 1 - TX Transceiver)
VPHY_GS --> ANT_2(Antenna 2 - RX Transceiver)
ANT_1 -- Uplink Data --> LEO_SAT_A(LEO Satellite A)
LEO_SAT_A -- Downlink Data --> ANT_2
ANT_1 -- Uplink Data --> GEO_SAT_B(GEO Satellite B)
GEO_SAT_B -- Downlink Data --> ANT_2
AMAC_GS[Actual MAC GS] <--> ANT_1
AMAC_GS <--> ANT_2
GEO_SYN[Geosynchronous Orbit]
LEO_ORBIT[Low Earth Orbit]
```

3. Cross-Domain Application

  • Derivative 25.3: Hospital Emergency Ward Patient Monitoring and Data Upload
    • Enabling Description: The wireless networking device is implemented in a hospital emergency ward as a central patient monitoring hub. This hub collects real-time vital signs and medical imaging from various bedside devices (recipients) and simultaneously uploads this high-bandwidth data to a central Electronic Health Record (EHR) system. The first wireless transceiver on the hub transmits continuous, low-latency vital sign streams from multiple patients (e.g., to a central display for nurses). Simultaneously, the second wireless transceiver receives high-resolution diagnostic images (e.g., X-rays, ultrasounds, MRI scans) from imaging equipment located in the ward. The virtual MAC (111) and virtual PHY (112) layers dynamically allocate distinct frequency channels (e.g., medical ISM bands, dedicated Wi-Fi 6E channels) and prioritize data streams to ensure critical patient data transmission is not interrupted by large image file transfers, and vice-versa, all transparently to the medical staff's EMR interface.
    • graph TD
    EHR_SYS[EHR System (Cloud/On-Prem)] --> WND_HUB(Wireless Networking Device - Hub)
    WND_HUB --> VMAC_HUB[VMAC Hub]
    WND_HUB --> VPHY_HUB[VPHY Hub]
    VMAC_HUB -- TX/RX Resource Alloc & Priority --> VPHY_HUB
    VPHY_HUB --> TRCV_TX(TX Transceiver - Vital Signs)
    VPHY_HUB --> TRCV_RX(RX Transceiver - Imaging)
    TRCV_TX -- Wireless Link --> BED_MONITOR_1(Patient Monitor 1)
    TRCV_TX -- Wireless Link --> BED_MONITOR_2(Patient Monitor 2)
    IMAGING_DEV(Imaging Device) -- Wireless Link --> TRCV_RX
    WND_HUB -- Upload Vital Signs --> EHR_SYS
    WND_HUB -- Receive Images --> EHR_SYS

4. Integration with Emerging Tech

  • Derivative 25.4: AI-Managed Spectrum Sharing with Real-Time Blockchain Verification
    • Enabling Description: The virtual MAC (111) is integrated with an AI-driven cognitive radio engine. This AI continuously scans available spectrum (from actual PHY layers via wideband receivers and spectrum analyzers) and, as of April 26, 2026, learns optimal transmit/receive frequency assignments for simultaneous operation. This optimization is based on historical interference patterns, dynamic environmental conditions (via IoT sensors detecting RF noise, weather, etc.), and predicted application traffic demands. The virtual MAC/PHY layers execute the AI's recommendations, dynamically partitioning the available spectrum between the dedicated transmitting transceiver (for the first data stream) and the dedicated receiving transceiver (for the second data stream). To ensure fair and secure spectrum sharing, especially in shared or licensed-shared access (LSA) bands, a blockchain-based ledger records all spectrum allocation decisions, transmit/receive activity, and any detected interference events. This provides an immutable, auditable log for regulatory compliance and dispute resolution in a multi-tenant spectrum environment.
    • graph TD
    APP_TX_REQ[App TX Request] --> PROC_INT(Processing Interface)
    APP_RX_REQ[App RX Request] --> PROC_INT
    PROC_INT --> AI_COG_RADIO(AI Cognitive Radio Engine)
    AI_COG_RADIO -- Spectrum Decision --> VMAC[Virtual MAC (111)]
    AI_COG_RADIO -- Spectrum Decision --> VPHY_TX[Virtual PHY TX]
    AI_COG_RADIO -- Spectrum Decision --> VPHY_RX[Virtual PHY RX]
    IOT_SENS[IoT Sensors (Spectrum Scanners)] --> AI_COG_RADIO
    VPHY_TX --> TRCV_TX(TX Transceiver)
    VPHY_RX --> TRCV_RX(RX Transceiver)
    TRCV_TX -- TX Data Stream (Freq X) --> WIRELESS_CHANNEL((Wireless Channel))
    TRCV_RX -- RX Data Stream (Freq Y) --> WIRELESS_CHANNEL
    TRCV_TX -- Log Activity --> BLOCKCHAIN[Blockchain Spectrum Ledger]
    TRCV_RX -- Log Activity --> BLOCKCHAIN
    REG_COMP[Regulatory Compliance] --> BLOCKCHAIN
    BLOCKCHAIN -- Audit Log --> SPECTRUM_MGMT[Spectrum Management]

5. The "Inverse" or Failure Mode

  • Derivative 25.5: Prioritized Fail-Safe Communication with Single-Channel TDM Fallback
    • Enabling Description: In applications where simultaneous transmit/receive on separate transceivers is crucial (ee.g., remote control of an uncrewed aerial vehicle (UAV) while simultaneously receiving high-definition video feedback), a robust fail-safe mechanism is implemented. If one transceiver fails (e.g., the TX radio fails, preventing command signals) or if extreme interference prevents simultaneous operation, the processing interface (104) detects this through the virtual PHY's continuous monitoring. The system then enters a prioritized fail-safe mode, abandoning strict simultaneous T/R on separate transceivers and falling back to a single, most robust transceiver operating in Time Division Multiplexing (TDM) mode on a pre-designated emergency channel. The virtual MAC (111) and virtual PHY (112) layers reconfigure the remaining functional transceiver to alternate between transmitting critical commands and receiving essential telemetry, heavily prioritizing the critical control signals. Non-essential data streams (like high-resolution video) are either paused, significantly degraded (e.g., to low-resolution stills), or dropped entirely. This ensures mission-critical bi-directional communication, albeit at reduced bandwidth and with increased latency, preventing a complete loss of control or situational awareness.
    • stateDiagram-v2
    [*] --> NORMAL_SIMULTANEOUS_TRX
    NORMAL_SIMULTANEOUS_TRX --> MONITOR_HEALTH: Continuous Monitoring
    MONITOR_HEALTH --> TRCV_FAILURE_DETECTED: TX or RX Trxvr Fails
    TRCV_FAILURE_DETECTED --> FALLBACK_INITIATED: Trigger Fail-Safe Protocol
    FALLBACK_INITIATED --> SINGLE_CHANNEL_TDM: Reconfigure VMAC/VPHY
    SINGLE_CHANNEL_TDM --> PRIORITIZED_COMM: Critical TX/RX Only (TDM)
    PRIORITIZED_COMM --> NOTIFY_APP: Signal Degraded Mode
    SINGLE_CHANNEL_TDM --> REPAIR_COMPLETE: Trxvr Repaired/Recovered
    REPAIR_COMPLETE --> NORMAL_SIMULTANEOUS_TRX
    TRCV_FAILURE_DETECTED --> COMPLETE_COMM_LOSS: Both Trxvr Fail
    COMPLETE_COMM_LOSS --> EMERGENCY_PROTOCOL: System Shutdown/Beacon

    state NORMAL_SIMULTANEOUS_TRX {
        VMAC_SIM: VMAC (Simultaneous TX/RX)
        VPHY_TX_SIM: VPHY (TX Path)
        VPHY_RX_SIM: VPHY (RX Path)
        TRCV_TX_ACTIVE: TX Trxvr (Active)
        TRCV_RX_ACTIVE: RX Trxvr (Active)
    }
    state SINGLE_CHANNEL_TDM {
        VMAC_TDM: VMAC (TDM Control)
        VPHY_TDM: VPHY (TDM Config)
        TRCV_FAILSAFE_ACTIVE: Single Robust Trxvr (Active)
        TRCV_DISABLED: Failed Trxvr (Disabled)
    }

Combination Prior Art Scenarios

These scenarios combine the inventive concepts of US12003976 with existing open-source standards, demonstrating their synergistic application and establishing further prior art as of April 26, 2026.

  1. US12003976 with OpenFlow (SDN Standard)

    • Enabling Description: The wireless networking device (or a collection of such devices, e.g., in an enterprise network) integrates its processing interface (104) and virtual MAC/PHY layers (111, 112) with an external Software-Defined Networking (SDN) controller via the OpenFlow protocol. The SDN controller, with its centralized network-wide visibility, provides global optimization directives for bandwidth allocation, traffic engineering, and dynamic spectrum sharing among multiple wireless networking devices. The virtual MAC's decision block (106) receives these high-level policies (e.g., "prioritize Application A traffic from Zone X with minimum 1 Gbps throughput," or "isolate guest network traffic to specific frequency bands"). The virtual MAC then translates these policies into local allocation of specific frequency portions across its transceivers (118) and uses OpenFlow to configure the underlying data plane elements to enforce these rules. OpenFlow enables programmatic control over the forwarding plane of the network devices, allowing the virtual PHY to translate allocation decisions into concrete flow rules (e.g., setting specific radio parameters for a given flow or associating flows with particular physical resources). This enables a centralized or hierarchical SDN controller to manage distributed virtual MAC/PHY instances for optimized resource utilization across an entire wireless network fabric. The non-prevention clause of Claim 1 is explicitly enforced by OpenFlow rules preventing a high-priority flow from monopolizing all bandwidth, thereby leaving remnants for other devices or lower-priority flows.

  2. US12003976 with Open vSwitch (Open Source Virtual Switch)

    • Enabling Description: The processing layer (104) of the wireless networking device is tightly integrated with an Open vSwitch (OvS) instance operating within the device's host system. The OvS acts as a software-defined switch, handling the internal network traffic within the device before it reaches the actual wireless hardware. The actual MAC interfaces (114) and actual PHY interfaces (116) are exposed as virtual ports on the OvS. The virtual MAC layer (111) functions as a control plane for the OvS, dynamically defining and injecting flow rules into the OvS to direct application data streams through specific wireless transceivers (118) and to allocate bandwidth portions. This provides a flexible, programmable packet processing pipeline above the actual hardware. For example, the virtual MAC dynamically injects OvS flow rules to steer high-priority Application A traffic (requiring bandwidth aggregation) to an aggregated logical channel formed by portions of Transceiver 1 and Transceiver 2 (as per Claim 21), while lower-priority traffic uses remaining bandwidth portions via other OvS ports connected to different physical or virtualized transceivers. This architecture allows for fine-grained, programmatic control over how application data streams are mapped to available wireless resources.

  3. US12003976 with IEEE 802.11 Standards (e.g., Wi-Fi 6/6E/7 with OFDMA/MU-MIMO)

    • Enabling Description: The wireless networking device fully implements the latest IEEE 802.11 standards, specifically IEEE 802.11ax (Wi-Fi 6/6E) and IEEE 802.11be (Wi-Fi 7) as of April 26, 2026, leveraging their Orthogonal Frequency Division Multiple Access (OFDMA) and Multi-User Multiple-Input Multiple-Output (MU-MIMO) capabilities in its actual MAC and PHY layers (114, 116). The processing interface (104) and its virtual MAC/PHY layers (111, 112) operate strategically above these standard 802.11 mechanisms. The virtual MAC analyzes application bandwidth requirements and, instead of directly allocating raw frequency blocks, it intelligently instructs the underlying 802.11 MAC to allocate specific OFDMA Resource Units (RUs) or MU-MIMO spatial streams across its multiple transceivers (operating in different 2.4 GHz, 5 GHz, or 6 GHz bands). For example, to satisfy Application A's high bandwidth requirement, the virtual MAC requests a specific allocation of RUs from Transceiver 1 (e.g., a portion of a 6 GHz channel) and additional RUs and/or MU-MIMO spatial streams from Transceiver 2 (e.g., a portion of a 5 GHz channel), potentially for simultaneous transmission (as per Claim 21) or simultaneous transmit/receive (as per Claim 25). The inherent sharing mechanisms within the 802.11 standards ensure that "utilization of the first available bandwidth portion... does not prevent any wireless networking device from utilizing a range of frequencies corresponding to the remaining portion," as OFDMA allows granular sharing of sub-carriers within a channel, and MU-MIMO enables multiple users to be served concurrently via spatial diversity. The virtual layers intelligently leverage and coordinate these advanced 802.11 features for optimized, multi-radio, multi-band bandwidth management.

Generated 5/19/2026, 12:49:57 AM