Derivative works — US Patent 12125070

Defensive Disclosure and Prior Art Generation for Inventions Related to US 12,125,070

Publication Date: April 26, 2026
Author: Senior Patent Strategist and Research Engineer
Subject: This document discloses novel derivative implementations, applications, and combinations of technologies related to client-side content monetization systems. The intent is to place these concepts in the public domain to serve as prior art against future patent applications claiming these or similar incremental innovations.

Derivative Set 1: Variations on the Core Concept of a Client-Side Ad Auction

1.1. Material & Component Substitution: Hardware-Accelerated Auctioning on a Trusted Execution Environment (TEE)

Enabling Description: The client-side auction mechanism is implemented not in the primary device operating system, but within a dedicated hardware-based Trusted Execution Environment (TEE) such as an Intel SGX enclave, an ARM TrustZone, or a dedicated Trusted Platform Module (TPM 2.0) co-processor. The ad cache, user profile attributes, and the auction logic itself are loaded into this secure hardware. Each ad's bidding rules (the "control") is a WebAssembly (WASM) binary signed by the advertiser. The TEE's auction runtime executes these WASM modules in a sandboxed environment, calculates the bids based on secure access to the user attributes, and determines the winner. The TEE then provides an auditable, cryptographically signed attestation of the auction result (including the winning ad's identifier and the winning bid value) directly to the media player for rendering and to the clearinghouse for settlement. This prevents tampering with the auction process by malicious software on the host OS.

Mermaid Diagram (Flowchart):

flowchart TD
    A[Media Player Requests Ad for Slot 7] --> B{Secure Enclave / TEE};
    C[Ad Cache] -- Encrypted Ad Packages --> B;
    D[User Profile DB] -- Encrypted Attributes --> B;
    B --> E[Instantiate WASM Runtime in Enclave];
    E --> F[For each Ad: Execute Signed Bidding WASM];
    F -- Reads User Attributes --> B;
    F -- Outputs Bid Value --> G[Auction Logic in Enclave];
    G --> H[Select Winning Bid];
    H -- Winning Ad ID --> A;
    H -- Signed Auction Attestation --> I[Clearinghouse];

1.2. Operational Parameter Expansion: Nanoscale Biological System Auction

Enabling Description: This invention is applied to a network of programmable, biocompatible nanobots operating within a biological host (e.g., a human bloodstream). Multiple pharmaceutical entities can deploy competing nanobot "agents" designed to perform a specific function, such as targeted drug delivery or diagnostic sensing. When a pathological condition is detected (e.g., a cluster of cancer cells), the nanobot that first detects it initiates a local, peer-to-peer auction. Competing therapeutic agents (the "ads") bid to be released at the site. The "bid" is a multi-factor score calculated by each agent's control logic based on local biomarker concentrations (the "user profile"), the agent's efficacy for that specific pathology, its potential for side effects (a negative bid modifier), and its remaining payload. The auction ensures the most appropriate therapeutic agent is deployed in real-time at the microscopic level, with the auction result logged for medical records.

Mermaid Diagram (Sequence Diagram):

sequenceDiagram
    participant SensorBot as Sensor Nanobot
    participant ChemoBotA as Chemo Agent A
    participant ChemoBotB as Chemo Agent B
    participant TargetCell as Malignant Cell Cluster

    SensorBot->>TargetCell: Detects Pathological Biomarkers
    SensorBot->>ChemoBotA: Initiate Auction (Context: Biomarker Profile)
    SensorBot->>ChemoBotB: Initiate Auction (Context: Biomarker Profile)
    ChemoBotA-->>SensorBot: Submit Bid (Efficacy=95%, SideEffect=5%)
    ChemoBotB-->>SensorBot: Submit Bid (Efficacy=88%, SideEffect=1%)
    SensorBot->>SensorBot: Run Auction Logic (Maximize Efficacy / Minimize Side Effects)
    SensorBot->>ChemoBotB: Announce Winner
    ChemoBotB->>TargetCell: Release Therapeutic Payload

1.3. Cross-Domain Application: Agricultural Technology (AgTech) Resource Arbitration

Enabling Description: An autonomous farming vehicle (e.g., a drone or tractor) is equipped with a local cache of "treatment plans" from various agricultural suppliers (e.g., Monsanto, Syngenta). Each plan is a control object containing rules for applying a product (e.g., fertilizer, herbicide, or beneficial insects). As the vehicle traverses a field, its onboard IoT sensors (e.g., hyperspectral imagers, soil nitrogen sensors) provide real-time local context. For each square-meter plot of land, the vehicle's onboard computer runs an auction. Each treatment plan's control object calculates a "bid" based on the sensor data, weather forecasts, and commodity futures prices. The bid represents the projected net economic value (yield gain minus input cost) of applying that treatment to that specific plot. The winning plan is executed instantly, enabling hyper-precise, economically optimized farming.

Mermaid Diagram (State Diagram):

stateDiagram-v2
    [*] --> Traversing
    Traversing --> Scanning: Enter new grid-plot
    Scanning --> Auction: Sensor data acquired (N, P, K, H2O levels)
    state Auction {
        direction LR
        [*] --> Bidding
        Bidding --> Bidding: Evaluate next treatment plan
        Bidding --> Selection: All plans evaluated
        Selection --> [*]: Winning plan chosen
    }
    Auction --> Application: Execute winning plan (e.g., apply nitrogen)
    Application --> Traversing: Move to next grid-plot

1.4. Integration with Emerging Tech: AI-Driven Federated Bidding Models

Enabling Description: Instead of static, hard-coded rules, each advertisement is packaged with a compact, pre-trained neural network (a "bid-model"), such as a lightweight TensorFlow Lite or ONNX model. This model takes the local user and context vector (e.g., time of day, location, app usage history, expressed as a normalized vector) as input and outputs a bid price. The client device's auction manager is a federated learning client. After a block of auctions (e.g., every 100 ad impressions), the client computes a model update based on the local performance (e.g., user interactions, dismissals). This anonymized gradient update, not the user's raw data, is sent back to the advertiser's federated learning server. The server aggregates updates from thousands of clients to train a new global model, which is then pushed out with future ad packages. This continuously optimizes bidding strategy while preserving user privacy.

Mermaid Diagram (Class Diagram):

classDiagram
  class FederatedClient {
    +runAuction(adModels, contextVector)
    +computeModelUpdate(auctionResults)
    +sendUpdateToServer(gradient)
  }
  class BidModel {
    <<TensorFlow Lite>>
    +predictBid(contextVector): float
  }
  class AdPackage {
    -adCreative: video
    -bidModel: BidModel
  }
  class FederatedServer {
    +aggregateGradients(updates)
    +trainGlobalModel()
    +distributeNewModel()
  }
  FederatedClient ..> AdPackage : "uses multiple"
  AdPackage "1" -- "1" BidModel
  FederatedClient ..> FederatedServer : "sends anonymized gradients"
  FederatedServer ..> FederatedClient : "pushes updated global model"

1.5. Inverse/Failure Mode: Auction for "Right-to-be-Forgotten"

Enabling Description: This system operates in reverse. Instead of ads bidding to be shown, locally cached "data agents" from various online services (e.g., social media, data brokers) bid for the right to delete a user's data from their servers. When a user initiates a "delete my profile" request, the client device triggers an auction. The user's device holds a set of verifiable credentials proving account ownership. Each data agent has rules specifying how quickly and completely it can process the deletion. The "bid" is a signed attestation of the deletion's parameters (e.g., "full physical deletion within 24 hours," "anonymization within 72 hours"). The user can configure the auction's objective function: either select the agent that promises the fastest deletion, the most thorough deletion (e.g., including backups), or a balance. The winning agent is granted a temporary, single-use token to execute the deletion command via the service's API. This creates a competitive, auditable market for data privacy services.

Mermaid Diagram (Flowchart):

flowchart TD
    subgraph User Device
        A[User Clicks "Delete My Data"] --> B{Initiate Deletion Auction};
        C[Data Agent Cache] -- Agents from Google, Meta, etc. --> B;
        D[User Preferences] -- "Prioritize Speed vs. Thoroughness" --> B;
    end
    B --> E[Agents bid with Deletion Promises];
    subgraph Auction Bids
        F["Agent F: Full Deletion in 24h"]
        G["Agent G: Anonymize in 1h"]
        H["Agent H: Partial Deletion Immediately"]
    end
    E --> I{Auction selects best promise based on User Prefs};
    I -- Grant Deletion Token to Winner --> J[Winning Data Agent];
    J -- Execute API Deletion Call --> K((Service Backend));
    K -- Signed Deletion Receipt --> J;
    J -- Forward Receipt --> A;

Derivative Set 2: Variations on the Core Concept of a DRM-Managed Trusted Execution

2.1. Cross-Domain Application: Industrial IoT (IIoT) Command & Control

Enabling Description: In a smart factory setting, a piece of critical machinery (e.g., a robotic arm) runs a DRM engine. Various subsystems (e.g., the vision system, the motor controller, the safety interlock) need to send it commands. To prevent conflicting or unsafe instructions, commands are not sent directly. Instead, they are packaged as "command-objects" with an associated DRM control. When a subsystem wants to issue a command (e.g., "move arm to position X"), its command-object bids for execution time on the robotic arm's controller. The DRM engine on the arm runs a continuous real-time auction. The "bid" is based on the command's priority, its safety implications, and its dependency on other operations. A command from the safety system will have an infinitely high bid. A routine quality-check command will have a low bid. The DRM engine ensures only the winning, authenticated command is executed, creating a secure, auditable, and deterministic control flow for industrial automation.

Mermaid Diagram (Sequence Diagram):

sequenceDiagram
    participant Vision as Vision System
    participant Safety as Safety System
    participant Planner as Production Planner
    participant RobotDRM as Robotic Arm DRM Engine

    Safety->>RobotDRM: Submit Bid (Command: E-STOP, Priority: MAX_INT)
    Vision->>RobotDRM: Submit Bid (Command: Inspect Part, Priority: 50)
    Planner->>RobotDRM: Submit Bid (Command: Move to Assembly, Priority: 100)
    RobotDRM->>RobotDRM: Run Priority Auction
    RobotDRM->>Planner: Grant Execution (Planner Won)
    Note over RobotDRM: If E-STOP bid, it would always win.
    Planner->>RobotDRM: Execute "Move to Assembly" Command

Combination Prior Art Scenarios

Combination with IETF's SUIT (Software Updates for IoT) Standard: The delivery and installation of firmware updates to a fleet of IoT devices are managed using the client-side auction mechanism. Multiple update packages (e.g., a stable version, a beta version with new features, a critical security patch) are pushed to the devices' local caches. Each update is packaged as a SUIT manifest, but also includes a DRM control with bidding rules. The device's local DRM engine runs an auction to decide which update to install. The "bid" is determined by factors defined in the control, such as the update's criticality, the device's current stability, its battery level, and network conditions. A critical security patch would generate the highest bid, ensuring its immediate installation, while a feature-rich beta update might only win the auction on a device with a full battery and a stable Wi-Fi connection. This creates a decentralized, policy-driven update system.
Combination with OpenID Connect (OIDC) Standard: The user attributes used for ad auctioning are not stored on the device but are fetched in a just-in-time manner using the OpenID Connect protocol. When an auction begins, the client-side DRM engine acts as an OIDC Relying Party. It requests specific claims (e.g., birthdate, address:country) from a user-chosen Identity Provider (e.g., "Sign in with Google" or a self-sovereign identity wallet). The Identity Provider authenticates the user and returns a signed ID Token containing the requested claims. The DRM engine verifies the token's signature and uses the claims as input for the ad-bidding controls. The ID Token is held only in memory for the duration of the auction and then discarded, ensuring that sensitive user data is never permanently stored on the device for advertising purposes.
Combination with the ISO/IEC 14443 (NFC) Standard: A client-side auction is triggered by a physical interaction via Near Field Communication (NFC). For example, a user taps their smartphone on a smart poster at a bus stop. The NFC tag on the poster does not contain an ad, but instead contains a signed "auction request" payload, specifying a content context (e.g., "concert_promo_slot_1"). The user's phone receives this request, and the DRM engine initiates a local auction among cached ads that are relevant to live events or music. The winning ad (e.g., a link to buy tickets for a local band) is immediately displayed to the user. The bid logic within the ad controls can heavily weight the physical location and context provided by the NFC tag, enabling hyper-contextual, physically-triggered advertising auctions.