Derivative works — US Patent 12118591

Defensive Disclosure Document for US Patent 12,118,591

Publication Date: May 13, 2026
Subject: Derivatives and obvious variations of methods, systems, and storage media for server-side generation and provision of multiple, distinct, ad-supported media feeds to mobile applications based on content expiration parameters. This document is intended to enter the public domain to be used as prior art.

Introduction

This document discloses a series of derivative inventions and technical variations based on the core concepts outlined in US Patent 12,118,591 ("the '591 patent"). The purpose is to preemptively place into the public domain a range of foreseeable and obvious modifications, extensions, and alternative applications of the patented technology. The disclosures herein are described in sufficient detail to enable a person ordinarily skilled in the art of server-side media delivery, mobile application architecture, and digital advertising to practice the inventions without undue experimentation.

The core concept of the '591 patent involves a server-side system that receives media messages with expiration data, selects subsets of these messages to form distinct media "feeds," associates advertisements with the messages in these feeds, and provides the feeds to a mobile application. The following disclosures expand upon this foundation.

Section 1: Derivatives of Independent Claim 1 (Method)

The following are derivative methods based on the teachings of Claim 1 of the '591 patent.

1.1. Material & Component Substitution

Derivative 1.1.1: In-Memory Database and Edge Computing for Feed Selection
- Enabling Description: The method is modified by substituting the persistent storage database (e.g., a hard drive-based SQL database) with a high-speed, in-memory data grid (e.g., Redis, Hazelcast) for storing the plurality of media messages and their associated expiration information. The selection process for the first and second subsets of media messages is offloaded from central servers to geographically distributed edge computing nodes. When a mobile application requests a feed, the request is routed to the nearest edge node, which queries its local in-memory cache of available media messages. This node performs the subset selection based on expiration data and user-specific criteria (e.g., location, viewing history), and assembles the feed in real-time. This substitution significantly reduces latency in feed delivery and enables dynamic, context-aware feed generation. The advertisement prompts are also cached at the edge and selected based on local relevance.
- Mermaid Diagram:
```
sequenceDiagram
    participant MobileApp as Mobile Application
    participant EdgeNode as Edge Computing Node
    participant CentralServer as Central Server
    participant InMemoryDB as In-Memory Data Grid

    MobileApp->>EdgeNode: Request Feed
    EdgeNode->>InMemoryDB: Query Available Media Messages
    InMemoryDB-->>EdgeNode: Return Messages + Expiration Data
    EdgeNode->>EdgeNode: Select Subset (Feed)
    EdgeNode->>EdgeNode: Associate Ads
    EdgeNode-->>MobileApp: Provide Feed
    CentralServer->>InMemoryDB: Periodically Update Media Messages
```
Derivative 1.1.2: GraphQL API for Feed Provisioning
- Enabling Description: The method of providing the first and second feeds to the mobile application is altered by replacing a traditional REST API with a GraphQL API endpoint. The mobile application, instead of requesting a predefined feed structure, sends a GraphQL query specifying the exact data fields it requires for presentation (e.g., message text, video URL, ad prompt type, expiration timestamp). The server-side resolver for this query performs the selection of the media message subset based on the expiration information and other parameters embedded in the query context. This allows the mobile application to control the data payload, reducing bandwidth consumption and improving performance on low-speed networks. The server provides a flexible schema defining available media message attributes and advertisement prompt formats.
- Mermaid Diagram:
```
graph TD
    A[Mobile Application] -- GraphQL Query --> B(Server: GraphQL Endpoint);
    B -- Resolves Query --> C{Feed Selection Logic};
    C -- Based on Expiration Info --> D[Database of Media Messages];
    D -- Returns Subset --> C;
    C -- Associates Ads --> E[Ad Server];
    E -- Returns Ad Prompts --> C;
    C -- Constructs JSON Response --> B;
    B -- Returns Specified Data --> A;
```

1.2. Operational Parameter Expansion

