Derivative works

Defensive Disclosure and Prior Art Derivations for U.S. Patent 8,725,700

Publication Date: May 13, 2026
Subject: Technical disclosure of derivative implementations and novel applications of the clearinghouse systems and methods described in U.S. Patent 8,725,700 for the purpose of establishing prior art. This document is intended to make subsequent patent filings on these specific variations obvious to a person skilled in the art.

---

Derivations Based on Independent Claim 1: Clearinghouse System

Claim 1 describes a computerized clearinghouse that matches property owners willing to host wireless equipment with carriers who have infrastructure needs. The following are derivative implementations.

1. Decentralized P2P Infrastructure Marketplace

• Axis: Material & Component Substitution
• Enabling Description: The centralized clearinghouse server and database architecture is replaced by a decentralized, peer-to-peer (P2P) network using the InterPlanetary File System (IPFS) for data storage and a distributed hash table (DHT) for participant discovery. End-user clients (on their personal computers or dedicated hardware) create and sign data objects representing their property and terms. These objects are published to the IPFS network, returning a unique content identifier (CID). The CID is then announced on a topic-specific DHT. Carrier clients query the DHT for CIDs within a specific geographic bounding box, retrieve the offer objects from IPFS, and initiate a direct, peer-to-peer connection with the end-user to negotiate. This removes the single point of failure and control of a central operator.
• Mermaid Diagram:

  sequenceDiagram
      participant EU as End-User Client
      participant IPFS
      participant DHT
      participant CC as Carrier Client
  
      EU->>IPFS: Publishes signed offer object (property data, terms)
      IPFS-->>EU: Returns Content ID (CID)
      EU->>DHT: Announces CID with geographic hash
      CC->>DHT: Queries for CIDs in geographic area
      DHT-->>CC: Returns list of relevant CIDs
      CC->>IPFS: Retrieves offer objects using CIDs
      CC->>EU: Initiates direct P2P negotiation
  

2. Clearinghouse for Distributed Energy Resource (DER) Management

• Axis: Cross-Domain Application
• Enabling Description: The clearinghouse concept is applied to the management of an electrical power grid. End-users are homeowners with solar panels, residential battery storage systems (e.g., Tesla Powerwall), or bi-directional electric vehicle (EV) chargers. They use a standardized API (e.g., IEEE 2030.5) to register their available energy generation or storage capacity with the clearinghouse. Utility companies (the "carriers") query the clearinghouse via a SCADA-integrated interface to find and bid on aggregated capacity in real-time. This allows the utility to perform "peak shaving" by drawing power from these distributed resources during high demand, rather than spinning up expensive and less efficient peaker power plants. The system also stores local energy market regulations and feed-in tariff rates.
• Mermaid Diagram:

  flowchart TD
      subgraph Homeowners (End-Users)
          A[Solar Panels]
          B[Battery Storage]
          C[EV Charger]
      end
      subgraph Utility (Carrier)
          D[Grid Control Center]
          E[SCADA System]
      end
      subgraph Clearinghouse
          F[DER Registry DB]
          G[Bidding & Dispatch Engine]
          H[Regulatory Rules DB]
      end
  
      A & B & C -->|Register Capacity via API| F
      D -->|Queries for Capacity| G
      E -->|Queries for Capacity| G
      G --> F
      F --> G
      G --> H
      G -->>|Sends Dispatch Signals| A & B & C
      G -->>|Reports Bid Results| D
  

3. AI-Powered Predictive Site Acquisition

• Axis: Integration with Emerging Tech
• Enabling Description: The clearinghouse integrates a machine learning (ML) model for proactive site acquisition. The model is trained on diverse datasets: carrier-provided RF propagation maps, user density heatmaps, public GIS data (terrain, foliage), municipal zoning plans, and historical site acquisition success/failure rates. Instead of waiting for a carrier request, the AI model continuously analyzes network performance data to predict future coverage gaps or capacity shortfalls. It then preemptively searches the end-user database to identify and rank a "top 5" list of optimal host properties for that predicted future need. The system can automatically contact these high-ranking property owners with a preliminary offer, significantly shortening the site acquisition lifecycle.
• Mermaid Diagram:

  graph LR
      subgraph Data Inputs
          A[RF Propagation Maps]
          B[User Density Data]
          C[GIS Data]
          D[Zoning Ordinances]
      end
      subgraph Clearinghouse
          E[End-User Property DB]
          F(ML Predictive Model)
          G[Automated Outreach Module]
      end
      subgraph Carrier
          H[Network Planning Dept]
      end
  
      A & B & C & D --> F
      F --> E
      E --> F
      F -- Generates 'Top 5' List --> G
      G -- Sends Preliminary Offer --> E
      F -- Provides Proactive Insights --> H
  

