The USPTO search confirms that the USPTO offers "Patent Public Search" and "Patent Center" tools to search for patents and patent applications. A direct search for patent number 12112357B2 on these platforms would yield the official record, which aligns with the authoritative full patent text provided in the user prompt. No contradictions were found.

Defensive Disclosure: Advanced Mobile Streaming Media Application Architectures and Operation

This document describes a series of derivative works and technical variations on the core inventive concepts disclosed in US Patent 12112357B2, "Mobile device streaming media application." The purpose of this disclosure is to establish prior art for potential future incremental improvements by competitors, rendering such advancements obvious or non-novel. The current date for this disclosure is April 26, 2026.

Derivative Variations for Core Claims

The following derivatives expand upon the independent claims 1, 9, 16, and 24 of US12112357B2. For brevity and because system claims largely mirror method claims in functionality, some derivatives will implicitly cover both where the underlying technical concept is the same.

1. Material & Component Substitution

Derivative 1.1: Distributed Edge Processing for Media Ingestion and Transcoding (Claim 1, 9, 16, 24)

Enabling Description:
Instead of a single centralized server (server 102) performing all media processing, an architecture comprising a plurality of geographically distributed edge computing nodes (e.g., mini-datacenters or content delivery network points of presence) is employed. Each edge node includes specialized hardware acceleration for real-time media ingestion, format transcoding (e.g., HEVC, AV1, VP9), and adaptive bitrate streaming preparation (e.g., HLS, DASH segments). Mobile devices 106 upload raw or minimally processed media messages to the nearest edge node based on geographical proximity or network latency. These edge nodes then perform initial processing (e.g., resizing, basic filtering, metadata extraction, generation of various bitrate renditions) and apply initial expiration metadata. The processed content is then replicated to a central object storage system (e.g., S3-compatible) which serves as the primary repository, with further processing and feed orchestration occurring at a central cloud-based microservices platform. This reduces latency for users uploading content and offloads computation from a single monolithic server.

flowchart TD
    A[Mobile Device 106] -->|Upload Raw Media| B(Edge Computing Node)
    B --> C{Media Ingestion & Transcoding Service}
    C --> D[Adaptive Bitrate Packaging]
    D --> E[Object Storage (e.g., S3)]
    E --> F[Cloud-based Microservices Platform]
    F -->|Feed Orchestration| G[Central Feed Server]
    G -->|Deliver Feeds| A
    E -- Replication --> F

Derivative 1.2: Optically-Routed Media Backbones for High-Bandwidth Feeds (Claim 1, 16)

Enabling Description:
The underlying network infrastructure (network 104) for critical, high-bandwidth media feeds (e.g., 4K/8K video streams, interactive VR experiences) utilizes dedicated optical fiber backbones with software-defined networking (SDN) and wavelength-division multiplexing (WDM) for dynamic, low-latency routing. Content distribution from origin servers (e.g., server 102) to regional distribution hubs leverages direct optical connections, bypassing intermediate network layers and conventional IP routing congestion where feasible. This setup is particularly beneficial for specialized feeds requiring guaranteed quality of service (QoS) and minimal jitter, ensuring that "live streaming media files" (Description, paragraph 0041) maintain superior fidelity and responsiveness. Mobile devices 106 connect to enhanced wireless access points (e.g., 5G mmWave, Wi-Fi 7) which are directly integrated into this optical backbone, minimizing terrestrial wireless hops.

graph TD
    A[Origin Server] --WDM & SDN--> B(Regional Optical Hub 1)
    A --WDM & SDN--> C(Regional Optical Hub 2)
    B --Optical Cross-Connect--> D[Wireless Access Point (5G/Wi-Fi 7)]
    C --Optical Cross-Connect--> E[Wireless Access Point (5G/Wi-Fi 7)]
    D --> F[Mobile Device 106]
    E --> G[Mobile Device 106]
    F --User Request/Interaction--> D
    G --User Request/Interaction--> E

2. Operational Parameter Expansion

