Derivative works — US Patent 8959146

Defensive Disclosure: US Patent 8959146 - Media Properties Selection Method and System Based on Expected Profit from Profile-Based Ad Delivery

This document describes derivative variations and combination prior art scenarios for US Patent 8959146, focusing on expanding the scope and rendering potential future improvements obvious or non-novel to a person having ordinary skill in the art. The analysis is presented from the perspective of an inventor specializing in the art, with a focus on technical enabling descriptions and architectural illustrations.

Derivatives of Core Claim 1 (Method for Directing Electronic Advertisements)

The core of Claim 1 involves: (a) automatically directing indicia of a condition to a third-party server controlling advertising space on a second media property for display of an advertisement to an electronic visitor; (b) this direction is based on profile attributes received from the visitor's interaction with a first media property; and (c) the advertisement is correlated with these profile attributes. The derivatives explore variations across the specified axes.

1. Material & Component Substitution

Derivative 1.1: WebAssembly (Wasm) Client-Side Condition Evaluation

Enabling Description: Instead of a server-side decision to direct "indicia of a condition," the behavioral targeting (BT) company's computer system generates a small, secure WebAssembly (Wasm) module. This Wasm module encapsulates the decision logic for the "condition" (e.g., Rev(profile) > P(mp) + C + Mar) and anonymized, encrypted profile attributes. This module, rather than a traditional cookie, is transferred to the electronic visitor's browser when they interact with the first media property. When the visitor subsequently accesses a second media property, the Wasm module executes client-side, communicating directly with the second media property's ad rendering engine (or a local proxy) to evaluate the condition and signal whether an ad correlated with the encrypted profile should be displayed, without transmitting raw profile data back to the BT company or the second media property server. Decryption keys for specific ad campaigns are securely provisioned to authorized rendering engines or through a trusted execution environment on the client.

sequenceDiagram
    participant V as Visitor Browser
    participant FMP as First Media Property
    participant BTC as BT Company System
    participant SMP as Second Media Property

    V->>FMP: Access First Media Property
    FMP->>BTC: Profile Data Collected (via JS/Pixel)
    BTC->>V: Send Encrypted Wasm Module + Profile (Secure Channel)
    Note over V,BTC: Wasm module contains condition logic and encrypted profile.
    V->>SMP: Access Second Media Property
    V->>V: Execute Wasm Module
    V->>SMP: Wasm Module Evaluates Condition (e.g., profit positive) and Signals Ad Request
    SMP->>BTC: Request Correlated Ad (with Wasm-generated signal, no raw profile)
    BTC->>SMP: Deliver Correlated Ad
    SMP->>V: Display Ad

Derivative 1.2: Homomorphic Encryption for Profile Attributes

Enabling Description: The profile attributes collected from the first media property are immediately homomorphically encrypted by the BT company's system. The "indicia of a condition" directed to the third-party server on the second media property consists of these encrypted profile attributes along with an encrypted representation of the profit threshold or time limit. The third-party server, without decrypting the sensitive profile data, can perform computations (e.g., comparing encrypted ad space cost with encrypted expected revenue) on the homomorphically encrypted values to determine if the condition is met. The ad selection process for correlation can also operate on the encrypted profile attributes using specialized privacy-preserving matching algorithms, ensuring that no party other than the original data collector (BT company) or an authorized, secure enclave ever sees the plaintext profile.

flowchart TD
    subgraph BT Company System
        A[Collect Profile] --> B{Encrypt Profile (Homomorphic)}
        B --> C{Encrypt Condition Logic (e.g., Profit Formula)}
    end

    subgraph Third-Party Server (Second Media Property)
        D{Receive Encrypted Profile + Condition}
        C --> D
        D --> E{Perform Encrypted Computation (on condition)}
        E -- Condition Met --> F[Request Encrypted Ad Match]
        E -- Condition Not Met --> G[Display Default Content]
    end

    subgraph Ad Server
        H[Receive Encrypted Ad Match Request]
        F --> H
        H --> I{Match Encrypted Ad with Encrypted Profile}
        I --> J[Deliver Encrypted Ad]
    end

    J --> K[Client Decrypts and Displays Ad];

2. Operational Parameter Expansion

Derivative 2.1: Ultra-High Frequency Real-Time Bidding (RTB) Integration