4. Low-Power, Graceful Degradation Mode

• Axis: The "Inverse" or Failure Mode
• Enabling Description: The system is designed for high-availability in disaster scenarios where central infrastructure may be compromised. If a carrier or end-user client cannot connect to the central clearinghouse server, it enters a "graceful degradation" mode. In this mode, the client uses a local mesh networking protocol (e.g., LoRaWAN or Wi-Fi HaLow) to broadcast a "request for site" or "site available" message to other devices within a multi-kilometer radius. Messages contain a geographic identifier and essential parameters. Devices that receive a message matching their state (e.g., a carrier client receiving a "site available" message) can establish a direct, ad-hoc connection to exchange further details. While less efficient than the centralized system, it enables emergency network restoration by leveraging local, device-to-device communication.
• Mermaid Diagram:

  stateDiagram-v2
      [*] --> Online
      Online: Normal operation with central server.
      Online --> Degraded: on serverConnectionFailure
      Degraded: Switches to mesh protocol (e.g., LoRaWAN).
      Degraded --> Online: on serverConnectionRestored
  
      state Degraded {
          direction LR
          [*] --> Broadcasting
          Broadcasting: Send periodic 'site needed/avail' msgs
          Broadcasting --> Listening: after timeout
          Listening: Scan for incoming mesh msgs
          Listening --> Broadcasting: after timeout
          Listening --> DirectConnect: on relevantMsgReceived
          DirectConnect: Establish P2P link for negotiation
          DirectConnect --> Broadcasting
      }
  

---

Derivations Based on Independent Claim 19: Method for Enhancing Service

Claim 19 describes a method where a wireless device queries a clearinghouse for location-based QoS data to select the optimal wireless service.

1. ASIC-Based RF Environment Co-processor

• Axis: Material & Component Substitution
• Enabling Description: The functionality of network scanning, data retrieval, and service selection is offloaded from the device's main application processor to a dedicated, low-power Application-Specific Integrated Circuit (ASIC). This "RF Environment Co-processor" maintains a local, compressed cache of the clearinghouse's QoS data for the user's typical roaming areas. The ASIC continuously monitors the RF spectrum for available networks (cellular, Wi-Fi, satellite) and evaluates them against the cached data according to a user-defined policy (e.g., "minimize latency," "maximize battery"). It makes handoff decisions and instructs the main baseband processor to switch networks, all without waking the power-hungry application processor, thereby extending device battery life by an order of magnitude.
• Mermaid Diagram:

  graph TD
      subgraph Device
          A[Application Processor (AP)]
          B[Baseband Processor]
          C(RF Environment Co-processor - ASIC)
          D[RF Front-End]
          E[Local QoS Cache]
      end
      F((Clearinghouse Server))
  
      D <--> C
      C <--> E
      C -- Handoff Command --> B
      B <--> D
      A -- Policy Settings --> C
      E <-->|Periodic Sync| F
  

2. V2X Channel Selection for Autonomous Vehicles

• Axis: Cross-Domain Application
• Enabling Description: The method is applied to Vehicle-to-Everything (V2X) communications for autonomous and semi-autonomous vehicles. The vehicle's telematics control unit (TCU) continuously determines its location via GNSS and inertial measurement. It queries a specialized V2X clearinghouse, which aggregates real-time performance data (latency, packet error rate, message collision rate) for available communication bearers like DSRC, C-V2X PC5, and 5G NR sidelink. The clearinghouse data is crowdsourced from other vehicles and roadside units (RSUs). The TCU uses the clearinghouse's ranked list to select the most reliable bearer for transmitting and receiving safety-critical messages, such as Basic Safety Messages (BSMs) and Cooperative Perception Messages (CPMs), optimizing for sub-10ms latency.
• Mermaid Diagram:

  sequenceDiagram
      participant V as Vehicle TCU
      participant GNSS
      participant CH as V2X Clearinghouse
      participant V2X_Radio as Multi-mode V2X Radio
  
      loop Real-time Operation
          V->>GNSS: Get current location
          GNSS-->>V: Return lat/lon/vector
          V->>CH: Query QoS for V2X bearers at location
          CH-->>V: Return ranked list {C-V2X, DSRC, 5G NR}
          V->>V2X_Radio: Select optimal bearer based on list
          V2X_Radio-->>V: Acknowledge selection
      end
  

3. Blockchain-Verified QoS Ledger

