Derivative works

Defensive Disclosure and Prior Art Generation for U.S. Patent 8,671,139

Publication Date: April 29, 2026
Subject Matter: Derivatives, extensions, and combinations of the methods and systems for conditional, profile-based authorization of electronic content delivery as described in U.S. Patent 8,671,139. This document is intended to enter the public domain to serve as prior art.

---

Core Mechanism Analysis

The foundational concept derived from U.S. Patent 8,671,139 involves a computer system that, upon receiving a visitor's profile attribute from a first media property, directs indicia of a condition to a third-party server controlling content space on a second media property. The system then authorizes the third-party server to display content correlated with the profile attribute, but only if the specified condition is met when the visitor later accesses the second media property. The following disclosures describe novel variations and applications of this core mechanism.

---

1. Material & Component Substitution Derivatives

1.1. System Utilizing Privacy-Preserving Cryptographic Identifiers

• Enabling Description: This variation replaces standard cookie-based or device-ID-based visitor tags with privacy-preserving cryptographic constructs. When a visitor's profile is collected at the first media property, the system generates a Blind Signature based on the visitor's identifier using a protocol like RSA-PSS. The system directs the condition and the blinded identifier to the third-party server. When the visitor arrives at the second media property, their browser provides the now-unblinded signature. The third-party server can verify the signature against the condition without ever knowing the visitor's original identity, thus preserving privacy while executing the conditional logic. The profile attributes themselves can be encoded using zero-knowledge proofs (e.g., zk-SNARKs), allowing the third-party server to verify that a visitor meets a profile criterion (e.g., "is interested in automotive") without learning the specific details of their browsing history.

• Mermaid Diagram:

  sequenceDiagram
      participant Visitor
      participant FirstMediaProperty
      participant BT_System as BT System (Authorizer)
      participant ThirdPartyServer as Ad Server (Verifier)
      participant SecondMediaProperty
  
      Visitor->>FirstMediaProperty: Visits page (profile collected)
      FirstMediaProperty->>BT_System: Redirect with Profile & VisitorID
      BT_System->>BT_System: Generates Blind Signature for VisitorID
      BT_System->>ThirdPartyServer: Send(Condition, Blinded_ID, Profile_Proof)
      Visitor->>SecondMediaProperty: Visits page
      SecondMediaProperty->>Visitor: Ad space requests content
      Visitor->>ThirdPartyServer: Request Ad (Presents Unblinded_Signature)
      ThirdPartyServer->>ThirdPartyServer: 1. Verify Unblinded_Signature
      ThirdPartyServer->>ThirdPartyServer: 2. Evaluate Condition(Profile_Proof)
      alt Condition Met
          ThirdPartyServer->>Visitor: Serve Targeted Ad
      else Condition Not Met
          ThirdPartyServer->>Visitor: Serve Default Ad
      end
  

1.2. System with Decentralized Profile & Condition Storage using a Distributed Hash Table (DHT)

• Enabling Description: Instead of a centralized database, the Behavioral Targeting (BT) system stores the (visitor_tag -> condition) mapping in a peer-to-peer Distributed Hash Table (DHT) like Kademlia. When the visitor's profile is collected, the BT system computes a hash of the visitor tag and stores the associated condition object at the nodes in the DHT responsible for that hash key. When the visitor arrives at the second media property, the third-party server, also a peer in the DHT, queries the network using the hash of the visitor's tag to retrieve the condition. This architecture increases resilience and scalability while reducing reliance on a single central server. The condition itself includes a TTL (Time-To-Live) and a cryptographic signature from the BT system to ensure its validity and prevent tampering.

• Mermaid Diagram:

  graph TD
      A[Visitor at First Property] --> B{BT System};
      B --> C{Generate (Tag, Condition)};
      C --> D[Hash(Tag) -> DHT_Key];
      D --> E((DHT Network));
      E -- Store(DHT_Key, Condition) --> E;
  
      F[Visitor at Second Property] --> G{3rd-Party Ad Server};
      G -- Has Tag --> H[Hash(Tag) -> DHT_Key];
      H --> I((DHT Network));
      I -- Lookup(DHT_Key) --> J[Retrieve Condition];
      J --> K{Evaluate Condition};
      K -- True --> L[Serve Ad];
      K -- False --> M[Serve Default];
  

