Derivative works — US Patent 10134054

Defensive Disclosure and Prior Art Generation for Privacy-Sensitive, Condition-Based Ad Serving Architectures

Publication Date: April 29, 2026
Subject Matter: Derivative works and extensions of the methods disclosed in U.S. Patent 10,134,054. This document is intended to enter the public domain as prior art.

Derivative Variation 1: Architectural & Protocol Substitution

Title: Real-Time, Persistent Channel Method for Conditional Ad Redirection

Enabling Description:
This variation replaces the stateless, HTTP-redirect-based communication flow of the core patent with a stateful, persistent connection architecture using WebSockets (RFC 6455) or gRPC.

Tagging: Upon a visitor's first interaction with the First Entity's system, a client-side script establishes a WebSocket connection to the First Entity's server. The server issues a signed JSON Web Token (JWT) to the client, which serves as the "tag" or session identifier. This JWT is stored in the browser's sessionStorage.
Condition Transfer: The First Entity determines the appropriate advertising "condition" (e.g., bid price, time validity) and sends this condition as a WebSocket message to the client. The client script then initiates a second WebSocket connection to the Second Entity's server, authenticates using its JWT tag, and forwards the condition.
Conditional Trigger: The Second Entity's server maintains the open WebSocket connection. When an ad opportunity arises on one of its controlled media properties, instead of a redirect, it sends a lightweight message over the WebSocket to the First Entity's server (via the client acting as a proxy, or directly if a server-to-server channel is established) containing contextual data.
Ad Serving: The First Entity's server validates that the condition is met and serves the ad creative payload directly back through its own WebSocket connection to the client for rendering, eliminating the need for a full-page HTTP redirect.

sequenceDiagram
    participant C as Visitor Device
    participant E1 as First Entity System
    participant E2 as Second Entity System

    C->>+E1: Establishes WebSocket Connection
    E1-->>-C: Returns Signed JWT (Tag)
    Note over C: Stores JWT in sessionStorage

    E1-->>C: Pushes Ad Condition (e.g., price)
    C->>+E2: Establishes WebSocket, sends JWT & Condition
    E2-->>-C: Acknowledges Condition

    loop Ad Opportunity on E2-controlled site
        E2-->>C: Ad Request (via WebSocket)
        C-->>E1: Forwards Ad Request
        E1->>E1: Check if Condition is Met
        E1-->>C: Serve Ad Creative (via WebSocket)
    end

Derivative Variation 2: Operational Parameter Expansion

Title: Edge-Computed, Multi-Factorial Condition Evaluation for Ultra-Low-Latency Ad Bidding

Enabling Description:
This variation adapts the core method for extreme-scale, real-time bidding (RTB) environments where decisions must be made in under 10 milliseconds.

Architecture: The First and Second Entities deploy their systems on a global edge computing network (e.g., Cloudflare Workers, AWS Lambda@Edge). User profiles are stored in a globally distributed, low-latency database (e.g., ScyllaDB, CockroachDB) with geo-partitioning to keep data close to the user.
Tagging: The tag is a standard cookie but contains a geo-routing hint.
Condition Definition: The "condition" is no longer a simple value but a structured data object (e.g., a Protocol Buffer) containing a multi-key-value map of bid parameters (max_cpm, allowed_categories, required_viewability_score, time_decay_factor).
Conditional Evaluation: When a user visits a media property, the request hits the Second Entity's nearest edge node. This node reads the tag and performs a local check against the complex condition object. The check may involve evaluating a small, pre-compiled WebAssembly (WASM) module provided by the First Entity as part of the condition itself.
Redirection: If the edge evaluation is successful, the redirection occurs directly between edge nodes, minimizing round-trip latency to a central server. The First Entity's edge node fetches the user profile from the nearest database replica and serves the ad.

flowchart TD
    subgraph User's Geographic Region
        A[User Device on Media Property] --> B{Second Entity Edge Node};
        B --> C{Read Tag & Geo-Hint};
        C --> D[Fetch Complex Condition from local cache];
        D --> E{Evaluate Condition via WASM module};
        E -- Condition Met --> F[Redirect to First Entity Edge Node];
        E -- Condition Not Met --> G[Serve Default Ad];
        F --> H[Fetch Profile from Geo-Partitioned DB];
        H --> I[Select & Serve Targeted Ad];
    end

Derivative Variation 3: Cross-Domain Application (Healthcare)

Title: Privacy-Preserving Patient Cohort Identification for Clinical Trials

Enabling Description:
This mechanism is applied to clinical trial recruitment, ensuring patient privacy in compliance with HIPAA.

