Derivative works

Defensive Disclosure: Information Messaging Systems and Methods

Publication Date: May 12, 2026
Reference Patent: US 9,531,665
Keywords: Consent-based messaging, sequential advertising, triggered notifications, decentralized consent, federated messaging, cross-domain data triggers, AI-driven marketing, IoT-to-human messaging.

This document discloses a series of technical implementations, systems, and methods derived from the core concept of triggering a message from a second entity based on a user's affirmative acceptance of a message from a first entity. These disclosures are intended to enter the public domain as prior art.

---

Derivative Set 1: Component & Protocol Substitution

1.1. Decentralized Consent Ledger using Distributed Hash Tables (DHT)

• Enabling Description: This variation replaces the central server and its database with a peer-to-peer network for managing and verifying user consent. When a user accepts a message from Vendor A, the mobile application (acting as a node) creates a cryptographically signed consent record. This record contains the user's public key, Vendor A's identifier, Vendor B's identifier, and a timestamp. The record is then stored on a Distributed Hash Table (DHT), like the one used in IPFS/libp2p, addressable by a key derived from the user's identifier and Vendor A. Vendor B's messaging service, also a node in the network, can query the DHT using the known key to verify consent before dispatching its message. This removes the single point of failure and control of the central server.

• Diagram:

  sequenceDiagram
      participant UserApp as User Application (Node)
      participant VendorA as Vendor A Service
      participant DHT as P2P DHT Network
      participant VendorB as Vendor B Service (Node)
  
      UserApp->>VendorA: Request/Interact with content
      VendorA-->>UserApp: Delivers Message/Offer 1
      UserApp->>UserApp: User accepts Message 1
      UserApp->>DHT: Publishes Signed Consent Record
      note over UserApp, DHT: Record: {user_pubkey, vendor_A_id, vendor_B_id, timestamp, signature}
      VendorB->>DHT: Queries for Consent Record by key(user_id, vendor_A_id)
      DHT-->>VendorB: Returns Signed Consent Record
      VendorB->>VendorB: Verifies Signature
      VendorB->>UserApp: Sends Message 2 (Post-Verification)
  

1.2. Rich Communication Services (RCS) with Chatbot-Managed Consent

• Enabling Description: This implementation leverages the RCS protocol instead of SMS or proprietary push notifications. Vendor A initiates contact via an RCS chatbot. The user's "acceptance" is a structured interaction with the chatbot (e.g., tapping a "Yes, I agree" button). Upon acceptance, the chatbot for Vendor A makes a secure API call to a central consent-broker service. This service then instructs the RCS chatbot of Vendor B to initiate a new conversation with the user, delivering the second message. The entire flow occurs within the native messaging app, utilizing RCS's rich media and standardized event handling capabilities.

