Patent 12015933
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.
Defensive Disclosure: US12015933 - Method and Apparatus for Processing Bandwidth Intensive Data Streams Using Virtual Media Access Control and Physical Layers
This document serves as a defensive disclosure, presenting derivative variations of the invention claimed in US patent 12015933. The purpose is to broaden the scope of prior art, rendering potential future incremental improvements by competitors obvious or non-novel. The derivations are based on the core independent claim (Claim 1) of US12015933 and explore various technical axes.
Level of Ordinary Skill in the Art (POSITA)
A Person of Ordinary Skill in the Art (POSITA) in this field, as of the priority date of US12015933 (October 30, 2013), would possess:
- Advanced knowledge of IEEE 802.11 standards and other wireless communication protocols (e.g., LTE, 5G, WiMAX).
- Expertise in network layering models (OSI/TCP-IP), particularly MAC and PHY layer functionalities.
- Proficiency in software-defined radio (SDR) principles, network function virtualization (NFV), and dynamic spectrum management.
- Experience with multi-radio and multi-band wireless system design and implementation.
- A graduate degree (Master's or Ph.D.) in Electrical Engineering, Computer Science, or Telecommunications, coupled with at least 5-7 years of hands-on experience in wireless system development, network architecture, or related research. This individual would also exhibit ordinary creativity and problem-solving capabilities within the domain.
Derivative Variations of Claim 1
1. Material & Component Substitution: Software-Defined Radio (SDR) with Reconfigurable RF Front-Ends
Enabling Description:
Instead of fixed-function wireless transceivers, the wireless networking device utilizes first and second Software-Defined Radio (SDR) units, each equipped with a highly reconfigurable RF front-end (RFFE) based on gallium nitride (GaN) high-electron-mobility transistors (HEMTs) and microelectromechanical systems (MEMS) tunable filters and antennas. The processing interface, implemented on a multi-core ARM SoC (e.g., NXP Layerscape LS1046A), integrates an FPGA for real-time PHY layer processing (e.g., LDPC encoding/decoding, advanced MIMO precoding) and a Linux kernel with virtualized network functions. The virtual MAC interface manages the dynamic reconfiguration of the SDR RFFE parameters (e.g., carrier frequency, bandwidth, modulation scheme, antenna beam patterns) to adapt to identified bandwidth portions in different frequency bands (e.g., sub-GHz ISM, 2.4 GHz, 5 GHz Wi-Fi, 60 GHz WiGig, CBRS spectrum). The feedback mechanism from the virtual PHY instances to the virtual MAC involves real-time spectral sensing data from the SDRs, enabling cognitive radio capabilities for opportunistic spectrum access and interference mitigation, transparently adjusting resource allocation for a recipient's data stream without necessitating disassociation. The GaN HEMTs provide high power efficiency and linearity across wide frequency ranges, while MEMS components enable rapid tuning and miniaturization for integration into compact wireless access points or mobile user equipment.
graph TD
A[Application Interface: First Application APP_A] --> B(Processing Interface: SDR Virtual MAC)
B --> C1(Virtual PHY 1: SDR RFFE Config)
B --> C2(Virtual PHY 2: SDR RFFE Config)
C1 --> D1(Actual MAC 1: SDR Controller)
C2 --> D2(Actual MAC 2: SDR Controller)
D1 --> E1(Actual PHY 1: GaN HEMT & MEMS SDR Transceiver 1)
D2 --> E2(Actual PHY 2: GaN HEMT & MEMS SDR Transceiver 2)
E1 -- Radio Signals (Band 1) --> F[Recipient]
E2 -- Radio Signals (Band 2) --> F
E1 -- Real-time Spectral Sensing --> C1
E2 -- Real-time Spectral Sensing --> C2
C1 -- Bandwidth Availability --> B
C2 -- Bandwidth Availability --> B
subgraph SDR Processing Interface
B
C1
C2
end
2. Material & Component Substitution: Photonic Integrated Circuit (PIC) Transceivers for Terahertz Communication
Enabling Description:
For extreme high-bandwidth requirements, the wireless networking device employs first and second transceivers implemented as Photonic Integrated Circuits (PICs) operating in the Terahertz (THz) frequency range (e.g., 100 GHz to 10 THz). These PIC-based transceivers leverage silicon photonics and graphene modulators for ultra-fast electro-optic conversion and detection. The "different bands of frequencies" refer to distinct sub-THz or THz spectral windows (e.g., 100-200 GHz, 250-350 GHz) allocated by the virtual MAC. The processing interface utilizes specialized digital signal processors (DSPs) with massively parallel architectures, optimized for THz waveform generation and processing. The virtual MAC layers manage the allocation of these THz spectral portions, dynamically tuning PIC components (e.g., resonant cavities, arrayed waveguide gratings) via a control plane. The feedback mechanism includes real-time channel quality indicators (CQI) derived from THz propagation characteristics, allowing the virtual MAC to adapt resource allocation for a recipient (e.g., a data center server or high-fidelity VR headset) to specific THz sub-bands or spatial streams, all transparently to higher application layers. This enables multi-gigabit or even terabit-per-second data rates over short ranges, without disassociating the recipient from the virtualized MAC/PHY layers.
graph TD
A[Application Interface: High-Res VR App] --> B(Processing Interface: THz Virtual MAC)
B --> C1(Virtual PHY 1: PIC THz Config)
B --> C2(Virtual PHY 2: PIC THz Config)
C1 --> D1(Actual MAC 1: THz DSP Controller)
C2 --> D2(Actual MAC 2: THz DSP Controller)
D1 --> E1(Actual PHY 1: PIC THz Transceiver 1)
D2 --> E2(Actual PHY 2: PIC THz Transceiver 2)
E1 -- THz Signals (Band 1) --> F[Recipient]
E2 -- THz Signals (Band 2) --> F
E1 -- Real-time CQI --> C1
E2 -- Real-time CQI --> C2
C1 -- Bandwidth Availability --> B
C2 -- Bandwidth Availability --> B
subgraph THz PIC System
B
C1
C2
end
3. Operational Parameter Expansion: Ultra-Dense Industrial IoT Network with Nanoscale Transceivers
Enabling Description:
The wireless networking device is deployed in an ultra-dense industrial IoT (IIoT) environment, comprising tens of thousands of distributed sensors and actuators (recipients) within a confined space (e.g., a smart factory floor). The "wireless transceivers" are integrated nanoscale transceivers (e.g., utilizing plasmonic antennas or resonant tunneling diodes) operating in sub-THz (e.g., 200-300 GHz) and mmWave (e.g., 60 GHz) bands, enabling very short-range, high-density communication. The processing interface, resident on a robust industrial edge gateway, manages a vast pool of these virtualized nanoscale MAC/PHY layers. Each virtual PHY corresponds to a physical cluster of nanoscale transceivers, feeding highly granular availability data (e.g., channel occupancy, interference levels, power consumption) back to the virtual MAC. The virtual MAC dynamically allocates sub-MHz or MHz portions of spectrum from the mmWave and sub-THz bands to individual IIoT devices based on real-time data bursts (e.g., critical sensor readings, control commands), maintaining associations across multiple nanoscale links transparently. This system is designed to handle extreme message rates (millions of transactions per second) with ultra-low latency, ensuring simultaneous operations of many devices without performance degradation or disassociation, leveraging spatial multiplexing and frequency hopping across the dense deployment.
graph TD
A[Application Interface: IIoT Data Aggregation] --> B(Processing Interface: Virtual MAC for Nanoscale Transceivers)
B --> C1(Virtual PHY 1: Cluster A Nano-Tx/Rx Config)
B --> C2(Virtual PHY 2: Cluster B Nano-Tx/Rx Config)
C1 --> D1(Actual MAC 1: Nano-Tx/Rx Controller A)
C2 --> D2(Actual MAC 2: Nano-Tx/Rx Controller B)
D1 --> E1(Actual PHY 1: Nanoscale Transceiver Array A)
D2 --> E2(Actual PHY 2: Nanoscale Transceiver Array B)
E1 -- MmWave/Sub-THz Signals --> F[Recipient: IIoT Sensor Network]
E2 -- MmWave/Sub-THz Signals --> F
E1 -- Granular Avail. Data --> C1
E2 -- Granular Avail. Data --> C2
C1 -- Bandwidth Availability --> B
C2 -- Bandwidth Availability --> B
subgraph IIoT Edge Gateway
B
C1
C2
end
4. Operational Parameter Expansion: Deep-Space Communication with Adaptive Optical and RF Links
Enabling Description:
The wireless networking device is a deep-space probe or satellite, communicating with a terrestrial ground station (recipient). The first wireless transceiver operates as a Free-Space Optical (FSO) communication module using coherent laser links (e.g., 1550 nm), while the second is a Ka-band (26-40 GHz) RF transceiver. Due to extreme distances, atmospheric conditions, and orbital mechanics, link characteristics are highly dynamic. The processing interface dynamically manages the FSO and RF links as "first and second different bands of frequencies," considering the FSO link for extremely high data rates during clear atmospheric windows and the RF link for robust, all-weather baseline communication. The virtual MAC layer incorporates predictive algorithms based on orbital trajectory data, atmospheric models, and solar activity to anticipate link quality changes. It allocates "portions of bandwidth" by dynamically adjusting laser power, beam steering, coding schemes for FSO, and modulation, coding, and spatial streams for Ka-band RF. The feedback loop from the virtual PHYs (representing FSO and Ka-band PHYs) provides real-time signal-to-noise ratio (SNR), pointing error, and atmospheric attenuation metrics. This enables transparent switching or bonding of FSO and RF resources to maintain high-bandwidth data streams (e.g., scientific telemetry, high-resolution imagery) to the ground station, without disassociating the recipient, even when one link degrades.
sequenceDiagram
participant P as Deep-Space Probe (Device)
participant G as Ground Station (Recipient)
P->>P: Application Interface (Telemetry, Imagery)
P->>P: Processing Interface (Virtual MAC)
P->>P: Virtual MAC requests association with G via FSO & RF actual MAC/PHYs
P->>G: Establish FSO Link (Band 1)
P->>G: Establish Ka-band RF Link (Band 2)
loop Data Stream Transfer
P->>P: Virtual PHYs feed FSO/RF Link Quality (SNR, Attenuation) to Virtual MAC
P->>P: Virtual MAC evaluates bandwidths, identifies portions (FSO/RF)
alt FSO Link Strong
P->>G: Transmit data via FSO (subset of FSO frequencies)
else RF Link Strong / FSO weak
P->>G: Transmit data via Ka-band RF (subset of RF frequencies)
end
P->>P: Transparent allocation, no disassociation
end
5. Cross-Domain Application: Predictive Maintenance for Offshore Wind Farms
Enabling Description:
The wireless networking device is an advanced sensor gateway on an offshore wind turbine, and the recipient is a central control facility or maintenance vessel. The "applications" are real-time condition monitoring (e.g., vibration analysis, blade integrity scans, gearbox temperature) requiring high-bandwidth data streams. The first wireless transceiver utilizes a sub-6 GHz industrial Wi-Fi link (e.g., IEEE 802.11ah for long range), while the second employs a directional mmWave link (e.g., 60 GHz) for high-capacity bursts when a maintenance vessel is in close proximity. The processing interface, hardened for harsh marine environments, runs a virtual MAC that dynamically prioritizes and aggregates bandwidth from these two transceivers. For example, continuous telemetry uses the stable Wi-Fi link, but when a high-resolution 3D scan of a blade is required (e.g., triggered by AI anomaly detection), the virtual MAC transparently activates and allocates a significant portion of the mmWave bandwidth to quickly offload the large data file to the nearby vessel (recipient) without disrupting ongoing Wi-Fi telemetry to the central facility. The "evaluation of unavailability" includes factors like weather conditions (rain fade for mmWave), vessel distance, and available power, dynamically managed by the virtual MAC to optimize data transfer for predictive maintenance tasks.
flowchart TD
A[Wind Turbine Sensor Data (Vibration, Temp, Scan)] --> B(Application Interface)
B --> C(Processing Interface: Virtual MAC)
C --> D1(Virtual PHY: Sub-6GHz Wi-Fi Config)
C --> D2(Virtual PHY: MmWave Directional Link Config)
D1 --> E1(Actual MAC 1)
D2 --> E2(Actual MAC 2)
E1 --> F1(Actual PHY 1: Sub-6GHz Wi-Fi Transceiver)
E2 --> F2(Actual PHY 2: MmWave Transceiver)
F1 -- Stable Telemetry --> G[Recipient: Central Control Facility]
F2 -- High-Res Scan Data --> H[Recipient: Maintenance Vessel]
subgraph Wind Turbine Gateway
C
D1
D2
E1
E2
F1
F2
end
F1 -- Avail. Feedback --> D1
F2 -- Avail. Feedback --> D2
D1 -- Bandwidth Status --> C
D2 -- Bandwidth Status --> C
style H fill:#f9f,stroke:#333,stroke-width:2px
6. Cross-Domain Application: Real-time Remote Surgery via Haptic Feedback Network
Enabling Description:
The wireless networking device is a surgical robot controller in an operating room, and the recipient is a remote surgeon's console. The "application" is real-time tele-surgery, demanding ultra-low latency, high-bandwidth video (4K/8K 3D), and precise haptic feedback data streams. The first transceiver is a dedicated 60 GHz WiGig (IEEE 802.11ad/ay) link for local, low-latency communication with surgical instruments, while the second is a secure 5G NR (mmWave) link to the remote surgeon. The processing interface, equipped with a specialized real-time operating system (RTOS) and deterministic networking capabilities, creates virtual MAC and PHY layers that prioritize and guarantee quality of service (QoS) for distinct data streams. The virtual MAC continuously monitors latency, jitter, and bandwidth availability across both links. For instance, haptic feedback, being extremely latency-sensitive, is allocated dedicated sub-portions of the 5G NR link, while high-resolution video streams are dynamically managed across remaining available 5G and WiGig bandwidth. The system dynamically switches video quality or dynamically allocates redundancy based on real-time link performance, transparently to the surgeon, ensuring uninterrupted and safe remote operation without disassociating the remote console from the virtualized communication pathways.
graph TD
A[Application Interface: Surgical Robot Control] --> B(Processing Interface: RTOS Virtual MAC)
B --> C1(Virtual PHY 1: WiGig Config)
B --> C2(Virtual PHY 2: 5G NR mmWave Config)
C1 --> D1(Actual MAC 1)
C2 --> D2(Actual MAC 2)
D1 --> E1(Actual PHY 1: WiGig Transceiver)
D2 --> E2(Actual PHY 2: 5G NR Transceiver)
E1 -- Instrument Control/Video --> F[Recipient: Remote Surgeon Console]
E2 -- Haptic/Video/Control --> F
E1 -- Latency/Bandwidth Feedback --> C1
E2 -- Latency/Bandwidth Feedback --> C2
C1 -- QoS Metrics --> B
C2 -- QoS Metrics --> B
subgraph Surgical Robot Controller
B
C1
C2
end
7. Integration with Emerging Tech: AI-Driven Multi-Tenant Spectrum Slicing with IoT Observability
Enabling Description:
The wireless networking device operates in a smart city infrastructure, serving multiple independent tenants (e.g., public safety, traffic management, autonomous vehicles). The "first and second wireless transceivers" represent generalized radio resource pools configurable across licensed (e.g., 5G CBRS) and unlicensed (e.g., Wi-Fi 6E) spectrum. The processing interface incorporates an AI/ML inference engine (e.g., a neural network trained for dynamic spectrum access and resource prediction) and an IoT sensor observability platform for real-time environmental awareness (e.g., localized interference, crowd density, traffic flow). The virtual MAC acts as an AI-driven orchestrator, implementing dynamic spectrum slicing and allocating specific bandwidth "portions" (frequency, time, spatial streams) to virtual network slices for each tenant's application. The IoT observability platform feeds environmental data directly into the AI inference engine. For example, if a public safety application (first application) requires high bandwidth due to an emergency, the AI-driven virtual MAC transparently reallocates spectrum from lower-priority slices (e.g., smart lighting, non-critical traffic sensors) to the public safety slice, using unoccupied or lightly used frequencies from the available transceiver resources. This reallocation happens without disassociating existing users within their respective slices, demonstrating simultaneous utilization of remaining bandwidth by other "wireless networking device devices" (other tenants/slices).
graph TD
A[Application Interface: Multi-Tenant Apps (Public Safety, Traffic)] --> B(Processing Interface: AI Virtual MAC)
B -- AI-driven Orchestration --> C1(Virtual PHY 1: Spectrum Slice 1 Config)
B -- AI-driven Orchestration --> C2(Virtual PHY 2: Spectrum Slice 2 Config)
C1 --> D1(Actual MAC 1: Radio Pool 1 Controller)
C2 --> D2(Actual MAC 2: Radio Pool 2 Controller)
D1 --> E1(Actual PHY 1: Configurable SDR Radio 1)
D2 --> E2(Actual PHY 2: Configurable SDR Radio 2)
E1 -- Wireless Link (Licensed/Unlicensed) --> F[Recipient(s): Public Safety Devices, Traffic Sensors]
E2 -- Wireless Link (Licensed/Unlicensed) --> G[Recipient(s): Autonomous Vehicles, Smart Lighting]
O[IoT Sensor Platform (Environmental Data)] --> B
E1 -- Real-time Observability --> C1
E2 -- Real-time Observability --> C2
C1 -- Slice Performance Metrics --> B
C2 -- Slice Performance Metrics --> B
subgraph Smart City Edge Node
B
C1
C2
end
8. Integration with Emerging Tech: Blockchain-Secured Bandwidth Market for Dynamic Resource Allocation
Enabling Description:
The wireless networking device (e.g., a federated access point or base station) participates in a blockchain-secured dynamic bandwidth market, where bandwidth "portions" are tokenized resources. The "recipient" could be another access point, a mobile device, or an IoT gateway. The processing interface includes a blockchain client (e.g., Ethereum smart contract interface) alongside the virtual MAC. Bandwidth availability is recorded on a distributed ledger. When a first application (e.g., high-definition media streaming) requires bandwidth, the virtual MAC queries the blockchain for available tokenized bandwidth portions from the first and second wireless transceivers (e.g., 5 GHz Wi-Fi and 6 GHz Wi-Fi 6E). If the local transceivers cannot fully satisfy the demand, the virtual MAC, through its processing logic, transparently initiates a micro-transaction on the blockchain to acquire additional bandwidth tokens from adjacent federated access points that have surplus capacity. The "evaluation of unavailability" includes not just physical radio conditions but also the economic availability of tokenized bandwidth on the ledger. This allows for fine-grained, auditable, and transparent allocation of spectrum resources, where a recipient effectively "leases" bandwidth portions via smart contracts, without requiring disassociation from the underlying physical MAC/PHY layers, and ensuring that remaining bandwidth can be similarly traded or utilized.
flowchart LR
A[Application Interface] --> B(Processing Interface: Virtual MAC + Blockchain Client)
B -- Request Bandwidth (Tokenized) --> C{Blockchain Network: Smart Contract}
C --> B
B --> D1(Virtual PHY 1: Token-based Config)
B --> D2(Virtual PHY 2: Token-based Config)
D1 --> E1(Actual MAC 1)
D2 --> E2(Actual MAC 2)
E1 --> F1(Actual PHY 1: 5GHz Transceiver)
E2 --> F2(Actual PHY 2: 6GHz Transceiver)
F1 -- Data Stream --> G[Recipient (e.g., Mobile Device)]
F2 -- Data Stream --> G
F1 -- Avail. Data --> D1
F2 -- Avail. Data --> D2
D1 -- Bandwidth Status --> B
D2 -- Bandwidth Status --> B
subgraph Federated Access Point
B
D1
D2
end
9. The "Inverse" or Failure Mode: Graceful Degradation for Critical Infrastructure Monitoring
Enabling Description:
The wireless networking device is a resilient communication hub for critical infrastructure monitoring (e.g., pipeline integrity, bridge structural health), where failure to transmit data can have severe consequences. The "first and second wireless transceivers" are robust, redundant SATCOM (Satellite Communication) and HF (High Frequency) radio links. In normal operation, high-bandwidth sensor data is transmitted via SATCOM. However, the system is designed to seamlessly transition to a "limited-functionality" or "graceful degradation" mode upon detection of SATCOM link degradation (e.g., jamming, adverse weather, satellite outage). The processing interface's virtual MAC continuously monitors link health and, upon detecting failure conditions, transparently switches to the lower-bandwidth, but more robust, HF link for the "first data stream" (e.g., essential system alarms, command & control messages). This involves identifying a minimal "portion" of the HF bandwidth that is always reserved and available, even under severe interference. The virtual PHY for the HF link employs advanced digital modulation (e.g., ALE-enabled OFDM) to maximize data throughput within the constrained HF spectrum. The recipient (e.g., emergency operations center) remains associated, but receives a pre-defined "low-power" or "emergency-mode" data stream (e.g., text-only alerts, compressed sensor readings), without requiring disassociation from the overall monitoring system, ensuring continuity of critical information flow despite severe communication challenges. This mode also prioritizes minimal power consumption using dynamic power scaling of the HF transceiver.
stateDiagram
[*] --> NormalOperation: System Startup
NormalOperation --> SatcomLinkMonitor: Monitor SATCOM Link Health
SatcomLinkMonitor --> NormalOperation: SATCOM Link Healthy
SatcomLinkMonitor --> DegradationDetected: SATCOM Link Degraded
DegradationDetected --> GracefulDegradationMode: Transition to HF Link
GracefulDegradationMode --> HFLinkMonitor: Monitor HF Link
HFLinkMonitor --> GracefulDegradationMode: HF Link Stable (Limited Functionality)
GracefulDegradationMode --> FullRecovery: SATCOM Restored
FullRecovery --> NormalOperation: Resume Normal Operations
state NormalOperation {
HighBandwidthData: SATCOM Link Active
VirtualMAC_SATCOM: Allocates full SATCOM BW
}
state GracefulDegradationMode {
LowBandwidthData: HF Link Active (Essential Only)
VirtualMAC_HF: Allocates reserved HF BW
PowerManagement: Reduce Transceiver Power
}
state DegradationDetected {
DecisionBlock: Detect SATCOM Loss
UltraStreamingBlock: Prepare HF Data Stream
}
state FullRecovery {
DecisionBlock: Detect SATCOM Recovery
UltraStreamingBlock: Revert to SATCOM Data Stream
}
Combination Prior Art Scenarios
Here are three combination prior art scenarios where US patent 12015933, or its derived concepts, could be combined with existing open-source standards to demonstrate obviousness.
US12015933 + OpenWrt (Open-Source Router Firmware):
- Description: The concepts of virtual MAC and virtual PHY layers for dynamic bandwidth allocation across multiple transceivers, as described in US12015933, are integrated into an OpenWrt-based wireless networking device (e.g., a consumer-grade Wi-Fi router). OpenWrt provides an open-source framework for managing network interfaces, routing, and access points. A POSITA would find it obvious to implement the processing interface (decision block, processing block, ultra-streaming block) and the virtual MAC/PHY layers as kernel modules or user-space daemons within the OpenWrt environment. The OpenWrt abstraction of network devices (e.g.,
iwcommands,mac80211stack) naturally supports the "transparent" management of underlying hardware. The goal of improving bandwidth utilization for applications (e.g., streaming video) by aggregating Wi-Fi bands (2.4 GHz and 5 GHz, or even 6 GHz for Wi-Fi 6E) through a virtualized layer would be an obvious extension to existing multi-band router functionalities in OpenWrt, allowing dynamic sub-channel allocation without breaking client associations. OpenWrt's flexibility in managing network interfaces and itshostapdfor access point control provides the necessary hooks for such virtualized resource management. - Claim Mapping: Directly combines with the "processing interface," "application interface," "actual MAC and PHY interfaces," "virtual MAC layer," "virtual PHY layer," "bandwidth allocator," and "transparent" operation of Claim 1, demonstrating implementation within an widely accessible, extensible platform.
- Description: The concepts of virtual MAC and virtual PHY layers for dynamic bandwidth allocation across multiple transceivers, as described in US12015933, are integrated into an OpenWrt-based wireless networking device (e.g., a consumer-grade Wi-Fi router). OpenWrt provides an open-source framework for managing network interfaces, routing, and access points. A POSITA would find it obvious to implement the processing interface (decision block, processing block, ultra-streaming block) and the virtual MAC/PHY layers as kernel modules or user-space daemons within the OpenWrt environment. The OpenWrt abstraction of network devices (e.g.,
US12015933 + OpenFlow/SDN (Software-Defined Networking):
- Description: The principles of US12015933 are applied to a wireless network managed by an OpenFlow-compliant Software-Defined Networking (SDN) controller. In this scenario, the "wireless networking device" becomes an OpenFlow-enabled wireless access point, and the "processing interface" functions as a local SDN agent that communicates with a centralized OpenFlow controller. The virtual MAC and virtual PHY layers of US12015933 would be implemented as network function virtualization (NFV) components orchestrated by the SDN controller. The controller, using OpenFlow rules, would dynamically program the actual MAC and PHY layers of multiple transceivers (e.g., distinct radio cards in an AP operating on different channels/bands). The "feedback" mechanism would leverage OpenFlow statistics and port status messages from the wireless AP to the controller, allowing the SDN logic to "evaluate" bandwidth availability and "allocate" portions of spectrum resources (via flow rules) to meet specific application bandwidth requirements of a "recipient" (e.g., a user device, VM, or container). This provides a network-wide, rather than device-local, virtualization of MAC/PHY resources, making the dynamic, transparent allocation across diverse physical radios an obvious extension of SDN principles for wireless networks.
- Claim Mapping: Maps to the "processing interface," "actual MAC and PHY interfaces," "virtual MAC layer," "virtual PHY layer," "bandwidth allocator," and the "transparent" nature of resource management in Claim 1, but extends it to a distributed, software-defined control plane.
US12015933 + IEEE 802.11be (Wi-Fi 7) Multi-Link Operation (MLO):
- Description: The core concept of US12015933, particularly the dynamic allocation of bandwidth portions from multiple wireless transceivers in different frequency bands, becomes obvious when considering the Multi-Link Operation (MLO) feature introduced in the IEEE 802.11be (Wi-Fi 7) standard. MLO inherently allows a single device (recipient) to simultaneously transmit and receive data across multiple frequency bands (e.g., 2.4 GHz, 5 GHz, and 6 GHz) or multiple channels within the same band. A POSITA familiar with 802.11be MLO would find it obvious to implement a "processing interface" and "virtual MAC/PHY layers" to optimally manage these multiple physical links. The virtual MAC would serve as an MLO controller, dynamically identifying and allocating specific "portions" (e.g., individual Resource Units (RUs), spatial streams, or entire channels) of the available bandwidth from each physical transceiver (actual PHY/MAC) to satisfy an application's bandwidth requirements. The "evaluation of unavailability" and "using a subset of frequencies" are precisely what MLO aims to achieve for improved aggregation and resilience, transparently to higher layers. This combination demonstrates that the high-level functional elements of Claim 1 are anticipated or rendered obvious by the design goals and architectural features of advanced Wi-Fi standards.
- Claim Mapping: Directly addresses the "first and second wireless transceivers... in first and second different bands of frequencies," "request or create (i) a first association... and (ii) a second association," "identify at least one first portion of the first actual bandwidth," "evaluate whether any... are unavailable," and "use the first wireless transceiver to transmit... without requiring disassociation... using a subset of frequencies..." elements of Claim 1, showing MLO as a concrete implementation.
Generated 5/19/2026, 6:46:36 AM