---

2. Operational Parameter Expansion Derivatives

2.1. High-Frequency / Real-Time Bidding (RTB) System with Sub-Millisecond Condition Evaluation

• Enabling Description: This variation adapts the core mechanism for the extreme low-latency environment of high-frequency ad exchanges. The "first media property" is a user's entire browsing session, with profile attributes streamed in real-time. The "condition" is not static but is a dynamic executable code snippet (e.g., a WebAssembly module) representing a complex bidding algorithm. The BT system directs this bidding module to an edge server co-located with the ad exchange. When an ad opportunity arises for the visitor, the third-party server (the ad exchange) executes the visitor-specific module in a secure sandbox. The module evaluates market conditions, the visitor's real-time context, and the profile attributes, returning a bid price within a 10-millisecond window. The authorization is conditional on the module's bid winning the auction.

• Mermaid Diagram:

  stateDiagram-v2
      [*] --> StreamingProfile: Visitor Browsing
      StreamingProfile --> BiddingModuleCompilation: BT System receives profile updates
      BiddingModuleCompilation --> PushingToEdge: Push visitor-specific Wasm module to Ad Exchange Edge
      PushingToEdge --> AwaitingAdRequest
  
      AwaitingAdRequest --> AdAuction: Ad opportunity for visitor
      AdAuction --> ModuleExecution: Exchange executes Wasm module
      ModuleExecution --> BidEvaluation: Module outputs bid price
      BidEvaluation --> [*]: Auction concludes
      BidEvaluation -- Bid Wins --> AdServed
      BidEvaluation -- Bid Loses --> NoAd
      AdServed --> [*]
      NoAd --> [*]
  

2.2. Low-Power / Edge Computing System for IoT Devices

• Enabling Description: This system operates on resource-constrained IoT devices (e.g., smart home displays, in-car infotainment systems) with intermittent network connectivity. The "first media property" could be a user's interaction with a companion mobile app. The BT system, recognizing the target is a low-power device, pre-calculates and pushes a highly compressed "decision tree" file, which represents the condition logic, to the IoT device itself. The third-party server is a software module on the device (e.g., the display's OS). When a content slot is available, the local module evaluates the pre-loaded decision tree against local device state (time of day, sensor data, user presence). Authorization to display content is granted locally without a round-trip to a remote server, conserving power and bandwidth. The content itself (e.g., a set of low-resolution ads) may also be pre-cached on the device.

• Mermaid Diagram:

  graph LR
      subgraph Cloud
          A[Mobile App Interaction] --> B{BT System};
          B --> C[Generate Compressed Condition (Decision Tree)];
          C --> D{Push to Device};
      end
      subgraph IoT Device
          D -- Syncs --> E[Local Storage: DecisionTree.bin];
          F[Local Trigger: e.g., idle screen] --> G{Local Content Engine};
          E --> G;
          H[Local Sensor Data] --> G;
          G -- Evaluates Tree --> I{Authorization Decision};
          I -- Granted --> J[Display Pre-Cached Ad];
          I -- Denied --> K[Display Default Content];
      end
  

---

3. Cross-Domain Application Derivatives

3.1. Personalized Healthcare: Conditional Patient Information Delivery

• Enabling Description: A hospital's Electronic Health Record (EHR) system acts as the BT system. The "first media property" is a physician's entry of a new diagnosis or lab result for a patient. The "profile attribute" is the new medical code (e.g., ICD-10 code for Type 2 Diabetes). The EHR system directs a condition to a third-party server—the hospital's patient portal. The condition is: "If patient logs in within the next 7 days AND has not yet opened a document tagged 'diabetes_intro', display this educational video." Authorization is based on the patient's medical profile. This ensures timely, relevant, and context-aware delivery of medical information without overwhelming the patient.

• Mermaid Diagram:

  sequenceDiagram
      participant Physician
      participant EHR_System as EHR System
      participant PatientPortal as Patient Portal
      participant Patient
  
      Physician->>EHR_System: Enters new diagnosis (Profile)
      EHR_System->>PatientPortal: Direct(Condition: DisplayEduVideo IF login<7d AND !viewed) for PatientID
      Patient->>PatientPortal: Logs in
      PatientPortal->>PatientPortal: Evaluate Condition for PatientID
      alt Condition Met
          PatientPortal->>Patient: Display specific educational video
      else Condition Not Met
          PatientPortal->>Patient: Show standard dashboard
      end
  