Derivative 2.1: Hyper-Localized, Ultra-Short-Duration Micro-Feeds (Claim 1, 9, 16, 24)

Enabling Description:
The system is configured to manage and deliver media messages with extremely precise spatial and temporal parameters. "Expiration information" (Claim 1) is refined to include geographic coordinates (latitude, longitude, altitude/floor level) and a validity radius (e.g., 10-meter radius) for spatial relevance, alongside temporal durations measured in seconds (e.g., 5-second message lifetime). This enables the creation of "micro-feeds" where messages are only visible and accessible to users within a specific physical location for a very brief period. For instance, a message captured by a mobile device camera (Claim 9) might be designated for "airing" only within a specific retail store section for 30 seconds to alert passersby of an immediate flash sale. The server (server 102) continuously evaluates user location data (via GPS, Wi-Fi triangulation, UWB) against message spatial and temporal expiration parameters to determine feed inclusion.

sequenceDiagram
    participant M as Mobile Device 106
    participant S as Server 102 (Geo-Spatial Engine)
    participant D as Database (Micro-Feeds)

    M->S: Upload Media Message (Geo-tag, 30s Expiry)
    S->D: Store Message + Geo-Expiry
    loop Every few seconds
        M->S: Send Current Location (GPS/UWB)
        S->D: Query Micro-Feeds by Location & Expiry
        D-->S: Relevant Micro-Feeds
        S-->M: Provide Micro-Feed
    end
    Note over M,S: Message disappears after 30s or leaving geo-fence

Derivative 2.2: Sub-millisecond Latency Real-Time Command and Control Feeds (Claim 1, 16)

Enabling Description:
The system is optimized for mission-critical, real-time command and control applications requiring sub-millisecond end-to-end latency for media feed delivery and user interaction. This involves utilizing low-latency transport protocols (e.g., UDP-based QUIC, WebRTC datachannels) directly over dedicated network slices (e.g., 5G URLLC) for delivery of the "first feed" and "second feed." Servers (server 102) employ in-memory databases (e.g., Redis, Aerospike) for media message storage and expiration management, with content delivered from RAM to network interfaces. Mobile application clients are implemented using high-performance, bare-metal rendering engines and prioritize network packets from the command and control feeds over all other background traffic. Sharing prompts, comments, and other interactive elements are designed for extremely rapid feedback loops, potentially using haptic feedback to confirm immediate command execution.

graph LR
    A[Command Center Server 102] -- Dedicated Network Slice (5G URLLC) & QUIC --> B(Mobile Device 106)
    B -- Sub-ms Latency Input (e.g., haptic feedback) --> A
    subgraph Server Operations
        C[In-Memory DB] --> D(Real-time Feed Selection & Packaging)
        D --> A
    end
    subgraph Mobile App Operations
        E[High-Perf Rendering] --> F(User Input Processing)
        F --> B
    end
    D --Feed 1--> A
    D --Feed 2--> A
    B --Switch Feed Request--> A

3. Cross-Domain Application

Derivative 3.1: Precision Agriculture - Crop Health Anomaly Feeds (Claim 9, 24)

Enabling Description:
In precision agriculture, the system is deployed with mobile applications on ruggedized agricultural tablets or drone control units. Farmers or automated drones "generate a plurality of media messages" (Claim 9) that include "image or video captured by the one or more mobile applications via a corresponding one or more cameras" (Claim 9) of multispectral or hyperspectral cameras. These media messages capture anomalies in crop health (e.g., discoloration, pest infestation, water stress) at specific geo-referenced locations within a field. The "expiration information" for these messages (Claim 1) is tied to remediation timelines or crop growth stages; for example, a pest alert message expires once the pest has been treated or the crop has advanced to a resistant stage. Distinct "first feed" (e.g., "Critical Alerts") and "second feed" (e.g., "Trending Issues") are provided. The sharing prompt facilitates sending anomaly reports to agronomists or farm equipment for autonomous treatment application.