• Axis: Integration with Emerging Tech
• Enabling Description: The clearinghouse's QoS database is replaced with a public, permissionless blockchain (a "QoS Ledger"). Wireless devices run a client that periodically measures network performance (upload/download speed, latency, jitter, signal strength). These measurements, along with a location hash (e.g., Geohash), are bundled into a transaction, signed by the device's unique private key, and submitted to the blockchain. The clearinghouse now acts as a trusted oracle and data aggregator, reading the immutable, tamper-proof data from the QoS Ledger to generate its network rankings. This prevents any single entity, including carriers, from manipulating the performance data and creates a fully transparent and verifiable system for all participants.
• Mermaid Diagram:

  flowchart TD
      A[Mobile Device] -->|1. Measures QoS| B(Create Transaction: {LocationHash, QoS_Data, Signature})
      B --> C{QoS Ledger Blockchain}
      C -- Block is Mined --> D[Distributed Nodes]
      E[Clearinghouse/Aggregator] -->|2. Reads Ledger Data| C
      E -->|3. Generates Ranked List| F[User Profile DB]
      A -->|4. Queries for Ranked List| E
      E -->|5. Returns location-specific ranking| A
  

4. Hypersonic Vehicle Comms Link Management

• Axis: Operational Parameter Expansion
• Enabling Description: The method is adapted for managing communication links on a hypersonic vehicle traveling at Mach 5+. The vehicle's flight computer pre-fetches QoS data from a specialized clearinghouse for its entire planned trajectory. This data ranks available communication links, including LEO/MEO satellite constellations (e.g., Starlink, Kuiper) and terrestrial ground stations. The selection algorithm, running on radiation-hardened hardware, must operate in real-time, accounting for extreme Doppler shifts that can exceed 100 kHz, rapid changes in atmospheric plasma attenuation during different flight phases, and handoff decisions that must be executed in under 50 milliseconds to maintain telemetry and control links. The ranked list prioritizes link stability and minimal bit error rate (BER) over raw bandwidth.
• Mermaid Diagram:

  graph LR
      subgraph Pre-Flight
          A[Mission Planner] --> B[Hypersonic Clearinghouse]
          B -- Trajectory QoS Data --> C[Onboard Flight Computer]
      end
      subgraph In-Flight (Mach 5+)
          C -- Real-time Selection --> D{Link Management Algorithm}
          D -- Input --> E[Doppler Shift Estimator]
          D -- Input --> F[Plasma Attenuation Model]
          D -- Handoff Command --> G[Multi-Link Comms Array]
          G <--> H((LEO/MEO Satellites))
          G <--> I((Ground Stations))
      end
  

---

Derivations Based on Independent Claim 26: Method for Localized Content

Claim 26 describes a method for injecting location-specific content into a user's data stream based on the location of the network infrastructure.

1. SmartNIC-Based Line-Rate Content Injection

• Axis: Material & Component Substitution
• Enabling Description: The local content/ad server is eliminated and its function is embedded directly into programmable hardware at the network edge. A Smart Network Interface Card (SmartNIC) or Data Processing Unit (DPU) is installed in the base station's Distributed Unit (DU) or at the mobile edge computing (MEC) node. The SmartNIC is programmed with P4 or a similar language to perform line-rate deep packet inspection (DPI) on egress user traffic. When it identifies an HTTP/QUIC request to a target domain, it uses an on-chip key-value store (mapping its own location ID to content) to fetch the localized content and rewrites the packet payload in hardware before it is forwarded to the radio unit. This process occurs with microsecond-level latency, making it imperceptible to the user.
• Mermaid Diagram:

  classDiagram
      class SmartNIC {
          +PacketProcessorFPGA
          +OnChipMemory
          +performDPI()
          +rewritePacketPayload()
      }
      class KeyValueStore {
          +locationID
          +contentPayload
      }
      class Clearinghouse {
          +updateContent()
      }
      SmartNIC "1" -- "1" KeyValueStore : Contains
      Clearinghouse "1" -- "n" SmartNIC : Pushes updates to
  

2. Location-Based AR Game Asset Injection