Enabling Description: The method is expanded to operate within an ultra-high frequency Real-Time Bidding (RTB) exchange. The "indicia of a condition" includes a dynamic bid price and latency requirement (e.g., sub-50ms response time) associated with a highly granular, short-lived profile attribute (e.g., "user just scrolled past product X at price Y"). The BT company's computer system, employing FPGA-accelerated or GPU-accelerated micro-services, constantly re-evaluates profit based on real-time market data from the RTB exchange and instantly updates the bid and condition for millions of ad impressions per second. This necessitates extremely low-latency profile attribute processing and condition evaluation, with results pre-cached or delivered via low-latency protocols like gRPC to the third-party server (Demand-Side Platform or Supply-Side Platform).

flowchart TD
    subgraph BT Company System (Ultra-Low Latency)
        A[Real-time Profile Stream] --> B(FPGA/GPU Accelerator: Condition Engine)
        B --> C{Dynamic Bid Price + Latency Requirement}
    end

    subgraph RTB Exchange
        D[Bid Request Stream (Millions/sec)] --> E{Evaluate Bids & Conditions}
        C --> E
        E -- Condition Met & Bid Won --> F[Signal Ad Delivery]
        E -- Condition Not Met / Bid Lost --> G[No Ad Delivery]
    end

    subgraph Third-Party Server (Ad Server)
        F --> H[Prepare & Serve Ad]
        H --> I[Display Ad to Visitor]
    end

Derivative 2.2: Long-Term Predictive Profile Modeling for Campaign Planning

Enabling Description: The BT company's computer system utilizes advanced machine learning models (e.g., recurrent neural networks or transformer models) trained on historical, anonymized visitor behavior data to predict long-term (e.g., 6-12 months) profile attribute evolution and associated expected profits. The "indicia of a condition" communicated to third-party media property servers now includes a "predicted long-term value" score and a campaign start/end date range. This allows for proactive media buying and budget allocation for future campaigns, where the condition for display of an advertisement is not immediate profitability but rather alignment with a projected future high-value profile segment. This operates at a much lower frequency (e.g., weekly or monthly updates) compared to real-time targeting.

graph TD
    A[Historical Profile Data] --> B(ML Model Training - Predictive Analytics)
    B --> C{Predictive Profile Attributes & Long-Term Profit}
    C --> D[Generate Long-Term Condition Indicia (e.g., LTV Score, Campaign Dates)]
    D --> E[Third-Party Server (Media Planner/Ad Server)]
    E --> F[Allocate Ad Inventory for Future Campaigns]
    F --> G[Display Ads to Matched Future Profiles]

3. Cross-Domain Application

Derivative 3.1: Personalized Medical Intervention Reminders in Digital Health

Enabling Description: In a digital health context, the "first media property" is a patient portal or telehealth platform where a visitor's health profile (e.g., medication adherence, recent lab results, chronic condition status) is collected. The BT company's system (here, a healthcare analytics platform) generates "indicia of a condition" (e.g., "patient requires medication reminder," "patient due for follow-up") based on this profile and medical guidelines. This indicia is directed to a third-party server controlling "advertising space" on a "second media property" such as a smart medication dispenser app, a smart display in a clinic waiting room, or a smart wearable device. The "advertisement" is a personalized, context-sensitive health intervention reminder or educational content, displayed only if the condition (e.g., critical adherence gap, next appointment within 24 hours, insurance coverage for specific wellness program) is met.

flowchart TD
    A[Patient Portal / Telehealth (First Media Property)] --> B(Health Analytics Platform - BT Company System)
    B -- Collects Health Profile (Medication, Labs) --> B
    B -- Generates Condition Indicia (e.g., Reminder_Needed, FollowUp_Due) --> C[Third-Party Server (Smart Health Device Mgmt)]
    C --> D[Smart Medication Dispenser App (Second Media Property)]
    C --> E[Clinic Smart Display (Second Media Property)]
    C --> F[Smart Wearable (Second Media Property)]
    D & E & F -- Condition Met --> G[Display Personalized Health Reminder/Content]

Derivative 3.2: Dynamic Public Service Announcements (PSAs) in Smart Cities

Enabling Description: In a smart city environment, the "first media property" is an aggregated, anonymized data stream from urban IoT sensors (e.g., traffic flow, air quality monitors, public transport usage, event attendance). The BT company's system (a city management platform) collects this anonymized "profile information" about the city's status and citizen movements. It then directs "indicia of a condition" (e.g., "congestion alert needed for sector A," "air quality advisory for vulnerable groups," "event capacity nearing limit") to third-party servers controlling "advertising space" on "second media properties" like smart public billboards, digital signage on public transport, or in-app notifications from municipal apps. The "advertisement" is a dynamic PSA or targeted commercial message, displayed only if the derived city condition and target audience profile (e.g., commuters in sector A, residents with respiratory issues) are met.