Derivative 1.2.1: Nanosecond-Scale Expiration for High-Frequency Trading Feeds
- Enabling Description: The operational parameters are scaled to handle media messages with expiration information defined at the nanosecond level. The system is designed for high-frequency financial or betting applications where information (a "media message") is only valid for microseconds or nanoseconds. The server infrastructure utilizes Field-Programmable Gate Arrays (FPGAs) or Application-Specific Integrated Circuits (ASICs) to execute the message selection logic. Messages are received via a low-latency protocol like FIX (Financial Information eXchange) and stored in SRAM. The FPGA continuously evaluates expiration timestamps against a high-precision network clock and assembles feeds of currently valid market data or odds. The "advertisement prompt" is replaced with a sponsored trade execution button or a micro-betting opportunity.
- Mermaid Diagram:
```
flowchart LR
    subgraph Low-Latency Infrastructure
        A[FIX Ingest] --> B(FPGA Processor);
        C[High-Precision Clock] --> B;
        B --> D{SRAM Message Store};
    end
    subgraph Feed Generation
        B -- Selects Subset based on Nanosecond Expiration --> E[Feed Assembler];
        F[Sponsored Trade Engine] -- Provides Prompts --> E;
        E --> G(Feed Stream to Client);
    end
```
Derivative 1.2.2: Geocached Feeds for Large-Scale Live Events
- Enabling Description: The method is adapted for industrial-scale use at a live event (e.g., Olympics, music festival) with millions of concurrent users. The "media messages" are short video clips, alerts, or offers relevant to specific venues within the event. The expiration information is tied to the duration of an activity at a venue (e.g., a 15-minute concert set). The server system pre-generates and caches multiple feeds for each venue (geofenced zone) on a Content Delivery Network (CDN). A mobile device entering a zone is served the pre-cached feed. The selection of the subset is performed ahead of time based on the event schedule, and the advertisement prompts are sponsored messages from vendors within that zone. This avoids real-time selection load on the central server during peak demand.
- Mermaid Diagram:
```
graph TD
    A[Central Server] -- Event Schedule --> B{Pre-Generation Service};
    B -- Generates Feeds per Geofence --> C[CDN Storage];
    D[Mobile App] -- Enters Geofence --> E{Location Service};
    E -- Notifies App of Zone --> D;
    D -- Requests Feed for Zone --> C;
    C -- Delivers Cached Feed with Ads --> D;
```

1.3. Cross-Domain Application

Derivative 1.3.1: Aerospace - Dynamic Flight Crew Checklists
- Enabling Description: In an aerospace context, the method is used to manage and present dynamic checklists to flight crews on Electronic Flight Bag (EFB) devices. "Media messages" are individual checklist items. The "expiration information" is tied to a specific flight phase (e.g., "pre-flight," "takeoff," "in-flight climb"). The server receives checklist items from a central flight operations database. It selects a "first feed" of pre-flight checks and provides it to the EFB. Upon phase change detection (e.g., from aircraft data bus), the EFB requests a new feed, and the server provides the "second feed" (e.g., takeoff checks). The "advertisement prompt" is replaced with a safety notification, maintenance alert, or an informational prompt linking to a specific section of the flight manual.
- Mermaid Diagram:
```
stateDiagram-v2
    [*] --> PreFlight
    PreFlight: Displaying Feed 1 (Pre-Flight Checks)
    PreFlight --> Takeoff: Flight Phase Change Detected
    Takeoff: Displaying Feed 2 (Takeoff Checks)
    Takeoff --> Climb: Flight Phase Change Detected
    Climb: Displaying Feed 3 (Climb Checks)
```
Derivative 1.3.2: AgTech - Time-Sensitive Crop Treatment Feeds
- Enabling Description: In agricultural technology (AgTech), the method delivers time-sensitive treatment plans to smart farming equipment (e.g., drones, tractors). "Media messages" are specific instructions, such as "apply X liters of pesticide to sector 4" or "irrigate sector 2 with Y amount of water." The "expiration information" is critical and is based on environmental sensor data (e.g., soil moisture below a threshold, pest detection valid for 2 hours). The server aggregates sensor data, selects a subset of urgent tasks into a "treatment feed," and pushes it to the relevant machinery. The "advertisement prompt" becomes a sponsored recommendation for a specific brand of fertilizer or pesticide that is compatible with the current task.
- Mermaid Diagram:
```
sequenceDiagram
    participant SensorNet as IoT Sensor Network
    participant AgServer as Agricultural Server
    participant SmartTractor as Autonomous Tractor App

    SensorNet->>AgServer: Stream Real-time Soil/Pest Data
    AgServer->>AgServer: Analyze data, create treatment tasks (media messages) with expiration
    AgServer->>AgServer: Select subset of urgent tasks into Treatment Feed
    AgServer->>AgServer: Associate sponsored product prompt
    AgServer-->>SmartTractor: Provide Treatment Feed
    SmartTractor->>SmartTractor: Execute tasks from feed
```

1.4. Integration with Emerging Tech