Entities: The "First Entity" is a Hospital's Electronic Health Record (EHR) system. The "Second Entity" is a Pharmaceutical Sponsor's clinical trial management system.
Tagging: The EHR system generates a de-identified, single-use participant token for a patient who has consented to be considered for research. This token is the "tag". The Hospital provides this token to the Sponsor's system.
Condition: The "condition" is the set of complex inclusion/exclusion criteria for a specific clinical trial (e.g., disease_code=ICD-10 C61, age_between=[50,75], lab_result_creatinine_lt=1.5). This condition is electronically transferred from the Sponsor to the EHR system and associated with the token.
Conditional Check & Redirection: The EHR system internally runs the query (the condition) against the full patient record. This is a "pull" model, not a "push." If the patient matches, the system flags the token as "eligible." The "redirection" is an electronic notification sent back to the Sponsor's system indicating the token is eligible, without revealing why or any other patient data. The Sponsor can then request that the Hospital's clinical coordinator (a human) contact the eligible patient.

sequenceDiagram
    participant Sponsor as Pharma Sponsor System
    participant Hospital as Hospital EHR System
    participant Patient as Patient Record

    Sponsor->>+Hospital: Submits Clinical Trial Condition
    Hospital->>-Sponsor: Acknowledges Condition
    Hospital->>Hospital: Generates De-identified Tokens for consenting patients
    Hospital->>Patient: Associates Condition with Patient's Token

    loop Nightly Batch Process
        Hospital->>Patient: Run Condition query against full Patient Record
        alt Patient matches criteria
            Hospital->>Hospital: Flag Patient Token as 'Eligible'
        end
    end

    Sponsor->>+Hospital: Query status of submitted Tokens
    Hospital-->>-Sponsor: Return list of 'Eligible' Tokens
    Note right of Sponsor: Sponsor requests human-mediated contact for eligible tokens.

Derivative Variation 4: Cross-Domain Application (Industrial IoT)

Title: Conditional, Just-In-Time Data Access for Predictive Maintenance

Enabling Description:
This mechanism provides secure, temporary access to industrial sensor data for third-party analytics.

Entities: The "First Entity" is a factory's on-premise SCADA/historian system. The "Second Entity" is a cloud-based AI/ML predictive maintenance provider.
Tagging: The SCADA system "tags" a specific asset (e.g., a CNC mill, identified by a unique ID) by registering it with the AI provider's platform.
Condition: The "condition" is a set of operational thresholds defined in a configuration file (e.g., vibration_rms > 5g, spindle_temp > 85C, acoustic_anomaly_score > 0.9). This configuration is maintained by the SCADA system.
Conditional Check & Redirection: The SCADA system continuously monitors the asset. When a condition is met, it triggers an automated process. The "redirection" is the generation of a short-lived, single-use API access token (e.g., a scoped OAuth2 token) that grants the AI provider read-only access to a specific window of time-series data (e.g., 30 minutes pre-event, 5 minutes post-event) for only that specific asset. The SCADA system then calls a webhook on the AI provider's platform, passing this token. The provider uses the token to pull the necessary data for analysis and model inference.

stateDiagram-v2
    [*] --> Monitoring
    Monitoring: Asset operating within normal parameters

    state "Condition Met" as ConditionMet
    Monitoring --> ConditionMet: Vibration > 5g OR Temp > 85C

    ConditionMet --> GrantingAccess: Generate scoped, short-lived API token
    GrantingAccess --> AwaitingAnalysis: Call provider webhook with token
    AwaitingAnalysis --> [*]: Token expires or analysis complete

Derivative Variation 5: Integration with Emerging Tech (AI/ML)

Title: Deployable Machine Learning Model as a Dynamic Advertising Condition

Enabling Description:
The "condition" is a predictive model that the Second Entity executes locally.

Entities: First Entity (Profile Holder), Second Entity (Ad Network).
Model Generation: The First Entity uses its private user profile data to train a lightweight predictive model (e.g., a logistic regression model or a small gradient-boosted tree). The model predicts the probability of conversion (p(Conversion)) for a given user. The model is serialized into a portable format like ONNX or PFA (Portable Format for Analytics).
Tagging & Condition Transfer: The First Entity tags the user with a cookie. It then transfers the serialized model to the Second Entity and associates it with the tag. This model is the condition. The model does not contain any of the private data it was trained on, only its learned parameters (weights and biases).
Conditional Evaluation: When the tagged user visits a site, the Second Entity's server gathers its own, non-private contextual data (e.g., time of day, device type, site content category). It feeds this data into the provided model to compute a p(Conversion) score.
Redirection: If the computed score is above a threshold agreed upon by both parties (e.g., score > 0.75), the Second Entity performs the redirection back to the First Entity.