graph LR
    A[Urban IoT Sensors (Traffic, Air Quality) - First Media Property] --> B(City Management Platform - BT Company System)
    B -- Aggregates Anonymized City Profile --> B
    B -- Generates Condition Indicia (e.g., Congestion_Alert, AQ_Advisory) --> C[Third-Party Server (Digital Signage Network)]
    C --> D[Smart Public Billboards (Second Media Property)]
    C --> E[Public Transport Screens (Second Media Property)]
    C --> F[Municipal Mobile App (Second Media Property)]
    D & E & F -- Condition Met --> G[Display Dynamic PSA/Targeted Message]

Derivative 3.3: Predictive Maintenance Alerts in Industrial IoT

Enabling Description: In an Industrial IoT setting, the "first media property" is a Supervisory Control and Data Acquisition (SCADA) system or a Manufacturing Execution System (MES) collecting real-time operational data (e.g., vibration levels, temperature, throughput) from industrial machinery. The BT company's system (a predictive maintenance platform) collects this equipment "profile information." It then directs "indicia of a condition" (e.g., "Machine X failure probability > 80% in 24h," "Operator Y requires training on new protocol") to a third-party server controlling "advertising space" on "second media properties" such as operator HMI panels, augmented reality (AR) headsets worn by technicians, or industrial smart displays. The "advertisement" is a critical maintenance alert, a specific troubleshooting guide, or an urgent training module, displayed only if the condition (e.g., predictive failure threshold exceeded, safety protocol update) is met, correlated with the specific machine's profile or operator's skill profile.

flowchart TD
    A[SCADA/MES (Machine Data) - First Media Property] --> B(Predictive Maintenance Platform - BT Company System)
    B -- Collects Equipment Profile (Vibration, Temp) --> B
    B -- Generates Condition Indicia (e.g., High_Failure_Risk, Training_Required) --> C[Third-Party Server (Industrial Display Mgmt)]
    C --> D[Operator HMI Panel (Second Media Property)]
    C --> E[AR Headset Display (Second Media Property)]
    C --> F[Industrial Smart Display (Second Media Property)]
    D & E & F -- Condition Met --> G[Display Maintenance Alert/Training Module]

4. Integration with Emerging Tech

Derivative 4.1: AI-Driven Reinforcement Learning for Profit Optimization

Enabling Description: The BT company's computer system incorporates a reinforcement learning (RL) agent that continuously learns and adapts the "indicia of a condition," specifically the dynamic pricing models (P(mp)) and profit margins (Mar), for each unique profile attribute and media property combination. The RL agent receives real-time feedback on ad performance (e.g., click-through rates, conversion rates, actual revenue generated) as its "reward signal." It dynamically adjusts the parameters of the condition (e.g., optimal bid price, impression frequency caps, time-to-live for profiles) to maximize long-term expected profit across the entire ad inventory, even for rare or transient profile attributes. The "indicia of a condition" directed to the third-party server then becomes a sophisticated policy derived from the RL agent's current model.

graph TD
    A[Visitor to First Media Property] --> B(Profile Data Collection)
    B --> C{Reinforcement Learning Agent (BT Company System)}
    C -- Real-time Ad Performance Feedback --> C
    C -- Policy Update (Optimal Bid, Frequency, TTL) --> D[Generate Condition Indicia]
    D --> E[Third-Party Server (Second Media Property)]
    E -- Condition Met --> F[Display Correlated Ad]
    F --> G[Ad Performance (Reward Signal)]
    G --> C

Derivative 4.2: IoT Sensor-Triggered Edge Ad Delivery

Enabling Description: The "first media property" is an IoT sensor network (e.g., smart retail store beacons, smart home hubs) that collects granular, real-time contextual and behavioral "profile attributes" (e.g., visitor proximity to a product, gaze duration, spoken keywords detected locally via privacy-preserving acoustic analysis). An edge computing device (e.g., a mini-PC in the store, a smart TV with local processing capabilities) acts as the "BT company system." It processes these real-time attributes, calculates expected profit, and directly transmits "indicia of a condition" (e.g., "display discount for item X for visitor ID 123 for next 30 seconds") to local "second media properties" such as in-store digital signage, smart mirror displays, or the visitor's connected mobile device. All processing and condition evaluation happen at the edge, minimizing latency and enhancing privacy by avoiding centralized data transfer.

