Derivative works — US Patent 6430408

DEFENSIVE DISCLOSURE AND PRIOR ART FOR DERIVATIVES OF MARKET-BASED RESOURCE ALLOCATION

Publication Date: May 9, 2026
Reference Patent: U.S. Patent 6430408 B1 ("the '408 patent")
Purpose: This document discloses a series of technical variations, extensions, and applications derived from the core concepts described in the '408 patent. The intent is to place these concepts in the public domain, thereby establishing them as prior art to preclude patenting of obvious, incremental improvements by third parties.

Part 1: Derivatives of Core Concept - Market-Based Service Allocation (per Claims 1, 2, 4)

The '408 patent teaches a system for allocating enhanced services via auctions or dynamic pricing. The following are derivative implementations.

1.1. Component Substitution: Reputation-Based Vickrey Auction

Enabling Description: A method for allocating network resources where the bid currency is a composite "reputation score" rather than a monetary unit. The reputation score is calculated by a base station controller (BSC) as a weighted function of the mobile unit's historical network behavior, such as payment history (if any), signal quality, and adherence to network policies (e.g., not causing interference). The auction is conducted as a second-price sealed-bid (Vickrey) auction. Each mobile unit submits a sealed bid (a percentage of its reputation score it's willing to "spend"). The highest bidder wins but pays the price of the second-highest bid. This encourages truthful bidding and prioritizes well-behaved nodes without requiring real-time financial transactions. The BSC updates reputation scores post-auction; the winner's score is debited by the price paid, and all participants receive a minor score adjustment for participation.

Mermaid Diagram:

sequenceDiagram
    participant MU1 as Mobile Unit 1 (Score: 95)
    participant MU2 as Mobile Unit 2 (Score: 80)
    participant BSC as Base Station Controller
    BSC->>+MU1: Announce Service Auction
    BSC->>+MU2: Announce Service Auction
    MU1->>-BSC: Submit Sealed Bid (Reputation: 50)
    MU2->>-BSC: Submit Sealed Bid (Reputation: 45)
    BSC->>BSC: Compare Bids: MU1 (50) > MU2 (45)
    BSC->>BSC: Determine Price = 2nd Highest Bid (45)
    BSC->>+MU1: Award Service (Cost: 45)
    BSC->>BSC: Update MU1 Score: 95 - 45 = 50
    BSC->>BSC: Update MU2 Score: 80 + 1 (participation) = 81
    BSC->>-MU2: Notify Auction Result

1.2. Operational Parameter Expansion: Micro-Resource Bidding in Massive MIMO for Terahertz (THz) Bands

Enabling Description: In a Massive MIMO system operating in the 0.1-10 THz band, the base station manages thousands of individual beamlets. This system implements a real-time auction for "micro-resources," defined as a single beamlet for a duration of nanoseconds. This is applicable to ultra-high-density environments like holographic telepresence conferences or neural-implant communication networks. A specialized co-processor at the base station runs a continuous double auction, where millions of devices (UEs) continuously post buy (bid) and sell (ask) orders for these micro-resource blocks. The co-processor matches orders in real-time, allowing for hyper-granular and efficient allocation of the massive available bandwidth.

Mermaid Diagram:

graph TD
    subgraph Base Station (THz Band)
        A[MIMO Processor]
        B[Auction Co-Processor]
        C[Beamforming Array]
        A -- Manages -- C
        A -- Offloads Auction to -- B
    end

    subgraph UEs (User Equipment)
        UE1(UE 1 - Neural Implant)
        UE2(UE 2 - Holographic Display)
        UE3(UE 3 - Haptic Suit)
    end

    B <-->|Bid/Ask for ns-Beamlets| UE1
    B <-->|Bid/Ask for ns-Beamlets| UE2
    B <-->|Bid/Ask for ns-Beamlets| UE3

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

1.3. Cross-Domain Application: Dynamic Resource Auction for EV Charging Grid

Enabling Description: An Electric Vehicle (EV) charging station network applies the bidding mechanism to allocate charging capacity. Each EV, via its onboard telematics unit, acts as a "mobile unit." The charging station operator (equivalent to the base station) broadcasts available charging slots and power levels (e.g., 50kW, 150kW, 350kW) and associated starting prices. EVs automatically bid based on user-set parameters (e.g., "must be 80% charged by 8 AM," "minimize cost"). The system runs an auction every 5 minutes. An EV with an urgent need can bid high to secure a high-power slot immediately, while an EV that can wait will place low bids for off-peak slots. This smooths grid load and provides price feedback to consumers.

Mermaid Diagram:

flowchart LR
    CSN[Charging Station Network] -- "Announce Slots & Prices" --> G(Grid of EVs)
    subgraph Grid of EVs
        EV1[EV 1 - Urgent]
        EV2[EV 2 - Flexible]
        EV3[EV 3 - Low Battery]
    end
    EV1 -- "High Bid for 350kW Slot" --> CSN
    EV2 -- "Low Bid for 50kW Slot" --> CSN
    EV3 -- "Medium Bid for 150kW Slot" --> CSN
    CSN -- "Allocate Slots based on Bids" --> EV1
    CSN -- "Allocate Slots based on Bids" --> EV2
    CSN -- "Allocate Slots based on Bids" --> EV3