flowchart TD
    A[Agricultural Tablet / Drone App] -->|Capture Multispectral Imagery| B(Server 102 - Agri-Analytics)
    B --> C{Detect Crop Anomaly}
    C --> D[Generate Media Message (Anomaly, Geo-Tag, Expiry)]
    D --> E[Database (Farm Records)]
    E --Select Subsets--> F{Feed Generation (Critical vs. Trending)}
    F --> G[Mobile App (Farmer/Agronomist)]
    G -->|Sharing Prompt| H[Agronomist / Autonomous Sprayer]

Derivative 3.2: Industrial Safety - Predictive Maintenance Alert Streams (Claim 1, 16)

Enabling Description:
For industrial safety and predictive maintenance in manufacturing plants, the system operates by receiving media messages generated by IoT sensors (e.g., thermal cameras, vibration sensors, acoustic monitors) attached to machinery. These "media messages" (Claim 1) are automated alerts (e.g., thermal image of an overheating component, a vibration spectrogram indicating bearing failure) accompanied by severity and resolution "expiration information" (e.g., "must be addressed within 2 hours" or "resolved by next scheduled maintenance"). A "first feed" displays "Critical Alerts" requiring immediate attention, while a "second feed" presents "Watchlist Items" for less urgent monitoring. Engineers or technicians view these feeds on ruggedized mobile devices. The "sharing prompt" allows for immediate creation of work orders in an Enterprise Asset Management (EAM) system or direct notification to maintenance teams, linking specific machine diagnostics to the media message.

graph LR
    A[Industrial IoT Sensors] -->|Transmit Media Messages (Alerts)| B(Gateway)
    B --> C(Server 102 - Predictive Maintenance Engine)
    C --> D{Evaluate Severity & Set Expiry}
    D --> E[Database (Machine Health Records)]
    E --Select Feeds (Critical vs. Watchlist)--> F(Mobile App - Technician/Engineer)
    F -->|Share Work Order| G[EAM System / Maintenance Team]
    F --Switch Feed--> F

Derivative 3.3: Emergency Response - Dynamic Incident Status Feeds (Claim 9, 24)

Enabling Description:
In emergency response scenarios (e.g., natural disasters, public safety incidents), first responders use mobile applications on their robust communication devices (e.g., TETRA radios with integrated cameras) to "generate a plurality of media messages" (Claim 9) comprising "image or video captured by... cameras" of the incident scene. Each message is tagged with real-time incident status and "expiration information" relevant to the dynamic nature of the event (e.g., "road closed until 14:00," "fire contained (expires 15 min after update)"). A "first feed" for field personnel might show "Active Hazard Zones," while a "second feed" for command centers displays "Resource Deployment Status." The "sharing prompt" allows for rapid dissemination of critical updates to other agencies, mapping platforms, or public information channels, with generated links providing direct access to geo-located incident media.

stateDiagram-v2
    state "Mobile App (First Responder)" as M_APP
    state "Server 102 (Incident Management)" as SERVER
    state "Central Database" as DB
    state "Command Center Display" as CMD_CENT
    state "Public Info Portal" as PUB_INFO

    M_APP --> SERVER : Generate/Upload Incident Media (Camera, Geo-tag, Dynamic Expiry)
    SERVER --> DB : Store Incident Data
    DB --> SERVER : Select Feeds (Active Hazards, Resource Status)
    SERVER --> M_APP : Provide Feed 1 (Active Hazards)
    SERVER --> CMD_CENT : Provide Feed 2 (Resource Status)
    M_APP --> M_APP : User Switches Feeds
    M_APP --> SERVER : Share Link
    SERVER --> PUB_INFO : Generate Access Link

4. Integration with Emerging Tech

Derivative 4.1: AI-Driven Contextual Feed Optimization and Anomaly Detection (Claim 1, 9, 16, 24)