flowchart LR
    A[IoT Sensors (Beacons, Cameras, Mics) - First Media Property] --> B(Edge Computing Device - BT Company System)
    B -- Real-time Contextual Profile --> B
    B -- Calculates Profit & Generates Indicia --> C[Local Digital Signage (Second Media Property)]
    B --> D[Smart Mirror Display (Second Media Property)]
    B --> E[Visitor Mobile App (Second Media Property)]
    C & D & E -- Condition Met --> F[Display Hyper-Targeted Ad]

Derivative 4.3: Blockchain-Verified Consent and Condition Enforcement

Enabling Description: The consent for collecting profile attributes and for subsequent ad delivery is managed via a decentralized identity (DID) system and recorded on a blockchain. When an electronic visitor interacts with the "first media property," their profile attributes are pseudonymized and cryptographically linked to their DID. The "indicia of a condition" (e.g., profit threshold, time limit, data usage policy) is encoded as a smart contract on a permissioned blockchain. The BT company's system, when directing this indicia to the third-party server, includes a transaction hash referencing the active smart contract. The third-party server verifies the condition by querying the blockchain and executing the smart contract, which ensures that ad delivery adheres to the visitor's expressed consent and the predefined terms, providing auditable transparency for all parties.

sequenceDiagram
    participant V as Visitor
    participant FMP as First Media Property
    participant BTC as BT Company System
    participant TPS as Third-Party Server (Second Media Property)
    participant BC as Blockchain

    V->>FMP: Access FMP
    FMP->>BTC: Collect Profile (Pseudonymized)
    V->>BC: Record Consent (DID + Profile Access Policy)
    BTC->>BC: Deploy/Update Smart Contract (Condition Logic)
    BTC->>TPS: Direct Indicia of Condition (Smart Contract Ref, Encrypted Profile)
    TPS->>BC: Verify Condition (Execute Smart Contract, Check Consent)
    alt Condition Met
        TPS->>BTC: Request Correlated Ad
        BTC->>TPS: Deliver Correlated Ad
        TPS->>V: Display Ad
    else Condition Not Met
        TPS->>V: Display Default Content
    end

5. The "Inverse" or Failure Mode

Derivative 5.1: Privacy-by-Default/Low-Power Anonymized Ad Delivery

Enabling Description: The system is designed with a "privacy-by-default" mode. If explicit, opt-in consent for profile-based targeting is not received from the electronic visitor, or if the visitor's device signals a low-power state (e.g., battery < 10%), the BT company's system automatically switches to a limited-functionality mode. In this mode, the "indicia of a condition" directed to the third-party server will specifically instruct to only display anonymized, contextual advertisements (e.g., based on the current page content rather than user profile) or public service announcements. The profit calculation in this mode defaults to a minimum threshold (potentially zero or negative, if displaying PSAs has a cost for the BT company), preventing expensive profile-based ad delivery when privacy preferences or resource constraints dictate a different approach. The tag placed on the visitor (if any) would be a generic "context-only" identifier.

stateDiagram
    [*] --> InitialState
    InitialState --> ProfileCollected: Profile Collected
    ProfileCollected --> EvaluateConsent:
    EvaluateConsent --> ConsentOptedIn: User Opts In
    EvaluateConsent --> ConsentNotOptedIn: User Opts Out / No Consent

    ConsentOptedIn --> DevicePowerCheck:
    DevicePowerCheck --> DeviceHighPower: Device > 10% Battery
    DevicePowerCheck --> DeviceLowPower: Device <= 10% Battery

    DeviceHighPower --> ProfitOptimizedAd: Condition = Maximize Profit
    DeviceLowPower --> AnonymizedAd: Condition = Anonymized/Contextual (Low Power)
    ConsentNotOptedIn --> AnonymizedAd: Condition = Anonymized/Contextual (Privacy Default)

    ProfitOptimizedAd --> AdDisplayed: Profile-Based Ad
    AnonymizedAd --> AdDisplayed: Contextual/PSA Ad

    AdDisplayed --> [*]

Derivative 5.2: Data Integrity Failure Mode (Default to No Ad)