• Axis: Cross-Domain Application
• Enabling Description: The method is used to deliver dynamic content for an Augmented Reality (AR) mobile game without relying on continuous device-side GPS polling. The clearinghouse maps game assets (e.g., 3D models of creatures, quest items, non-player characters) to specific Wi-Fi access points or 5G small cells deployed at physical locations like parks, museums, or city squares. When a player's device connects to one of these network nodes and the game requests assets from its main server, the edge infrastructure intercepts the request. It modifies the server's response to inject the additional assets specific to that node's physical location. The player's game client then renders these assets, making it appear as if a rare creature has spawned right next to them.
• Mermaid Diagram:

  sequenceDiagram
      participant Player as Player Device (Game Client)
      participant Edge as Edge Node (e.g., 5G gNB)
      participant CH as Clearinghouse
      participant GameSrv as Main Game Server
  
      Player->>Edge: Connects to Network
      Player->>GameSrv: Request game state/assets for area
      Edge->>CH: Query local content for self.locationID & "game.com"
      CH-->>Edge: Return location-specific AR Asset Pack
      Edge->>GameSrv: Forward original request
      GameSrv-->>Edge: Return standard asset response
      Edge->>Edge: Modify response, inject AR Asset Pack
      Edge-->>Player: Return modified response
      Player->>Player: Renders combined standard and local assets
  

3. Hyper-local IoT-Triggered Content

• Axis: Integration with Emerging Tech
• Enabling Description: The system's trigger for content injection is expanded from the static location of the network infrastructure to include real-time data from a local Internet of Things (IoT) sensor mesh. The clearinghouse subscribes to an MQTT message broker that receives data from sensors in the vicinity of a cell tower (e.g., temperature, air quality, foot traffic counters, BLE beacons). A local content rule engine associates specific IoT data patterns with content. For example, a rule might state: "IF foot_traffic_sensor_3 > 50 AND time_is_between(12:00, 13:00), THEN inject 'lunch special' content for users connected to this tower." This allows for dynamic, context-aware content delivery that responds to real-world conditions in real-time.
• Mermaid Diagram:

  flowchart TD
      subgraph IoT Mesh
          A[Temp Sensor]
          B[Foot Traffic Counter]
          C[BLE Beacon]
      end
      subgraph Edge Network
          G[User Device]
          H[Base Station]
      end
  
      A & B & C --> D[MQTT Broker]
      E[Clearinghouse/Rule Engine] -- Subscribes to --> D
      E -- Fetches content from --> F[Content DB]
      E -- Pushes rule-triggered content to --> H
      H -- Injects content into data stream for --> G
  

---

Combination Prior Art Scenarios

The following describe combinations of the core concepts in U.S. Patent 8,725,700 with existing open-source standards to create novel and obvious implementations.

1. Claim 1 + Hyperledger Fabric: The clearinghouse for infrastructure sites is implemented as a private blockchain using the Hyperledger Fabric framework. Carriers, property owners, and municipal regulatory bodies each operate nodes on the network.

   • Enabling Description: A property owner's offer to host equipment is committed to the immutable ledger as a digital asset. A carrier's request for a new site is executed as a query against the ledger's world state. Lease agreements are encoded as smart contracts (chaincode) that automatically trigger monthly rental payments (via an integrated payment oracle) contingent upon verifiable uptime data, which is also committed to the chain by IoT sensors on the equipment. Municipalities can encode zoning rules directly into the chaincode, ensuring that any proposed match automatically complies with local ordinances, creating a transparent and auditable marketplace.

2. Claim 19 + Prometheus/Grafana: The system for collecting, storing, and delivering QoS data is built entirely on the open-source Prometheus monitoring and Grafana visualization stack.

   • Enabling Description: A lightweight exporter client is deployed on wireless devices. This client exposes a /metrics HTTP endpoint presenting current network performance data (RSRP, RSRQ, latency, packet loss) in the Prometheus exposition format. A central clearinghouse runs a Prometheus server that is configured to scrape these metrics from millions of registered devices. The collected time-series data is stored in a compatible database (e.g., Cortex or Thanos for long-term storage). The "ranked list of best-performing services" delivered to the device is the result of a pre-configured PromQL (Prometheus Query Language) query executed against this dataset. Carrier-facing portals are built as Grafana dashboards to visualize network performance across various geographic cuts.

3. Claim 26 + Envoy Proxy with WebAssembly (WASM) Filter: The location-specific content insertion functionality is implemented as a custom filter for the open-source Envoy proxy, deployed at the network edge.

   • Enabling Description: An Envoy proxy instance is co-located with the 5G User Plane Function (UPF) or cable modem termination system (CMTS). A custom network filter, compiled to a WebAssembly (WASM) module for portability and security, is loaded by Envoy. When processing an egress data stream, the WASM filter extracts a location identifier from the proxy's own configuration. It then makes an asynchronous gRPC call to the clearinghouse database to fetch the appropriate local content for that location and the destination of the user's request. Upon receiving the content, the filter uses Envoy's buffer manipulation APIs to modify the original HTTP/S response body, inserting the localized content before forwarding the data to the user. This leverages Envoy's high-performance, extensible, and widely adopted architecture for edge processing.