1.4. Integration with Emerging Tech: AI-Driven Predictive Bidding Agent

Enabling Description: Each mobile unit is equipped with an onboard AI agent, implemented as a lightweight reinforcement learning (RL) model. The agent's function is to manage the device's bidding strategy for enhanced services. Its state space includes the device's current application needs (e.g., streaming 4K video vs. background email sync), battery level, available funds/tokens, and current network price. The action space is the bid amount. The RL agent is trained to maximize a reward function that balances performance (QoS) against cost (price paid and battery consumption). It learns from historical network price data and the outcomes of its past bids to predict price fluctuations and place bids pre-emptively, just before anticipated network congestion, securing resources more cheaply.

Mermaid Diagram:

stateDiagram-v2
    [*] --> Idle
    Idle --> Analyzing: App starts (e.g., 4K Video)
    Analyzing --> Bidding: High QoS needed & low predicted price
    Analyzing --> Idle: Low QoS needs
    Bidding --> Active: Bid Accepted
    Bidding --> Analyzing: Bid Rejected
    Active --> Idle: App closes
    Active --> Bidding: Bidding for next time slot
    state Bidding {
        direction LR
        [*] -> PlacingBid
        PlacingBid -> Waiting
        Waiting -> Won: Bid Accepted
        Waiting -> Lost: Bid Rejected
        Won -> [*]
        Lost -> [*]
    }

1.5. Inverse/Failure Mode: Graceful Degradation with Emergency Override

Enabling Description: A system designed to fail safely when a mobile unit can no longer participate in the service auction (e.g., zero account balance, authentication failure). Instead of terminating the connection, the Base Station Controller re-assigns the unit to a "Best-Effort Fallback Tier." This tier offers no QoS guarantees but provides a minimum data rate (e.g., 64 kbps) sufficient for critical low-bandwidth communication. Furthermore, if the mobile unit's transceiver sends a standardized Emergency Service Request (ESR) packet—regardless of its bidding status—the system immediately allocates the highest-priority enhanced service (e.g., dedicated high-S/N channel) for the duration of the emergency session, pre-empting any non-emergency auctioned services.

Mermaid Diagram:

graph TD
    A[Mobile Unit Active] -- "Auction Participation" --> B{Bid Successful?}
    B -- Yes --> C[Receive Enhanced Service]
    B -- No --> D[Receive Standard Service]
    A -- "Funds Depleted / Auth Error" --> E[Enter Fallback Tier: 64kbps Best-Effort]
    C -- "Session Ends" --> A
    D -- "Session Ends" --> A
    E -- "Funds Restored" --> A
    subgraph Emergency Override
        F[Mobile Unit Sends ESR Packet] --> G{ESR Received?}
        G -- Yes --> H[Pre-empt & Allocate Priority Channel]
    end
    A --> F
    C --> F
    D --> F
    E --> F

Part 2: Derivatives of Core Concept - Peer-to-Peer Service Trading (per Claim 10)

The '408 patent teaches peer-to-peer negotiation for services. The following are derivative implementations.

2.1. Component Substitution: Network Slice Trading via Distributed Ledger

Enabling Description: This system enables mobile units to trade 5G Network Slices. A network slice is a complete, isolated, end-to-end virtual network with specific QoS parameters (latency, bandwidth, reliability). Ownership of a slice for a given time duration is represented by a token on a private, permissioned distributed ledger (blockchain) managed by the network operator. A mobile unit (MU1) that has been allocated a high-performance, low-latency slice but is temporarily idle can offer its slice token for sale on a decentralized marketplace. Another unit (MU2) needing immediate low-latency performance can purchase the token directly from MU1. The network's slice management function monitors the ledger and re-allocates the physical resources corresponding to the slice from MU1 to MU2 upon token transfer.

Mermaid Diagram:

sequenceDiagram
    participant MU1 as Mobile Unit 1 (owns Slice Token)
    participant MU2 as Mobile Unit 2
    participant Marketplace as P2P Slice Marketplace (DApp)
    participant DLT as Distributed Ledger (Blockchain)
    participant SMF as Slice Management Function

    MU1->>+Marketplace: List Slice Token for Sale
    Marketplace-->>-MU1: Token Listed
    MU2->>+Marketplace: Discover and Purchase Token
    Marketplace->>DLT: Initiate Token Transfer(From: MU1, To: MU2)
    DLT->>DLT: Validate & Record Transaction
    DLT-->>SMF: Event: Token Ownership Changed
    SMF->>SMF: Re-provision Physical Resources
    SMF-->>MU1: De-allocate Slice Resources
    SMF-->>MU2: Allocate Slice Resources

2.2. Cross-Domain Application: P2P Sensor Data Trading in Autonomous Vehicles