3.2. Cybersecurity: Dynamic Network Access Control

• Enabling Description: A Security Information and Event Management (SIEM) system functions as the BT system. A user's login to a low-security internal application is the "first media property." The "profile attribute" is the user's role and device posture (e.g., OS patched, corporate VPN). The SIEM directs a condition to a network firewall (the "third-party server") controlling access to a high-security database. The condition is: "Authorize access for this user's IP address to the finance database for the next 60 minutes ONLY IF their continuous behavior monitoring score remains below a threat threshold of 75." This creates a just-in-time, behavior-contingent access rule that is more secure than a static permission.

• Mermaid Diagram:

  graph TD
      A[User logs into App1] --> B{SIEM System};
      B -- Profile: UserRole, DevicePosture --> C{Generate Conditional Access Rule};
      C -- Rule: Authorize DB_Access IF ThreatScore < 75 --> D(Firewall);
      E[User attempts DB Access] --> D;
      F[Continuous Behavior Monitor] -- ThreatScore --> D;
      D -- Evaluates Rule --> G{Access Granted/Denied};
  

3.3. Agriculture Technology (AgTech): Precision Irrigation Authorization

• Enabling Description: A farm management platform is the BT system. A satellite imagery service providing NDVI (Normalized Difference Vegetation Index) data is the "first media property." A low NDVI reading in a specific field is the "profile attribute," indicating plant stress. The platform directs a condition to the field's IoT irrigation controller (the "third-party server"). The condition: "Authorize a 20-minute watering cycle for Zone 4 at 5:00 AM, but ONLY IF the local soil moisture sensor reading is below 25% and the chance of rain in the next 12 hours is less than 10%." This combines high-level analysis with real-time, on-site data for hyper-efficient resource management.

• Mermaid Diagram:

  sequenceDiagram
      participant Satellite
      participant FarmPlatform
      participant IrrigationController
      participant SoilSensor
      participant WeatherAPI
  
      Satellite->>FarmPlatform: Provides NDVI map (Profile)
      FarmPlatform->>FarmPlatform: Detects stress in Zone 4
      FarmPlatform->>IrrigationController: Send(Condition: Irrigate IF moisture<25% AND rain<10%)
      loop Every 15 minutes
          SoilSensor->>IrrigationController: Moisture reading
          WeatherAPI->>IrrigationController: Rain forecast
      end
      IrrigationController->>IrrigationController: At 5:00 AM, evaluate Condition
      alt Condition Met
          IrrigationController->>IrrigationController: Activate watering cycle
      end
  

---

4. Integration with Emerging Technology Derivatives

4.1. AI-Driven Reinforcement Learning for Condition Optimization

• Enabling Description: The core mechanism is integrated with a Reinforcement Learning (RL) agent. The "state" for the agent includes the visitor's profile attributes and the context of the second media property. The "action" is the generation of a condition, specifically the financial parameters within it (e.g., the bid price in Price < X). The "reward" is the measured profit or loss from the eventual ad display. The BT system directs the AI-generated condition to the third-party server. After the ad opportunity, the outcome (impression, click, conversion, cost) is fed back to the RL agent, which updates its policy to generate more profitable conditions in the future. This creates a self-optimizing system that adapts to market dynamics.

• Mermaid Diagram:

  graph TD
      subgraph Training Loop
          A[Feedback: Profit/Loss] --> B[RL Agent];
          B -- Updates Policy --> B;
      end
      subgraph Live Operation
          C[Visitor Profile] --> B;
          B -- Action --> D[Generate Optimal Condition];
          D --> E{3rd-Party Ad Server};
          F[Ad Opportunity] --> E;
          E -- Evaluates Condition --> G[Displays Ad];
          G -- Outcome --> A;
      end
  

4.2. Blockchain-Based Smart Contracts for Auditable Ad Delivery