• Diagram:

  graph TD
      A[User's Native Messaging App] -- RCS Protocol --> B(Vendor A Chatbot);
      B -- Presents Offer 1 --> A;
      A -- User Taps 'Accept' Button --> B;
      B -- "Acceptance Event" --> C{Consent Broker API};
      C -- Validates & Logs Consent --> C;
      C -- Trigger Message 2 --> D(Vendor B Chatbot);
      D -- Initiates New RCS Conversation --> A;
  

---

Derivative Set 2: Operational Parameter Expansion

2.1. Microsecond Consent-Trigger for High-Frequency Trading (HFT)

• Enabling Description: The system is implemented for algorithmic trading. A trading algorithm's "acceptance" of a data packet from a primary market data feed (Vendor A, e.g., NYSE Direct Feed) is defined as executing a trade based on that packet's data. This execution event, logged in a low-latency messaging bus like Aeron or Kafka, triggers the system to subscribe the algorithm to a correlated, but competing, data feed (Vendor B, e.g., a dark pool's pricing feed) for a short, predefined window (e.g., 500 milliseconds) to seek arbitrage opportunities. The entire process from acceptance to the second subscription must occur in the sub-millisecond timeframe.

• Diagram:

  stateDiagram-v2
      [*] --> Inactive
      Inactive --> Subscribed_To_A: Receive Market Data (Vendor A)
      Subscribed_To_A --> Subscribed_To_A: Processing Data
      Subscribed_To_A --> Triggered: Execute Trade Based on Data A
      Triggered --> Subscribed_To_B: Subscribe to Feed (Vendor B)
      Subscribed_To_B --> Subscribed_To_B: Processing Data A & B
      Subscribed_To_B --> Inactive: TTL (500ms) Expires
      Triggered --> Inactive: No Trade Executed
  

2.2. Low-Bandwidth, High-Latency System for Mesh Networks

• Enabling Description: This variation is designed for disaster-response or battlefield IoT mesh networks using protocols like LoRaWAN or other delay-tolerant networking (DTN) standards. The "first message" is a high-priority status request from a central command node (Vendor A). A field unit's "acceptance" is its successful transmission of a response packet. Due to the unreliable network, this acceptance might take minutes or hours to propagate. Upon receipt at any listening node, the acceptance acts as a trigger for a secondary node (Vendor B, e.g., a supply drone) to queue a mission-critical message (e.g., "resupply coordinates") for delivery to the field unit on its next DTN routing opportunity.

• Diagram:

  flowchart LR
      subgraph FieldUnit
          A[Receive Status Request from A] --> B{Transmit Response};
      end
      subgraph MeshNetwork
          B --> C[Nodes Propagate Response];
      end
      subgraph SupplyDrone_NodeB
          C -- Response Received --> D[Queue Resupply Message];
          D --> E(Transmit to Field Unit on Next Connection);
      end
      style FieldUnit fill:#f9f,stroke:#333,stroke-width:2px
      style SupplyDrone_NodeB fill:#ccf,stroke:#333,stroke-width:2px
  

---

Derivative Set 3: Cross-Domain Applications

3.1. Aerospace: Dissimilar Avionics System Cross-Verification

• Enabling Description: In a glass cockpit, a pilot's "acceptance" of a critical flight parameter update from the primary Flight Management System (FMS, Vendor A), entered via the CDU, triggers an automated cross-check message. The FMS sends the newly accepted parameter (e.g., a final approach fix altitude) to a dissimilar secondary system, such as an Integrated Standby Instrument System (ISIS, Vendor B). The ISIS then runs its own calculation and sends a message back to the primary flight display indicating "AGREE" or "DISAGREE," providing immediate, automated verification from a redundant source.

• Diagram:

  sequenceDiagram
      participant Pilot
      participant PFD as Primary Flight Display
      participant FMS as FMS (Vendor A)
      participant ISIS as ISIS (Vendor B)
  
      Pilot->>FMS: Enters Altitude Update
      FMS-->>PFD: Displays Pending Update
      Pilot->>FMS: Executes/Accepts Update
      FMS->>ISIS: Send Accepted Parameter for Verification
      ISIS->>ISIS: Perform Independent Calculation
      ISIS-->>PFD: Display "AGREE" or "DISAGREE" status
  

3.2. Agriculture Technology (AgTech): Integrated Pest and Weather Management

• Enabling Description: A farmer receives a message from their soil analytics provider (Vendor A) recommending the application of a specific nitrogen-based pesticide. The farmer "accepts" this recommendation by placing an order for the pesticide through Vendor A's platform. This order event triggers a message to a hyper-local weather forecasting service (Vendor B). Vendor B's service, now aware of the impending application, sends a secondary alert to the farmer with a 72-hour forecast specifically detailing conditions (wind speed, temperature inversions, precipitation) that would violate the pesticide's application guidelines, preventing spray drift and runoff.

• Diagram:

  erDiagram
      FARMER ||--o{ ACCEPTS : Recommendation
      ACCEPTS {
          string eventId PK
          datetime timestamp
      }
      RECOMMENDATION ||--|{ ACCEPTS
      RECOMMENDATION {
          string pesticideType
      }
      SOIL_ANALYTICS_A ||--|{ RECOMMENDATION
      SOIL_ANALYTICS_A {
          string vendorId PK
      }
      ACCEPTS }o--|| TRIGGERS : Alert
      TRIGGERS {
          string forecastType
      }
      WEATHER_SERVICE_B ||--|{ TRIGGERS
      WEATHER_SERVICE_B {
          string vendorId PK
      }
  

---

Derivative Set 4: Integration with Emerging Technologies

4.1. AI-Optimized Second Vendor Selection

• Enabling Description: The server does not have a hardcoded rule for selecting the second vendor. When a user accepts a message from Vendor A, the server feeds a data payload (user's anonymized profile, Vendor A's category, time of day, geolocation) into a trained reinforcement learning model. The model's action space consists of all potential second vendors. The model selects the vendor (the "action") that maximizes the predicted reward, which is a combination of predicted user conversion probability and the bid price offered by the second vendor for the lead. The system continuously retrains the model based on the actual outcomes of the second messages.

• Diagram:

  flowchart TD
      A[User Accepts Message from Vendor A] --> B{Server Receives Acceptance};
      B --> C[Construct Feature Vector: {user_profile, vendor_A_info, context}];
      C --> D{RL Model};
      D -- Predicts Optimal Action --> E[Select Vendor B from Pool];
      E --> F[Send Message from Selected Vendor B];
      F --> G[Track Outcome: Conversion/Dismissal];
      G --> H(Update RL Model Weights);
      H --> D;
  

4.2. Blockchain-Verified Consent via Smart Contract

• Enabling Description: The system is built on a permissioned blockchain (e.g., Hyperledger Fabric). Vendors and users are participants. Consent is managed by a smart contract. When a user accepts Vendor A's offer, their mobile app calls the grantConsent function on the smart contract, passing Vendor A and Vendor B's identifiers. The smart contract logs this consent on the ledger immutably. A service run by Vendor B listens for ConsentGranted events emitted by the smart contract. Upon hearing an event relevant to it, Vendor B's service is authorized to send its message, with the blockchain transaction ID serving as an auditable proof of prior consent.

• Diagram:

  classDiagram
      class SmartContract {
          +mapping(address => Consent) consents
          +grantConsent(vendorA_id, vendorB_id)
          +revokeConsent(vendorA_id, vendorB_id)
          +verifyConsent(user, vendorB_id) bool
      }
      class UserApp {
          +wallet_address
          +callGrantConsent()
      }
      class VendorB_Service {
          +listenForConsentEvents()
          +sendMessage()
      }
      UserApp --> SmartContract : calls
      VendorB_Service --> SmartContract : listens to events
  

---

Derivative Set 5: The "Inverse" or Failure Mode

5.1. Privacy-Preserving Trigger with Zero-Knowledge Proof

• Enabling Description: This variant ensures Vendor B can be triggered without knowing which Vendor A generated the consent, protecting commercial relationships. When User accepts Vendor A's message, the server generates a consent token. The server then generates a zero-knowledge proof (ZKP) that it holds a valid consent token for the user that matches a policy defined by Vendor B (e.g., "user consented to a message from the 'automotive' category"), without revealing the token itself or Vendor A's identity. Vendor B's system receives the trigger request along with the ZKP. It verifies the proof and, if valid, sends its message, trusting the trigger's authenticity without needing to know the source.

• Diagram:

  sequenceDiagram
      participant User
      participant Server as Consent Broker
      participant VendorB
  
      User->>Server: Accepts message from Vendor A
      Server->>Server: Generates Consent Token & ZKP
      note right of Server: Proof asserts: "I have a valid<br/>token for this user matching<br/>Vendor B's policy."
      Server->>VendorB: Request Send + Zero-Knowledge Proof
      VendorB->>VendorB: Verifies Proof
      alt Proof is Valid
          VendorB->>User: Sends Message 2
      else Proof is Invalid
          VendorB->>Server: Rejects Request
      end
  

---

Combination Prior Art with Open-Source Standards

1. OAuth 2.0 Trigger Scopes: The user's "acceptance" is managed as an OAuth 2.0 consent flow. Vendor A's application requests a specific scope like trigger:vendor_b:message. When the user authenticates and approves, the authorization server (the system) issues an access token. Vendor A's backend then uses this token to make a single, authorized API call to an endpoint that dispatches Vendor B's message. This grounds the consent mechanism in a widely adopted, secure, and well-defined authorization framework.

2. CloudEvents for Decoupled Messaging: The acceptance event from Vendor A's system is packaged as a CNCF CloudEvent, a standard specification for describing event data. The event, containing source: vendor-a, type: com.vendor.a.consent.accepted, and subject: user_id, is published to a message broker (e.g., RabbitMQ, NATS). A separate microservice, acting as the trigger engine, subscribes to these events. It parses the CloudEvent and, based on its routing rules, constructs and emits a new CloudEvent (type: com.vendor.b.message.dispatch) directed to Vendor B's dispatch service. This creates a fully decoupled, event-driven architecture using open standards.

3. OpenID Connect (OIDC) Consent Claim: The consent action is stored as a custom claim within a user's identity token, managed by an OIDC provider like Keycloak. When the user accepts Vendor A's message, the OIDC provider is updated to add a claim to that user's profile, e.g., "accepted_vendors": ["vendor_a_id"]. Vendor B's application, which also uses the OIDC provider for authentication, can then request this claim as part of its authentication flow. Upon finding vendor_a_id in the user's token claims, it is authorized to send its follow-up message, tying the trigger directly to the user's federated identity and session.