Enabling Description: In a Vehicle-to-Everything (V2X) network, autonomous vehicles trade sensor data streams in a peer-to-peer market. A vehicle (Car A) approaching a blind intersection can broadcast a request for a real-time LiDAR point cloud or video feed from that intersection. Another vehicle (Car B) or a roadside unit (RSU) with a clear line of sight can respond with an offer to sell that data stream for a micro-payment. The negotiation and payment are handled directly between the vehicles' communication modules. The network (e.g., 5G Sidelink) provides the underlying transport but does not broker the deal. This creates a decentralized market for situational awareness, increasing safety.

Mermaid Diagram:

flowchart TD
    subgraph Car_A [Car A - Approaching Blind Intersection]
        A1[V2X Module]
        A2[Onboard AI]
        A2 -- "Need visual data" --> A1
    end
    subgraph Car_B [Car B - At Intersection]
        B1[V2X Module]
        B2[Forward-Facing Camera]
        B1 -- "Controls" --> B2
    end

    A1 -- "Broadcast Request: 'Video feed of intersection X'" --> B1
    B1 -- "Respond: 'Offer feed for 0.05 tokens'" --> A1
    A1 -- "Accept & Send Micropayment" --> B1
    B1 -- "Stream Encrypted Video" --> A1
    A1 -- "Feed to AI" --> A2

2.3. Integration with Emerging Tech: NFT-Based Spectrum Leasing

Enabling Description: This system uses Non-Fungible Tokens (NFTs) to represent temporary leases of licensed radio spectrum. A primary spectrum license holder (e.g., a mobile network operator) can divide its underutilized spectrum into spatio-temporal blocks (e.g., 10 MHz in a specific city block for 1 hour) and mint an NFT for each block on a public blockchain. These NFTs can be sold in a primary auction. The winning bidders (e.g., a private enterprise, an IoT network provider) can then use the spectrum or resell the NFT on a secondary marketplace like OpenSea. The NFT's metadata contains the technical parameters of the spectrum lease (frequency, location, time, power limits), and the associated smart contract automates royalty payments to the primary holder on secondary sales. Base stations in the area are configured to authorize transmissions from any device that can cryptographically prove ownership of the valid NFT for that time and location.

Mermaid Diagram:

erDiagram
    SPECTRUM_HOLDER ||--o{ NFT_MINT : "mints"
    NFT_MINT {
        string tokenID
        string frequency
        string location
        datetime startTime
        datetime endTime
    }
    SPECTRUM_HOLDER {
        string holderID
        string licenseInfo
    }
    BUYER ||--|{ NFT_MINT : "buys/sells"
    BUYER {
        string walletAddress
    }
    BASE_STATION ||--|{ NFT_MINT : "validates"
    BASE_STATION {
        string stationID
        string location
    }
    MOBILE_UNIT ||--|{ BUYER : "owned by"
    MOBILE_UNIT {
        string deviceID
        string walletAddress
    }

Part 3: Combination Prior Art Scenarios with Open Standards

3.1. Combination with MQTT for Prioritized IoT Bidding

Enabling Description: The bidding system of the '408 patent is integrated into the MQTT (Message Queuing Telemetry Transport) protocol framework. IoT devices are pre-configured with a bidding policy. When an IoT device needs to publish a message, it sets the MQTT QoS level. A message with QoS 0 (at most once) is sent over the standard, non-guaranteed channel. However, publishing a message with QoS 1 (at least once) or QoS 2 (exactly once) automatically triggers the device's network module to place a bid for an enhanced service (e.g., a channel with lower packet loss or higher power allocation) for the duration of that message's transmission and acknowledgment. The bid amount can be a fixed value per QoS level or dynamically determined by an onboard agent. This links application-level delivery requirements directly to physical-layer resource allocation in a standardized way.

3.2. Combination with WebRTC for P2P Quality Negotiation

Enabling Description: The peer-to-peer trading mechanism of Claim 10 is implemented over the WebRTC (Web Real-Time Communication) standard. During a peer-to-peer video call, the WebRTC statistics API in each browser monitors connection quality (e.g., packet loss, RTT, jitter). If one user's (User A) uplink becomes congested, their browser can signal to the other user's (User B) browser, via the WebRTC data channel, a request to purchase a higher-quality connection. User B, who may currently have a high-quality connection but doesn't require it (e.g., is only listening), can agree. The agreement triggers a message from User B's device to the base station to release its "enhanced service" in favor of User A. The base station reallocates the resource, and the payment is handled via a third-party API (e.g., micropayment service) linked to the web application.

3.3. Combination with IEEE 802.11ah (Wi-Fi HaLow) for Group-Based Bidding

Enabling Description: The auction mechanism is applied to the Restricted Access Window (RAW) feature of the IEEE 802.11ah standard, designed for long-range, low-power IoT. An access point (AP) announces upcoming RAW slots available for contention-free access. Instead of random backoff, the AP also announces a "floor price" for each slot. IoT devices, organized into groups, aggregate their needs. A group leader (e.g., a slightly more powerful gateway device) places a single bid on behalf of its entire group. If the bid is won, all devices in that group are permitted to transmit during that RAW slot. This reduces the protocol overhead of having thousands of individual devices bid and allows for market-based prioritization between different classes of sensors (e.g., a "high-priority security sensor" group could outbid a "low-priority environmental monitoring" group).