Enabling Description:
The server (server 102) integrates an AI-driven contextual engine that continuously analyzes incoming "media messages" (Claim 1, 9) and user interaction patterns to dynamically optimize feed content and detect anomalies. For messages containing "image or video captured by... cameras" (Claim 9), computer vision AI processes the content for semantic understanding (e.g., identifying objects, detecting sentiment in text overlays, transcribing audio). Natural Language Processing (NLP) models analyze "comments" (Description, paragraph 0042) to infer user sentiment and engagement. The "first feed" and "second feed" are then personalized for each user or group based on learned preferences, historical interactions, and inferred context (e.g., time of day, current user activity, explicit interest tags). The AI also monitors feed consumption and sharing patterns to predict message virality, automatically adjusting "expiration information" (Claim 1) or promoting under-engaged messages, and flags potentially harmful or anomalous content for moderation before it's widely broadcast.

flowchart TD
    A[Mobile Device 106] --> B(Server 102 - Ingest)
    B --> C{AI Content Analysis (CV, NLP)}
    C --> D[AI Feed Optimization Engine]
    D --Personalized Selection & Ordering--> E[Dynamic Feed Generator]
    E --> F[Feed 1 / Feed 2 to Mobile App]
    F <-- User Interaction --> G[Mobile App (Personalized Feed)]
    D --Anomaly Detection--> H[Moderation Queue]
    H --> B

Derivative 4.2: IoT-Triggered Immersive Media Experiences (Claim 1, 9, 16, 24)

Enabling Description:
The system is integrated with a pervasive network of IoT sensors that trigger the generation and delivery of "media messages" (Claim 1) creating immersive experiences. For example, in a smart retail environment, a user's presence near a product display (detected by BLE beacons or UWB sensors, part of IoT) triggers a "first feed" containing an interactive augmented reality (AR) product demo or a 360-degree video message related to the product, delivered to their mobile device 106. The "expiration information" for this message is set to expire when the user moves away from the product display or after a set engagement time. User interactions with "sharing prompts" (Claim 1) within the AR experience could generate links to product information or purchase options. The "second feed" could be a general store news stream, with users switching between the contextual AR feed and the general feed via "user interaction" (Claim 1). Media messages could also be automatically captured by fixed IoT cameras (e.g., security cameras, smart doorbells) and fed into the system with dynamically assigned expiration times.

sequenceDiagram
    participant U as User (Mobile Device 106)
    participant I as IoT Sensors (Beacons/UWB)
    participant S as Server 102 (IoT & Media Orchestration)
    participant A as Mobile App (AR Capable)

    I->S: User Proximity Event (Product Display)
    S->S: Identify Contextual Media Message
    S->S: Set Dynamic Expiration
    S->A: Provide "First Feed" (Interactive AR Media Message)
    A->U: Present AR Experience
    U->A: Interact with AR (e.g., Share Link)
    A->S: Send Share Request
    S->U: Generate & Deliver Link (e.g., to product page)
    U->A: User Initiates "Switch Feed"
    A->S: Request "Second Feed"
    S->A: Provide "Second Feed" (General Store News)

Derivative 4.3: Blockchain-Verified Content Provenance and Micro-Licensing (Claim 1, 9, 16, 24)

Enabling Description:
To enhance trust and enable micro-licensing, the system integrates blockchain technology for immutable recording of "media message" (Claim 1, 9) provenance and "payment" (Description, abstract) for "airtime" (Description, abstract). When a user uploads a media message, especially "image or video captured by... cameras" (Claim 9), a unique cryptographic hash of the content, along with metadata such as originator ID, timestamp, and initial "expiration information" (Claim 1), is recorded on a public or consortium blockchain (e.g., Ethereum, Solana). "Scheduled airtimes" (Claim 8) and subsequent "payments" for airtime are executed as smart contract transactions, verifiable on-chain. The "sharing prompt" (Claim 1) generates links that include cryptographic proofs of content authenticity and ownership. Furthermore, a micro-licensing smart contract can be associated with each media message, allowing other users to acquire temporary usage rights (e.g., for re-broadcasting on another feed) for a small, tokenized fee, with the transaction recorded on-chain, and the "item purchase prompt" (Claim 7) facilitating the acquisition of these usage rights.