Enabling Description: The BT company's computer system implements continuous data integrity checks (e.g., checksums, cryptographic hashes, anomaly detection on profile data streams). If a data integrity anomaly is detected in the collected profile attributes (e.g., corrupted data, suspicious manipulation, or an attempt to inject malicious profile data), or if the profit calculation module encounters an error (e.g., division by zero, database connection failure, unexpected negative revenue prediction), the system enters a "safe-failure" mode. In this mode, the "indicia of a condition" directed to the third-party server will explicitly convey a "no ad delivery" instruction or a fallback to a default, non-commercial message (e.g., an "error" placeholder or a generic site banner), ensuring that no ad correlated with potentially compromised or erroneous profile information is ever displayed. This prioritizes system stability and user experience over revenue generation in failure scenarios.

flowchart TD
    A[Collect Profile Data] --> B{Data Integrity Check};
    B -- OK --> C{Calculate Expected Profit};
    B -- Integrity Fail --> F[Safe-Failure: No Ad Indicia];

    C -- Profit OK --> D[Generate Condition Indicia (Profit-Based)];
    C -- Calculation Error --> F;

    D --> E[Direct Indicia to Third-Party Server];
    F --> E;

    E --> G{Third-Party Server: Evaluate Indicia};
    G -- Ad Indicia --> H[Display Correlated Ad];
    G -- No Ad Indicia --> I[Display Default Content / Blank Space];

Combination Prior Art Scenarios with Open-Source Standards

These scenarios illustrate how the core concepts of US8959146 can be combined with existing open-source standards to create prior art.

1. Integration with OpenRTB (Open Real-Time Bidding) Protocol

Scenario Description: The method of US8959146, particularly the calculation of expected profit for media property selection, is implemented within a programmatic advertising ecosystem leveraging the OpenRTB (Open Real-Time Bidding) protocol (e.g., version 2.5). The BT company's system acts as a Demand-Side Platform (DSP) or integrates with one. When a Supply-Side Platform (SSP) sends an OpenRTB Bid Request (containing details about the ad impression, user, and context) to the DSP, the DSP (BT company's system) uses its profile information (collected from the first media property) and the profit calculation method to determine a bid price (bidfloor) and a set of bcat (blocked categories) or badv (blocked advertisers) for that specific impression. This bid response, containing the "indicia of a condition" (i.e., the specific bid price, allowed categories, and expiration time), is then directed to the SSP (third-party server) within the OpenRTB framework for display on the second media property. The ext (extensions) field in OpenRTB can carry proprietary "condition" parameters like a calculated profit margin or a profile confidence score.

2. Integration with IAB Transparency and Consent Framework (TCF)

Scenario Description: The mechanisms for collecting profile attributes from a first media property and arranging for tagging (as described in US8959146) are explicitly designed to be compliant with the IAB Transparency and Consent Framework (TCF) (e.g., TCF 2.2). When a visitor lands on the first media property, the Consent Management Platform (CMP) presents a TCF-compliant consent dialog. The BT company's system receives the visitor's TC String (Transparency and Consent String) along with their profile attributes. The "indicia of a condition" sent to the third-party server (which might also be a vendor registered with TCF) includes the visitor's TC String. This TC String serves as a critical part of the "condition" for ad display; the third-party server must verify that the visitor's consent preferences within the TC String permit the specific type of profile-based ad delivery intended by the BT company before displaying the correlated advertisement. This ensures that profit-driven ad selection respects user privacy choices as communicated through a standardized consent mechanism.

3. Integration with W3C Privacy Sandbox APIs (e.g., Protected Audience API)

Scenario Description: The method of US8959146 is adapted to operate within a browser environment implementing the W3C Privacy Sandbox, specifically the Protected Audience API (formerly FLEDGE). When an electronic visitor accesses a first media property, the BT company's system (as an "Ad Buyer" or "Interest Group Owner") uses the browser's Protected Audience API to add the visitor to an "interest group" based on their profile attributes (e.g., "searched for mortgage"). The "indicia of a condition" for displaying an advertisement on a second media property is encapsulated within the bid and bid-logic functions of the interest group, which are executed locally within the browser's trusted execution environment during an on-device auction. The "profit calculation" (e.g., Rev(profile) - P(mp) - C - Mar) is now part of the generateBid() logic, where P(mp) is the publisher's expected revenue and Rev(profile) is the ad buyer's expected revenue for that user, both evaluated client-side. The browser (acting as the "third-party server" in this context) performs the auction and displays the ad correlated with the interest group if the bid wins and the profit-based condition is met, without exposing the raw profile or bidding logic to external servers.