• Enabling Description: The entire process is managed via a public or permissioned blockchain. The BT system initiates a smart contract, which encodes the condition (e.g., price < 0.50, time < timestamp) and the correlated content (ad creative hash). This transaction is a public "authorization." The third-party ad server is an oracle that monitors the blockchain. When a tagged visitor arrives, the ad server evaluates the condition. If met, it serves the ad and then calls a function on the smart contract, providing cryptographic proof of the event (e.g., a signed attestation). The smart contract then automatically executes a payment transfer from the advertiser's wallet to the second media property's wallet, creating a transparent, auditable, and trustless system for ad delivery and settlement.

• Mermaid Diagram:

  sequenceDiagram
      participant BT_System
      participant Blockchain
      participant AdServer_Oracle
      participant Visitor
      
      BT_System->>Blockchain: Deploy SmartContract(Condition, AdHash, Wallets)
      Visitor->>AdServer_Oracle: Visits page, triggers ad request
      AdServer_Oracle->>AdServer_Oracle: Evaluates Condition from SmartContract
      alt Condition Met
          AdServer_Oracle->>Visitor: Serve Ad
          AdServer_Oracle->>Blockchain: Call execute() on SmartContract with Proof
          Blockchain->>Blockchain: 1. Verify Proof
          Blockchain->>Blockchain: 2. Transfer funds (Advertiser -> Publisher)
      end
  

---

5. The "Inverse" or Failure Mode Derivatives

5.1. Graceful Degradation System with Condition Prioritization

• Enabling Description: This version is designed for high-availability. The BT system categorizes conditions into tiers (e.g., Tier 1: High-Value/Complex, Tier 2: Medium-Value/Simple, Tier 3: Default/Contextual). It directs all tiers of conditions to the third-party server. The third-party server continuously monitors its own system load and latency. If CPU usage exceeds 85% or response time is > 50ms, it automatically stops evaluating Tier 1 conditions and attempts to evaluate Tier 2. If load is critical, it falls back to Tier 3 or a static public service announcement. This ensures the ad slot is always filled, preventing blank spaces and timeouts, while gracefully degrading the quality of targeting under duress.

• Mermaid Diagram:

  stateDiagram-v2
      state "Normal Load (<85% CPU)" as Normal
      state "High Load (85-95% CPU)" as High
      state "Critical Load (>95% CPU)" as Critical
      
      [*] --> Normal
      Normal --> High: Load increases
      High --> Normal: Load decreases
      High --> Critical: Load increases
      Critical --> High: Load decreases
      
      state "Evaluate Tier 1 Condition" as T1
      state "Evaluate Tier 2 Condition" as T2
      state "Serve Default Ad" as T3
  
      Normal: Ad Request -> T1
      High: Ad Request -> T2
      Critical: Ad Request -> T3
  

---

Combination Prior Art with Open-Source Standards

1. Combination with Prebid.js: The BT system's client-side script is implemented as a Prebid.js "Real-Time Data" module. When a visitor's profile is captured, the module stores the condition (e.g., a floor price for this user) in the browser's local storage. During the header bidding auction initiated by Prebid.js, a custom adapter (acting as the third-party server logic) reads this condition from local storage. It then passes the condition into the bid requests sent to various demand partners, instructing them to only return a bid if it meets the user-specific floor price.

2. Combination with IAB OpenRTB Protocol: The indicia of a condition is formally specified as a new extension object in the OpenRTB 3.0 protocol. The BT system, acting as a data management platform (DMP), passes this object in the user.ext field of a bid request. The object contains fields like condition_type: "price_cap", condition_value: "1.25", expiry: 1672531199. The third-party server (a Demand-Side Platform or DSP) is programmed to parse this extension object and will only submit a bid if its internal valuation of the impression satisfies the received condition.

3. Combination with OAuth 2.0: The system is framed as a resource access protocol. The BT system is the "Authorization Server." The second media property's ad space is the "Resource." When a user visits the first property, the BT system issues a JSON Web Token (JWT) containing the user's profile and the condition as private claims. When the user visits the second property, the third-party ad server ("Resource Server") receives this JWT. It validates the token's signature and then evaluates the claims against the current context. Access to the "resource" (i.e., displaying the targeted ad) is granted only if the conditions in the validated token are met.