Derivative works — US Patent 11610226

As a Senior Patent Strategist specializing in Defensive Publishing, I have analyzed US patent 11,610,226. The following document is a defensive disclosure of derivative works intended to establish prior art against future incremental inventions by competitors. This disclosure builds upon the core concepts claimed in the patent.

Defensive Disclosure: Derivative Variations of Condition-Based, Cross-Device Ad Delivery

I. Derivative Disclosures based on Material & Component Substitution

Derivative 1: Microservice & gRPC-Based Architecture

Enabling Description: The first and second computer systems are not monolithic applications but are implemented as a distributed network of microservices orchestrated using Kubernetes. Communication between the first entity's profile service and the second entity's ad-space controller does not use standard REST APIs. Instead, it utilizes gRPC (gRPC Remote Procedure Calls) for high-performance, low-latency communication. The "tag information" and "condition" are defined as protocol buffer messages. The first computer system exposes a .proto service definition that the second computer system implements as a client stub. This architecture allows for streaming of conditions and real-time updates, as opposed to a single request/response cycle. The behavioral profiles are stored in a sharded MongoDB cluster, enabling horizontal scalability for billions of user profiles.

Mermaid Diagram:

sequenceDiagram
    participant UserDevice1 as User Device 1 (Mobile App)
    participant ProfileSvc as Profile Microservice (System 1)
    participant PiiLinkSvc as PII-Linkage Microservice (System 1)
    participant UserDevice2 as User Device 2 (Smart TV)
    participant AdSpaceCtrl as Ad Space Controller (System 2)
    participant ConditionEvalSvc as Condition Evaluator (System 2)
    participant AdServer as Ad Server (System 1)

    UserDevice1->>+ProfileSvc: Stream behavioral events (product view, etc.)
    ProfileSvc->>+PiiLinkSvc: Request device linkage for User_XYZ
    PiiLinkSvc-->>-ProfileSvc: Return Device2_ID based on PII
    ProfileSvc->>AdSpaceCtrl: Establish gRPC stream, send TagInfo(Device2_ID)
    UserDevice2->>+AdSpaceCtrl: User starts video stream
    AdSpaceCtrl->>+ConditionEvalSvc: Initiate check for Device2_ID
    Note over AdSpaceCtrl,ConditionEvalSvc: Condition: video_genre=='sports' AND time < 2ms
    ConditionEvalSvc-->>-AdSpaceCtrl: Condition Met = TRUE
    AdSpaceCtrl->>+AdServer: gRPC Call: ServeAd(Profile_Ref_XYZ)
    AdServer-->>-UserDevice2: Stream VAST ad creative

Derivative 2: Graph Database for Profile Management & Decentralized Storage

Enabling Description: The first entity's computer system utilizes a graph database (e.g., Neo4j) to store user profiles. User actions, devices, and personally identifiable information are stored as nodes, with relationships (e.g., OWNS_DEVICE, VIEWED_CONTENT, HAS_EMAIL) represented as edges. This allows for complex, multi-dimensional relationship queries to identify a second device and infer interests. The actual behavioral profile information is not stored centrally. Instead, it is encrypted and stored as data fragments on a decentralized file system like the InterPlanetary File System (IPFS). The first computer system's database only stores the IPFS content identifiers (CIDs) and the decryption key, enhancing data security and user privacy. The "tag information" sent to the second system includes a one-time token that resolves to the relevant CIDs upon successful condition validation.

Mermaid Diagram:

erDiagram
    USER ||--o{ DEVICE : has
    USER ||--o{ PII : has
    USER ||--o{ ACTION : performed
    ACTION {
        string type
        datetime timestamp
        string content_CID "IPFS Content Identifier"
    }
    DEVICE {
        string device_id
        string type
    }
    PII {
        string email_hash
        string phone_hash
    }
    USER {
        string user_id
    }

II. Derivative Disclosures based on Operational Parameter Expansion

Derivative 3: Millisecond-Latency Real-Time Bidding (RTB) Implementation

Enabling Description: The invention is adapted for extreme low-latency environments typical of programmatic advertising auctions, where decisions must be made in under 100 milliseconds. The "condition" sent from the first computer system to the second is a pre-compiled WebAssembly (WASM) module. When the second computer system (an ad exchange) receives an ad request from a video player, it executes this WASM module in a sandboxed environment, passing real-time parameters (e.g., video content metadata, user location). The WASM module contains the logic to evaluate the condition and returns a binary true/false. This avoids the network latency of a round-trip API call to the first system for condition checking. If the result is true, the second system then calls the first system to retrieve the ad creative, having already confirmed the condition is met.

Mermaid Diagram:

flowchart TD
    subgraph System 1 (First Entity)
        A[Behavioral Profile DB] --> B{Generate Condition};
        B --> C[Compile to WebAssembly Module];
    end
    subgraph System 2 (Second Entity / Ad Exchange)
        E[Video Ad Request Received] --> F{Execute WASM Module w/ Request Data};
        F -- Condition Met --> G[Request Ad Creative from System 1];
        F -- Condition Not Met --> H[Run Auction for Other Ads];
        G --> I[Serve Ad in Video Stream];
    end
    C -- Deployed To --> F;

Derivative 4: Air-Gapped/High-Security Environment Application

Enabling Description: The method is applied within a high-security, air-gapped corporate or government network. "Device 1" is a user's primary workstation where their software usage and document access patterns are logged into a profile by a central monitoring system ("System 1"). "Device 2" is a secure, hardened terminal in a sensitive data room. Using the user's login credentials (PII), System 1 identifies the secure terminal as belonging to the user. System 1 sends "tag information" (user's security clearance hash) and a "condition" (e.g., "user must be accessing 'Project_Alpha' documents") to the terminal's local OS ("System 2"). This transfer happens via a secure, one-way data diode. If the user on the workstation (Device 1) accesses a document tagged 'Project_Alpha', and is logged into the secure terminal (Device 2), the condition is met, and System 1 is triggered to push a temporary, specific firewall rule or data access permission to the secure terminal's OS.

Mermaid Diagram:

sequenceDiagram
    actor User
    participant Workstation as Device 1
    participant MonitorSvc as System 1
    participant DataDiode
    participant SecureTerminal as Device 2 / System 2

    User->>Workstation: Accesses 'Project_Alpha' doc
    Workstation->>MonitorSvc: Log access event (behavioral profile)
    MonitorSvc->>DataDiode: Send Tag(User_Hash) & Condition('Project_Alpha')
    DataDiode->>SecureTerminal: Deliver payload
    User->>SecureTerminal: Logs in
    SecureTerminal->>SecureTerminal: Check local conditions: User_Hash matches AND 'Project_Alpha' condition received
    Note right of SecureTerminal: Condition Met
    SecureTerminal->>DataDiode: Send trigger signal (return path)
    DataDiode->>MonitorSvc: Relay trigger
    MonitorSvc->>DataDiode: Push temporary firewall rule
    DataDiode->>SecureTerminal: Apply rule

III. Derivative Disclosures based on Cross-Domain Application

Derivative 5: Aerospace - Predictive Maintenance

Enabling Description: A ground-based analytics platform ("System 1") records telemetry data from an aircraft engine during testing on a maintenance stand ("Device 1"), building a performance profile. Using the engine's unique serial number (a form of PII for the asset), System 1 identifies the specific aircraft ("Device 2") where the engine is installed. System 1 pre-emptively transfers "tag information" (the engine serial number) and a complex "condition" (a predictive model that outputs a failure probability based on in-flight sensor readings like EGT, vibration, and fuel flow) to the aircraft's onboard avionics computer ("System 2"). During flight, the avionics computer continuously feeds sensor data into the local model. If the predicted failure probability exceeds a pre-set threshold, the condition is met. The avionics computer then triggers a request to System 1 via a satellite link, causing System 1 to transmit a specific diagnostic software routine to the aircraft for execution.

Mermaid Diagram:

flowchart LR
    subgraph Ground (System 1)
        A[Engine Test Data] --> B[Build Performance Profile];
        B --> C[Generate Predictive Failure Model];
    end
    subgraph Aircraft (System 2)
        E[Onboard Avionics] --> F{Run Local Failure Model};
        G[Live Engine Sensors] --> F;
        F -- Prob > Threshold --> H[Signal Ground System via SatCom];
        H --> I[Receive & Run Diagnostic Routine];
    end
    C -- Uploaded to --> E;
    H --> J[Request Diagnostic from System 1];
    K[Diagnostic Routine] -- Sent to --> I;
    J --> K;

Derivative 6: AgTech - Autonomous Crop Treatment

Enabling Description: A cloud-based agricultural analytics platform ("System 1") collects data from a network of stationary soil sensors ("Device 1"), building a real-time hydration and nutrient profile for a field. Using the farm's management records and GPS data (PII for the plot), System 1 identifies an autonomous tractor/drone ("Device 2") assigned to that field. System 1 sends "tag information" (the specific plot ID) and a "condition" (e.g., "nitrogen level < 5 ppm AND soil moisture > 30%") to the drone's onboard control unit ("System 2"). The drone patrols the field. When its own GPS confirms it is in the tagged plot and its onboard sensors validate the condition, its control unit sends a confirmation back to System 1. This causes System 1 to serve a precise, variable-rate fertilizer application map to the drone for immediate execution.

Mermaid Diagram:

sequenceDiagram
    participant SoilSensors as Device 1
    participant AgPlatform as System 1
    participant Drone as Device 2 / System 2
    
    SoilSensors-->>AgPlatform: Stream soil data
    AgPlatform->>AgPlatform: Build nutrient profile for Plot_7
    AgPlatform->>Drone: Send Tag(Plot_7) & Condition(N < 5ppm)
    Drone->>Drone: Patrols to Plot_7 (verifies via GPS)
    Drone->>Drone: Onboard sensor confirms N < 5ppm
    Note right of Drone: Condition Met
    Drone->>AgPlatform: Request application map for Plot_7
    AgPlatform-->>Drone: Serve variable-rate fertilizer map
    Drone->>Drone: Execute fertilizer application

IV. Derivative Disclosures based on Integration with Emerging Tech

Derivative 7: AI-Driven Predictive Condition

Enabling Description: The "condition" is not a static rule but a machine learning model. The first computer system (System 1) trains a recurrent neural network (RNN) on the user's sequence of actions (the behavioral profile) to predict their next likely intent (e.g., "intent_to_purchase_travel"). System 1 serializes and transfers this trained model to the second computer system (System 2). System 2, which controls ad space in a video stream, feeds real-time contextual data (e.g., video genre, time of day, detected objects in the video frames) into the model. The "condition is met" if the model's output confidence score for a specific intent (e.g., 'purchase_travel') surpasses a dynamic threshold, which itself may be adjusted based on the advertiser's budget.

Mermaid Diagram:

stateDiagram-v2
    [*] --> Profiled: User behavior recorded
    Profiled --> ModelTrained: System 1 trains RNN on behavior sequence
    ModelTrained --> ModelDeployed: RNN model sent to System 2
    ModelDeployed --> Evaluating: User watches video on Device 2
    
    Evaluating --> AdTriggered: System 2 feeds video context to RNN, output > threshold
    Evaluating --> Idle: RNN output < threshold
    AdTriggered --> AdServed: System 1 serves ad
    AdServed --> [*]
    Idle --> Evaluating

Derivative 8: Blockchain for Consent and Transaction Verification

Enabling Description: The entire process is mediated by a private blockchain. The user's consent to have their devices linked and profile used is recorded as an immutable transaction. System 1 records the "tag information" and the "condition" in a smart contract. The smart contract holds advertiser funds in escrow. When System 2 (the video provider) determines the condition is met, it calls a function on the smart contract. The smart contract validates the call, triggers an event that notifies System 1 to serve the ad, and automatically releases payment from the advertiser's wallet to the video provider's wallet. This provides a decentralized, transparent, and auditable record of the entire ad transaction without a central clearinghouse.

Mermaid Diagram:

sequenceDiagram
    participant User
    participant System1
    participant System2
    participant SmartContract

    User->>SmartContract: GrantConsent() transaction
    System1->>SmartContract: CreateAdOpportunity(Tag, Condition, Escrow)
    System2->>System2: User watches video; condition is met
    System2->>SmartContract: ExecuteOpportunity(Tag)
    SmartContract->>System1: Emit AdServeRequest event
    SmartContract->>System2: TransferFunds() from escrow
    System1->>User: Serve Ad

V. Derivative Disclosures based on "Inverse" or Failure Mode

Derivative 9: Graceful Degradation to Contextual Targeting

Enabling Description: The invention includes a fail-safe or privacy-enhanced mode. If System 1's profile on the user is sparse, or if the user has opted for a high-privacy setting, System 1 does not create a detailed behavioral profile. Instead, it only determines a single, broad interest category from the user's action on Device 1. It then sends "tag information" that is a temporary, anonymized identifier, and a "condition" that is purely contextual (e.g., video.category == 'automotive'). System 2 checks only this contextual condition. If met, it causes System 1 to serve a generic, non-personalized ad related to that context. This provides a baseline functionality that operates when the primary behavioral targeting mechanism is unavailable or disabled, ensuring the ad space is still monetized.

Mermaid Diagram:

flowchart TD
    A{User Action on Device 1};
    A --> B{Check User Privacy Setting};
    B -- Full Opt-In --> C[Record Detailed Behavioral Profile];
    B -- Limited/Private --> D[Record Broad Contextual Category];
    C --> E[Send Behavioral Condition to System 2];
    D --> F[Send Contextual Condition to System 2];
    subgraph System 2
      G{Check Condition};
      E --> G;
      F --> G;
      G -- Met --> H[Trigger System 1];
    end
    H -- from E --> I[Serve Personalized Ad];
    H -- from F --> J[Serve Contextual Ad];

VI. Combination Prior Art Scenarios with Open-Source Standards

Combination 1: Integration with Prebid.js and User ID Modules

Description: The methodology of US patent 11,610,226 is implemented within the open-source Prebid.js header bidding framework. The first computer system (System 1) operates as a server-side bidding adapter. The "personally identifiable information" is resolved on the client-side (Device 1) by a Prebid User ID module (e.g., Unified ID 2.0, LiveRamp IDL). This identifier is passed in the bid request to the System 1 adapter. System 1 uses this ID to look up the behavioral profile. The "condition" is the bid price and ad creative rules. The second computer system (System 2) is the publisher's website running the Prebid.js auction. If System 1 wins the auction, Prebid.js "causes" System 1 to serve the ad by calling its provided render URL. This entire flow is standardized by the Prebid.js open-source project.

Combination 2: Compliance with IAB OpenRTB Protocol

Description: The communication protocol between the first and second computer systems is defined by the Interactive Advertising Bureau's (IAB) OpenRTB 2.5 (or later) specification. The second computer system (an Ad Exchange) sends a BidRequest to the first computer system (a Demand-Side Platform or DSP). The "tag information" is contained in the BidRequest.user.ext.eids array, following the standard for external user identifiers. The "behavioral profile information" is held by System 1 and is not transferred. The "condition" is implicitly defined by the parameters of the BidRequest.imp (impression) object, which specifies the ad slot size, video protocols (VAST), and content categories (bcat). System 1's decision to respond with a BidResponse signifies that the condition is met. The ad itself is served based on the adm field in the winning BidResponse.

Combination 3: User Identity via W3C Decentralized Identifiers (DIDs)

Description: The system is built to operate without relying on PII controlled by the first entity. Instead, user identity across devices is managed using the W3C's Decentralized Identifiers (DID) and Verifiable Credentials (VC) standards. A user controls their own DID. On Device 1, the user's browser (or a wallet application) provides a VC to System 1, proving control of the DID. System 1 associates the behavioral profile with this public DID. On Device 2 (e.g., a Smart TV application), the user authenticates with the same DID. System 2 receives the "tag information" (the user's DID) from the application. The "condition" check involves System 2 requesting a VC from the user's wallet to prove they are the same user and consent to the ad. If verified, System 2 triggers System 1, referencing the public DID to retrieve the appropriate ad. This architecture aligns the patent's mechanism with open standards for self-sovereign identity.