flowchart TD
    A[Mobile Device 106] --> B(Server 102 - Content Ingestion)
    B --> C{Generate Content Hash + Metadata}
    C --> D[Blockchain Network (e.g., Ethereum)]
    D --> E[Immutable Content Record]
    B --> F[Database (Media Messages)]
    F --Airtime Purchase (Smart Contract)--> D
    F --User Engagement/Views--> G[Royalty Smart Contract]
    G --> D
    H[Mobile App] --View Feed--> F
    H --Share Prompt--> B
    B --Link with Proof--> I[External Platform]

5. The "Inverse" or Failure Mode

Derivative 5.1: Adaptive "Low-Bandwidth / Disaster Mode" Operation (Claim 1, 16)

Enabling Description:
The system is designed with an adaptive "Low-Bandwidth / Disaster Mode" that automatically or manually activates under detected network congestion, infrastructure failure, or emergency situations. In this mode, the server (server 102) prioritizes critical, non-expiring text-only "media messages" and "sharing prompts" over all other media types for the "first feed." All "image or video" (Claim 9) content is automatically transcoded to extremely low-resolution, monochrome, or grayscale still images, or completely suppressed. Dynamic HTML/text-based feeds replace rich media streams. The "expiration information" for non-critical messages is automatically extended or marked for indefinite archival until normal service resumes. The "second feed" (e.g., "entertainment stream") is entirely suspended. The mobile application is configured to aggressively cache critical text feeds and minimize network requests, potentially switching to peer-to-peer mesh networking (e.g., using Wi-Fi Direct or Bluetooth LE) with other local mobile devices if server connectivity is lost.

stateDiagram-v2
    state "Normal Operation" as Normal
    state "Low-Bandwidth / Disaster Mode" as LowBandwidth

    [*] --> Normal
    Normal --> LowBandwidth : Detect Network Failure / Congestion
    LowBandwidth --> Normal : Network Restored / Manual Override

    state "Server Behavior" {
        Normal : Transmit Rich Media Feeds
        LowBandwidth : Prioritize Text-Only / Low-Res Images
        LowBandwidth : Suspend Non-Critical Feeds
        LowBandwidth : Extend/Archive Expiration Info
    }

    state "Mobile App Behavior" {
        Normal : Display Rich Media
        LowBandwidth : Display Text/Low-Res
        LowBandwidth : Aggressive Caching
        LowBandwidth : Attempt Mesh Networking
    }

Derivative 5.2: "Safe Mode" for Content Moderation Failures (Claim 1, 9, 16, 24)

Enabling Description:
In the event of a detected content moderation system failure (e.g., malicious content bypasses filters, sudden surge of inappropriate "media messages"), the system enters a "Safe Mode." All user-generated content, particularly "image or video captured by... cameras" (Claim 9), is automatically subjected to a mandatory, human-review queue before "airing" in any "feed." If real-time human review capacity is exceeded, all incoming user-generated media messages are temporarily converted to placeholder text messages or held in a quarantine state, irrespective of their "scheduled airtimes" or "expiration information." Previously approved content continues to stream, but new contributions are halted or severely restricted. "Sharing prompts" are disabled for new content, and any generated "links" (Claim 1) for content posted during the moderation failure are flagged with a disclaimer or temporarily deactivated. The "switch stream button 115" (Description, paragraph 0053) functionality might be restricted to only pre-vetted, administrator-controlled feeds.

flowchart TD
    A[User Uploads Media Message] --> B{AI Content Filter}
    B --Pass--> C[Scheduled for Airing]
    B --Fail / Suspect--> D{Human Review Queue}
    subgraph System State
        state "Normal Content Flow" as NCF
        state "Safe Mode (Moderation Failure)" as SMF
    end
    NCF --> A
    D --Clear--> C
    D --Reject--> E[Content Rejected]
    SMF --Activation--> D
    SMF --If Review Queue Full--> F[New Content Quarantined / Text-Only Placeholder]
    C --> G[Live Feeds (Feed 1, Feed 2)]
    F --> G
    G --Sharing Prompt (Disabled for new content in SMF)--> H[Link Generation]