Derivative 1.4.1: AI-Optimized Personalized Feed Generation
- Enabling Description: The method is integrated with an AI/ML model for feed personalization. The server receives the plurality of media messages. The selection of the "first subset" is not based solely on expiration but is primarily determined by a machine learning model that predicts user engagement. The model considers user history, time of day, device type, and the semantic content of the media messages. The "expiration information" is used as a hard constraint to filter out expired content before the AI model makes its selection. The associated "advertisement prompt" is also selected by a complementary AI model to maximize conversion probability for that specific user and media message pairing. The system continuously retrains the models based on user interactions.
- Mermaid Diagram:
```
graph TD
    subgraph Server
        A[Media Messages Ingest] --> B(Filter Expired Content);
        B --> C[User Profile Data];
        C --> D{AI Engagement Prediction Model};
        B --> D;
        D -- Selects Personalized Subset --> E[Feed Assembler];
        F{AI Ad Selection Model} --> E;
        E --> G[Provide Personalized Feed];
    end
    subgraph Client
        H[Mobile App] --> G;
        G --> H;
        H -- Interaction Data --> I(Feedback Loop);
        I --> D;
        I --> F;
    end
```
Derivative 1.4.2: Blockchain-Verified Message Provenance
- Enabling Description: The method is enhanced with blockchain integration to ensure the authenticity and provenance of media messages, particularly for news or official announcements. When a media message is received by the server, its hash, author, and timestamp are recorded as a transaction on a distributed ledger (e.g., a permissioned blockchain). When the server selects a subset of messages for a feed, it includes the blockchain transaction ID for each message. The mobile application can optionally use this ID to query the blockchain and independently verify that the message content has not been altered since its creation. The "advertisement prompt" can also be linked to a smart contract on the blockchain that governs the terms of the ad placement and payment.
- Mermaid Diagram:
```
erDiagram
    SERVER {
        string messageID PK
        string content
        datetime expiration
        string blockchainTxID
    }
    MOBILE_APP {
        string sessionID PK
        string currentFeed
    }
    BLOCKCHAIN {
        string transactionID PK
        string messageHash
        string author
        datetime timestamp
    }
    SERVER ||--o{ BLOCKCHAIN : Records
    SERVER ||--o{ MOBILE_APP : Provides_Feed
```

1.5. The "Inverse" or Failure Mode

Derivative 1.5.1: Graceful Degradation to a Text-Only, Ad-Free Failsafe Feed
- Enabling Description: A version of the method is designed to fail safely. Under normal operation, the server provides rich media feeds with video and interactive advertisement prompts. The server continuously monitors its own load, network latency, and the health of the advertising backend. If a performance threshold is breached (e.g., database response time > 500ms), the system automatically switches to a "limited-functionality" mode. In this mode, the selection logic is simplified to only choose media messages that are text-only, and it explicitly omits the step of associating an advertisement prompt. This ensures that users receive a core, low-bandwidth, failsafe feed of information even when ancillary services like video hosting or ad serving are unavailable.
- Mermaid Diagram:
```
stateDiagram-v2
    [*] --> Normal_Operation
    Normal_Operation: Serving Rich Media Feeds with Ads
    state Normal_Operation {
        [*] --> Monitoring
        Monitoring --> Threshold_Breached : High Latency or System Load
    }
    Normal_Operation --> Limited_Functionality : Failover
    Limited_Functionality: Serving Text-Only Feeds, No Ads
    Limited_Functionality --> Normal_Operation : System Health Restored
```

Section 2: Combination Prior Art Scenarios

The core method of the '591 patent is combined with existing open-source standards to create obvious and non-novel derivative systems.

Combination with ActivityPub (W3C Standard): The server system is implemented as a federated social media server (e.g., Mastodon, PeerTube) that communicates using the ActivityPub protocol. "Media messages" are Note or Video objects in the ActivityStreams 2.0 vocabulary. The "expiration information" is a custom property, expires, added to the ActivityStream object. A client application receives a feed by following a specific Actor (e.g., a news bot). The server selects which activities to push to followers' inboxes based on the expires property. The "advertisement prompt" is an Announce activity where the object being announced is a sponsored Note from an advertiser, injected into the user's feed. The ability to switch feeds is accomplished by following or unfollowing different Actor accounts. This combines the feed generation of '591 with the standardized, decentralized infrastructure of the Fediverse.
Combination with RSS (Really Simple Syndication): The server's output is not a proprietary API but a standard RSS or Atom XML feed. The "first feed" and "second feed" are simply different RSS feed URLs (e.g., .../feed.php?type=news and .../feed.php?type=sports). Each <item> in the RSS feed represents a media message. The "expiration information" is implemented using the <ttl> (time to live) tag, which informs the client how long to cache the feed before requesting a new one. The selection logic on the server filters messages based on their internal expiration times before generating the XML file. The "advertisement prompt" is an additional <item> in the feed that is clearly marked as sponsored, or is embedded within the <description> field of a content item using HTML, following the RSS specification's allowance for HTML content.
Combination with IAB OpenRTB (Interactive Advertising Bureau Real-Time Bidding): The process of associating an "advertisement prompt" is performed by integrating the server with the OpenRTB open standard. When the server selects a subset of media messages to form a feed, it generates a bid request for each message slot and sends it to an ad exchange. This bid request contains information about the media message content and the user (anonymized). Ad buyers bid in real-time to have their ad served. The winning bid's ad creative (the "advertisement prompt") is returned to the server, which then packages it with the media message into the feed for the mobile application. This replaces the patent's generic "association" of an ad with a standardized, auction-based mechanism for ad selection and pricing.