flowchart TD
    subgraph E1 [First Entity System]
        A[Private User Profile Data] --> B(Train p(Conversion) Model);
        B --> C[Serialize Model to ONNX];
    end

    subgraph E2 [Second Entity System]
        D[User on Media Property] --> E(Gather Contextual Data);
        F[Get Model associated with user tag];
        G(Execute Model);
        E --> G;
        F --> G;
        G --> H{p(Conversion) > Threshold?};
    end

    C -- Transfer Model (The Condition) --> F;
    H -- Yes --> I[Redirect to First Entity];
    H -- No --> J[Serve Other Ad];

Derivative Variation 6: Integration with Emerging Tech (Blockchain)

Title: Smart Contract-Mediated Auditing for Conditional Ad Serving

Enabling Description:
This variation uses a permissioned blockchain (e.g., Hyperledger Fabric) to create an immutable, auditable record of the privacy-preserving advertising transaction.

On-Chain Identities: Both the First Entity and Second Entity have registered identities on the blockchain.
Tagging & Condition Registration: When the First Entity tags a user, it initiates a smart contract transaction. The transaction records (anonymous_user_id, second_entity_id, condition_hash, timestamp). The condition_hash is a cryptographic hash (e.g., SHA-256) of the actual condition (e.g., hash("price_cpm < 2.50")), which is communicated off-chain.
Redirection & Verification: When the Second Entity's system determines the condition is met, it triggers a second smart contract function, attestRedirect(anonymous_user_id, off_chain_data_hash). The smart contract verifies that a registration event for that user and entity exists. If valid, it records the redirection event on the ledger.
Settlement: A third, "settlement" smart contract periodically runs, which tallies the verified redirection events between the two parties and automates the financial settlement process, ensuring payment only for valid, on-chain-attested ad calls.

sequenceDiagram
    participant E1 as First Entity
    participant E2 as Second Entity
    participant SC as Smart Contract

    E1->>SC: registerCondition(userID, E2_ID, conditionHash)
    Note over E1,E2: Condition sent off-chain

    loop User visits E2 site
        E2->>E2: Check off-chain condition
        alt Condition Met
            E2->>SC: attestRedirect(userID, contextHash)
            SC->>SC: Verify original registration
            SC-->>E2: Transaction Confirmed
            E2->>E1: Redirect user
        end
    end

Combination Prior Art Scenarios

Combination with OpenRTB: The architecture of US 10,134,054 is implemented within the IAB OpenRTB 3.0 framework. The First Entity acts as a "Demand Side Platform" (DSP) and the Second Entity as an "Ad Exchange." The BidRequest from the Exchange to the DSP includes a new extension object, BidRequest.ext.privacy_token, which is the "tag". The DSP's BidResponse contains a bid, but also a new BidResponse.seatbid.bid.ext.condition object, which passes the condition (e.g., a maximum clearing price) back to the Exchange. If the auction is won but the clearing price exceeds the condition, the Exchange uses a specific VAST redirect URL in the ad response that points back to the DSP, fulfilling the conditional redirection.
Combination with FIDO/WebAuthn: The "tagging" of a visitor's device is accomplished via the FIDO2/WebAuthn standard, treating the First Entity as a "Relying Party." When a user interacts, they are prompted for a passkey/biometric authentication. The resulting credential ID is shared with the Second Entity as the "tag." When an ad opportunity arises, the Second Entity initiates a FIDO assertion challenge. The user's browser signs the challenge and sends it to the First Entity for verification. The "condition" is checked by the First Entity as part of the assertion validation logic before it serves the ad, effectively merging the "redirection" and "ad serving" steps into a single, secure authentication flow.
Combination with OAuth 2.0: The entire flow is modeled using the OAuth 2.0 protocol. The First Entity is the Authorization Server, the Second Entity is the Client Application, and the user is the Resource Owner.
- Tagging: The Second Entity initiates an OAuth flow, redirecting the user to the First Entity.
- Condition: The Second Entity requests a custom scope, e.g., scope=ad-serve-cpm:2.50. This scope is the condition.
- Conditional Check: The user consents on the First Entity's server, which checks if it can fulfill the requested conditional scope.
- Redirection & Ad Serving: If the condition is acceptable, the First Entity redirects the user back to the Second Entity's redirect_uri with an authorization code. The Second Entity exchanges this code for an access token, which it then uses to request the ad creative from a resource endpoint on the First Entity's server.