Combination Prior Art Scenarios

Here are three combination prior art scenarios where the patent US12112357B2's core concepts could be combined with existing open-source standards to establish obviousness or lack of novelty for certain improvements.

Scenario 1: Decentralized, User-Controlled Feeds with ActivityPub

Description:
The core concept of "receiving... media messages" and "providing... feeds" (Claim 1) with "sharing prompts" (Claim 1) can be combined with the ActivityPub W3C standard (an open, decentralized social networking protocol). A system could be built where mobile applications function as ActivityPub clients, generating "media messages" (Claim 9) as "Activities" (e.g., "Note" for text, "Video" for video) and "sharing" them across a federated network of ActivityPub-compatible servers. "Expiration information" (Claim 1) could be implemented as a metadata field within the ActivityPub object (e.g., endTime property in an Activity or Object), indicating when a message is no longer considered active in a user's "inbox" feed. The "first feed" and "second feed" (Claim 1) would correspond to different collections of Activities (e.g., a "Public Timeline" and a "Friends-Only Stream"), with the mobile application configured to "switch a presentation" (Claim 1) between these federated feeds. The "link configured to enable access to the media message" (Claim 1) is inherent to ActivityPub's URL-based object addressing.

Scenario 2: Real-time, Browser-Based Streaming with WebRTC and Media Source Extensions

Description:
The concept of "providing the first feed... to a mobile application executable on a mobile device, the mobile application configured to present the first feed" (Claim 1), especially when delivering "live streaming media file (e.g., streaming audio/video)" (Description, paragraph 0041), can be rendered obvious by combining existing web standards. Specifically, using WebRTC (Web Real-Time Communication, an open-source project enabling real-time communication capabilities in web browsers) for low-latency, peer-to-peer media ingestion from mobile devices (acting as WebRTC peers) to a server, and Media Source Extensions (MSE) (a W3C API allowing JavaScript to construct media streams for playback in HTML5 video and audio elements) for presenting adaptable streaming content in a web browser. The mobile application could be a progressive web application (PWA) or a hybrid app utilizing a WebView to access the browser-based streaming interface. "Expiration information" (Claim 1) would be managed server-side and signaled to the client-side JavaScript, which would then dynamically remove expired segments from the MSE buffer. The ability to "switch a presentation of the first feed to a presentation of the second feed" (Claim 1) is a standard feature of web-based media players that can switch between different MediaSource objects or adapt their content selection based on user input.

Scenario 3: Containerized, Scalable Media Microservices with Kubernetes and FFmpeg

Description:
The "system, comprising: one or more servers including memory, machine-readable instructions, and one or more processors" (Claim 16, 24) configured to "receiving, at the one or more servers, a plurality of media messages" and "storing the plurality of media messages" (Claim 16, 24), and then "selecting, for inclusion in respective ones of a first feed and a second" (Claim 16, 24) and "providing the first feed" (Claim 16, 24) can be made obvious by combining Kubernetes (an open-source system for automating deployment, scaling, and management of containerized applications) and FFmpeg (a leading open-source multimedia framework for processing audio and video). Media ingestion, transcoding, packaging, and feed generation services can each be deployed as distinct microservices within a Kubernetes cluster. FFmpeg, running within Docker containers orchestrated by Kubernetes, performs the actual media processing (e.g., converting "image or video captured by... cameras" (Claim 9) into various streaming formats like HLS/DASH). Kubernetes' inherent auto-scaling capabilities efficiently handle fluctuating loads of incoming media messages and outgoing feed requests. "Expiration information" (Claim 1) would be managed by a dedicated microservice that signals FFmpeg processes to stop serving specific content segments once expired, and automatically cleans up expired media files from distributed storage. The "first feed" and "second feed" are dynamically composed by dedicated feed-generation microservices querying the content catalog, with Kubernetes ensuring high availability and resilience.

Derivative works