Patent 12112357

Derivative works

Defensive disclosure: derivative variations of each claim designed to render future incremental improvements obvious or non-novel.

Active provider: Google · gemini-2.5-flash

Derivative works

Defensive disclosure: derivative variations of each claim designed to render future incremental improvements obvious or non-novel.

✓ Generated

This Defensive Disclosure document analyzes US patent 12,112,357 and generates derivative variations for its independent claims, aimed at creating prior art to render future incremental improvements by competitors obvious or non-novel. The goal is to technically describe these variations to enable reproduction by a person skilled in the art.

Defensive Disclosure: Derivatives of US Patent 12,112,357

I. Derivatives of Independent Claim 1 (Method - Server-Centric Media Feed Coordination)

Claim 1: A method, comprising: receiving, at one or more servers, a plurality of media messages from one or more mobile applications executable on a corresponding one or more mobile devices; storing the plurality of media messages on the one or more servers, wherein one or more stored media messages are associated with expiration information to determine when the one or more stored media messages can no longer be provided in a feed; selecting, for inclusion in respective ones of a first feed and a second, corresponding ones of a first subset and a second subset of media messages from among the plurality of media messages stored on the one or more servers, wherein the respective selections of the first subset and the second subset of media messages are based at least in part on the expiration information, wherein the second feed differs from the first feed; providing the first feed from the one or more servers to a mobile application executable on a mobile device, the mobile application configured to present the first feed, wherein presentation of the first feed by the mobile application includes presentation of a sharing prompt with a media message included in the first feed, wherein interaction with the sharing prompt via the mobile application facilitates generation of a link configured to enable access to the media message; and providing the second feed from the one or more servers to the mobile application, the mobile application configured to present the second feed, wherein the mobile application is further configured to switch a presentation of the first feed to a presentation of the second feed in response to a user interaction with the mobile application.

Derivative 1.1: Material & Component Substitution - Distributed Ledger Server Architecture

  • Enabling Description: The "one or more servers" are implemented as a distributed network of peer-to-peer nodes, each running a client-side daemon that contributes storage and processing power. Media messages are fragmented and stored across this distributed ledger network, leveraging content-addressable storage (e.g., IPFS). Expiration information is embedded within the metadata of each media message's ledger entry, validated by consensus mechanisms. Feed selection and provision are executed via smart contracts on the distributed ledger, defining rules for content inclusion and access based on expiration and user preferences. The mobile application interacts with a local ledger node or a gateway to retrieve signed content hashes and associated metadata, reconstructing feeds. Sharing prompts generate cryptographically verifiable links (e.g., IPFS CIDs) that ensure content integrity and immutability of access, referencing the ledger for content resolution.
graph TD
    A[Mobile App] -- Submit Media (Fragmented) --> B(Distributed Ledger Network)
    B -- Store & Replicate (IPFS/Blockchain) --> C{Ledger Nodes}
    C -- Consensus Validation --> D[Smart Contract: Feed Rules]
    D -- Query & Select (Expiration Based) --> E[Feed Generation]
    E -- Provide Feed (Signed CIDs) --> A
    A -- Share Prompt (Generate CID Link) --> F[External User]
    F -- Access Content via CID --> B

Derivative 1.2: Operational Parameter Expansion - Terabit-Scale Geospatial Event Streaming

  • Enabling Description: This variation operates at an extreme scale, handling terabit-per-second streaming of hyper-localized, high-definition (8K volumetric) media messages from millions of geographically dispersed mobile devices. The "one or more servers" consist of a globally distributed edge computing network leveraging specialized hardware accelerators (e.g., NVIDIA Jetson for edge processing, dedicated transcoding ASICs for format conversion) and massive parallel processing clusters (e.g., GPU farms) within regional data centers. Media messages, including live geospatial sensor data and multi-spectrum imagery, are time-stamped with nanosecond precision and associated with geofenced expiration polygons, defining both temporal and spatial expiration. Feeds are dynamically composed based on user proximity to expired/active geofences and network load, streamed via low-latency protocols (e.g., WebRTC over 5G millimeter wave or satellite links). The sharing prompt generates a time- and location-sensitive deep link to the volumetric media stream, dynamically adjusting resolution based on recipient device capabilities and network conditions.
graph TD
    A[Mobile Device (5G/SAT)] -- Hyper-Localized 8K Volumetric Media --> B(Edge Compute Network)
    B -- Ingest & Pre-process (ASICs) --> C[Global Data Centers]
    C -- Store & Process (GPU Farms) --> D{Geospatial Expiration Engine}
    D -- Dynamic Feed Composition (Proximity/Expiration) --> E[Low-Latency Stream Provision]
    E -- Stream (WebRTC/5G) --> A
    A -- Share Prompt (Time/Location Deep Link) --> F[Recipient Device]
    F -- Access Stream (Dynamic Resolution) --> E

Derivative 1.3: Cross-Domain Application - Precision Agriculture Field Monitoring

  • Enabling Description: In a precision agriculture context, "mobile applications" are executed on agricultural drones or robotic field sensors. "Media messages" include real-time multispectral imagery (e.g., NDVI, thermal), soil moisture data, and pest detection videos captured by these mobile platforms. The "one or more servers" are located in a central farm management system or a cloud agriculture platform. Expiration information is linked to crop growth stages, weather forecasts, or pesticide application windows. A "first feed" could be "Crop Health Anomalies," displaying time-sensitive alerts for specific field zones requiring immediate attention. A "second feed" could be "Irrigation Recommendations," showing scheduled watering plans and resource utilization. A farmer, via a ruggedized tablet, switches between these feeds. The sharing prompt allows sharing a link to a specific georeferenced anomaly video or data point with an agronomist or equipment operator for rapid response.
graph TD
    A[Agri-Drone/Sensor] -- Multispectral/Sensor Data --> B(Cloud Agriculture Platform)
    B -- Store & Process (GIS) --> C{Crop Growth Model}
    C -- Expiration Logic (Growth Stage/Weather) --> D[Feed Selection Engine]
    D -- Provide Feed 1 (Crop Health Alerts) --> E[Ruggedized Tablet]
    D -- Provide Feed 2 (Irrigation Recs) --> E
    E -- Switch Feed -- D
    E -- Share Prompt (Geo-Ref Link) --> F[Agronomist/Operator]

Derivative 1.4: Integration with Emerging Tech - AI-Optimized Real-time Content Moderation & Delivery

  • Enabling Description: The system integrates AI-driven content optimization and real-time moderation. Upon receiving a media message, an AI inference engine (e.g., using a fine-tuned BERT model for text, ResNet for images, or a temporal convolutional network for video) performs sentiment analysis, content classification, and anomaly detection. Expiration information is dynamically adjusted by the AI based on detected trends, virality predictions, or flagging of misinformation, extending or truncating message lifespans. Feed selection is optimized by a reinforcement learning agent that considers user engagement patterns, predicted relevance, and content diversity, creating hyper-personalized "first" and "second" feeds (e.g., "Trending Relevant Content" vs. "Curated Educational Streams"). The sharing prompt integrates with an AI-powered content summarizer, generating a concise textual or audio summary of the media message and the link for sharing, while adhering to platform-specific content policies.
graph TD
    A[Mobile App] -- Submit Media --> B(Servers)
    B -- Store --> C{AI Inference Engine}
    C -- Sentiment/Classification/Anomaly --> D[Dynamic Expiration Adjuster]
    D -- Optimized Selection --> E{Reinforcement Learning Agent}
    E -- Hyper-Personalized Feeds --> F[Feed Provision]
    F -- Provide Feeds --> A
    A -- Share Prompt (AI Summary + Link) --> G[Recipient]

Derivative 1.5: The "Inverse" or Failure Mode - Emergency Broadcast Low-Bandwidth Mode

  • Enabling Description: This derivative defines an operational mode for disaster or network failure scenarios. In the event of detected network degradation (e.g., via real-time QoS monitoring and packet loss thresholds), the "one or more servers" automatically switch to a "low-bandwidth emergency broadcast mode." In this mode, only pre-approved, safety-critical media messages (e.g., evacuation routes, emergency contact info, weather alerts) are selected and provided. These emergency messages are stripped of non-essential metadata, transcoded to ultra-low bitrate formats (e.g., monochrome still images, compressed audio codecs like CELP), and given highest priority, overriding any standard expiration. The "first feed" becomes "Critical Emergency Alerts," and the "second feed" might be "Community Check-ins" (text-only messages). The mobile application, detecting the low-bandwidth mode or an explicit server instruction, switches its UI to a simplified, text-first emergency interface, presenting only essential information. The sharing prompt is simplified to immediately transmit geo-located "I'm Safe" text messages or pre-configured emergency links to local authorities.
stateDiagram-v2
    state Normal_Operation {
        [*] --> High_Bandwidth_Feeds
        High_Bandwidth_Feeds --> Receive_Media
        Receive_Media --> Store_Media
        Store_Media --> Select_Feeds_Normal
        Select_Feeds_Normal --> Provide_Feeds_Normal
    }
    state Emergency_Mode {
        [*] --> Low_Bandwidth_Emergency_Broadcast
        Low_Bandwidth_Emergency_Broadcast --> Prioritize_Emergency_Messages
        Prioritize_Emergency_Messages --> Transcode_Ultra_Low_Bitrate
        Transcode_Ultra_Low_Bitrate --> Provide_Emergency_Feeds
        Provide_Emergency_Feeds --> Display_Simplified_UI
    }

    High_Bandwidth_Feeds --> Low_Bandwidth_Emergency_Broadcast : Network_Degradation_Detected
    Display_Simplified_UI --> High_Bandwidth_Feeds : Network_Recovered

II. Derivatives of Independent Claim 9 (Method - Mobile-Centric Media Generation & Feed Coordination)

Claim 9: A method, comprising: generating a plurality of media messages at one or more mobile applications executable on a corresponding one or more mobile devices, wherein respective ones of the plurality of media messages include an image or video captured by the one or more mobile applications via a corresponding one or more cameras of the corresponding one or more mobile devices; receiving, at one or more servers, the plurality of media messages from the one or more mobile applications; storing the plurality of media messages on the one or more servers, wherein one or more stored media messages are associated with expiration information to determine when the one or more stored media messages can no longer be provided in a feed; selecting, for inclusion in respective ones of a first feed and a second, corresponding ones of a first subset and a second subset of media messages from among the plurality of media messages stored on the one or more servers, wherein the respective selections of the first subset and the second subset of media messages are based at least in part on the expiration information, wherein the second feed differs from the first feed; providing the first feed from the one or more servers to a mobile application executable on a mobile device, the mobile application configured to present the first feed, wherein presentation of the first feed by the mobile application includes presentation of a sharing prompt with a media message included in the first feed, wherein interaction with the sharing prompt via the mobile application facilitates generation of a link configured to enable access to the media message; and providing the second feed from the one or more servers to the mobile application, the mobile application configured to present the second feed, wherein the mobile application is further configured to switch a presentation of the first feed to a presentation of the second feed in response to a user interaction with the mobile application.

Derivative 2.1: Material & Component Substitution - Multi-Sensor Biometric Capture on Mobile

  • Enabling Description: The "one or more cameras" on the mobile device are augmented with integrated biometric sensors (e.g., heart rate variability, galvanic skin response, pupil dilation trackers). The "mobile applications" generate media messages that combine standard video/image capture with real-time biometric data, correlating user emotional state or physiological response to the content being captured or interacted with. This composite media message, including encrypted biometric metadata, is sent to the servers. Expiration information can be tied to the validity of the biometric data or the time-sensitivity of the associated emotional context. Feeds are then selected and presented not only based on media content but also on the user's inferred emotional resonance with past messages or a collective biometric profile of the community. The sharing prompt includes options to share only the visual media, or to include anonymized biometric insights for enhanced contextual sharing, protected by homomorphic encryption for privacy.
sequenceDiagram
    Mobile_Device->>Mobile_App: User Captures Media
    Mobile_App->>Mobile_Device: Integrate Biometric Data (Camera + Sensors)
    Mobile_App->>Server: Send Composite Media (Video + Encrypted Biometrics)
    Server->>Server: Store with Biometric-Tied Expiration
    Server->>Server: Select Feeds (Content + Biometric Resonance)
    Server->>Mobile_App: Provide Feeds
    Mobile_App->>Mobile_Device: Present Feeds
    Mobile_App->>Mobile_Device: User Interacts with Sharing Prompt
    Mobile_Device->>Mobile_App: Share (Visual Only OR Anonymized Biometrics)

Derivative 2.2: Operational Parameter Expansion - Microscopic/Macroscopic Spectral Imaging Stream

  • Enabling Description: The "one or more cameras" are specialized, user-attachable or integrated mobile cameras capable of either micro-scale (e.g., cellular level, requiring a micro-lens attachment) or macro-scale (e.g., wide-field astronomical, requiring a telephoto/spectral filter attachment) spectral imaging. Media messages generated include imagery across non-visible spectra (e.g., UV, IR) or with extreme magnification/field-of-view. These messages are captured with high temporal resolution (e.g., 1000+ FPS for microscopic processes or minute-by-minute for astronomical events). Servers store these large spectral datasets, and expiration information is tied to the ephemeral nature of the phenomena observed (e.g., cell division cycles, transient astronomical events). A "first feed" could be "Live Cellular Dynamics," and a "second feed" "Astronomy Transient Alerts." The mobile application, with specialized rendering capabilities, presents these feeds, allowing users to switch between scales and spectral views. The sharing prompt generates links to specific scientific observations with embedded spectral data for collaborative analysis.
graph TD
    A[Mobile Device (Micro/Macro Camera)] -- High-Res Spectral Imaging --> B(Mobile App)
    B -- Transmit (Large Datasets) --> C(Specialized Servers)
    C -- Store & Process (Spectral/Temporal) --> D{Phenomena Expiration Engine}
    D -- Select Feed 1 (Cell Dynamics) --> E[Mobile App]
    D -- Select Feed 2 (Astronomy Alerts) --> E
    E -- Switch Feed -- D
    E -- Share Prompt (Spectral Data Link) --> F[Researcher/Collaborator]

Derivative 2.3: Cross-Domain Application - Remote Diagnostic Telemedicine Stream

  • Enabling Description: "Mobile devices" are ruggedized tablets or handheld diagnostic tools (e.g., otoscopes, dermatoscopes) with integrated high-resolution cameras, operated by field medics or patients. "Media messages" consist of streaming video of patient symptoms (e.g., wound progression, dermatological conditions) or live endoscopic views captured by the camera. These streams are secured and transmitted to "one or more servers" residing within a healthcare cloud. Expiration information is tied to diagnostic urgency or treatment plan milestones. A "first feed" might be "Urgent Cases for Review," prioritized by severity and age of data. A "second feed" could be "Chronic Condition Monitoring," showing longitudinal patient data. A consulting physician, via a secure mobile application, switches between these feeds. The sharing prompt generates a HIPAA-compliant, time-limited link to a specific patient's diagnostic stream for a specialist consultation, with explicit consent management.
graph TD
    A[Patient/Field Medic (Mobile Device w/ Diagnostic Camera)] -- Encrypted Live Medical Media --> B(Healthcare Cloud Servers)
    B -- Store & Process (HIPAA Compliant) --> C{Diagnostic Urgency Engine}
    C -- Expiration Logic (Severity/Milestone) --> D[Feed Selection for Physicians]
    D -- Provide Feed 1 (Urgent Cases) --> E[Consulting Physician App]
    D -- Provide Feed 2 (Chronic Monitoring) --> E
    E -- Switch Feed -- D
    E -- Share Prompt (Time-Limited HIPAA Link) --> F[Specialist Physician]

Derivative 2.4: Integration with Emerging Tech - Context-Aware AR/VR Media Generation & Metaverse Integration

  • Enabling Description: "Mobile applications" on AR/VR-capable mobile devices (e.g., smart glasses, spatial computing headsets) generate "media messages" that are not merely 2D images/videos but spatially-aware, augmented reality overlays or volumetric captures of real-world environments. These messages are enriched with context from integrated spatial sensors (LiDAR, IMUs). An embedded AI on the device performs real-time object recognition and semantic segmentation during capture. When sent to "one or more servers" (now a distributed Metaverse content mesh), these messages carry metadata specifying their spatial anchor points, interaction affordances, and volumetric data. Expiration information can be tied to the decay of physical phenomena, relevance to dynamic virtual events, or user-defined persistence. Feeds are presented as navigable AR/VR spaces, dynamically loading relevant volumetric media. A "first feed" could be "Live Collaborative Design," and a "second feed" "Historical Site Reconstructions." The sharing prompt generates a deep link to a specific spatial coordinate within the Metaverse, allowing others to experience the AR content in its intended spatial context or collaboratively annotate it.
graph TD
    A[AR/VR Mobile Device] -- Spatial Capture (Volumetric + AI Context) --> B(Mobile App)
    B -- Upload (Volumetric Data + Metadata) --> C(Metaverse Content Mesh Servers)
    C -- Store (Spatial DB) --> D{Dynamic Expiration & Relevance Engine}
    D -- Select Feeds (Spatial/Temporal) --> E[AR/VR Mobile App]
    E -- Present Feeds (Navigable AR/VR Spaces) --> A
    A -- Share Prompt (Metaverse Deep Link) --> F[Other Metaverse Users]

Derivative 2.5: The "Inverse" or Failure Mode - Privacy-Preserving Placeholder Media & Delayed Delivery

  • Enabling Description: In a "privacy-preserving placeholder mode" activated when sensitive content is detected (e.g., via on-device AI for facial recognition, document scanning, or user explicit flagging) or network security is compromised (e.g., insecure Wi-Fi, detected surveillance), the "mobile application" automatically generates a "placeholder media message." This placeholder consists of a cryptographically hashed representation of the original image/video, along with a blurred or pixelated preview, and a notification of delayed delivery. The actual original media message is then encrypted on-device (e.g., using E2E encryption) and stored locally, only to be transmitted when a secure network connection is re-established or explicit user consent for less secure transmission is given. The "expiration information" for the placeholder might be a reminder to review or securely transmit the original content. Feeds provided by the server will initially display these placeholders. The sharing prompt for a placeholder offers options for "Request Original Content" (triggering an encrypted transfer request upon re-establishing security) or "Share Placeholder Only" to maintain privacy.
stateDiagram-v2
    state Normal_Capture {
        [*] --> Capture_Media_Original
        Capture_Media_Original --> Encrypt_Transmit_Immediately
    }
    state Privacy_Mode {
        [*] --> Detect_Sensitive_Content
        Detect_Sensitive_Content --> Generate_Placeholder
        Generate_Placeholder --> Encrypt_Store_Locally
        Encrypt_Store_Locally --> Transmit_Placeholder_To_Server
    }

    Encrypt_Transmit_Immediately --> Server_Receive_Store
    Transmit_Placeholder_To_Server --> Server_Receive_Store_Placeholder

    Server_Receive_Store_Placeholder --> Mobile_App_Present_Placeholder_Feed
    Mobile_App_Present_Placeholder_Feed --> User_Request_Original : Secure_Connection_Available
    User_Request_Original --> Transmit_Original_Securely
    Transmit_Original_Securely --> Server_Update_With_Original
    Server_Update_With_Original --> Mobile_App_Present_Original_Feed

    Mobile_App_Present_Placeholder_Feed --> User_Share_Placeholder : Share_Prompt_Interaction

III. Derivatives of Independent Claim 16 (System - Server-Centric Media Feed Coordination)

Claim 16: A system, comprising: one or more servers including memory, machine-readable instructions, and one or more processors, the one or more processors configured to execute the machine-readable instructions to perform operations comprising: receiving, at the one or more servers, a plurality of media messages from one or more mobile applications executable on a corresponding one or more mobile devices; storing the plurality of media messages on the one or more servers, wherein one or more stored media messages are associated with expiration information to determine when the one or more stored media messages can no longer be provided in a feed; selecting, for inclusion in respective ones of a first feed and a second, corresponding ones of a first subset and a second subset of media messages from among the plurality of media messages stored on the one or more servers, wherein the respective selections of the first subset and the second subset of media messages are based at least in part on the expiration information, wherein the second feed differs from the first feed; providing the first feed from the one or more servers to a mobile application executable on a mobile device, the mobile application configured to present the first feed, wherein presentation of the first feed by the mobile application includes presentation of a sharing prompt with a media message included in the first feed, wherein interaction with the sharing prompt via the mobile application facilitates generation of a link configured to enable access to the media message; and providing the second feed from the one or more servers to the mobile application, the mobile application configured to present the second feed, wherein the mobile application is further configured to switch a presentation of the first feed to a presentation of the second feed in response to a user interaction with the mobile application.

Derivative 3.1: Material & Component Substitution - Quantum Computing-Enabled Content Processing Unit

  • Enabling Description: The "one or more processors" within the servers include a hybrid computing architecture incorporating a quantum processing unit (QPU) alongside classical CPUs/GPUs. The QPU is specifically configured to execute quantum algorithms for ultra-fast pattern matching and probabilistic filtering of media messages during selection. Media message metadata, including complex expiration information (e.g., multi-dimensional relevance vectors with quantum state decay probabilities), is stored in quantum-resistant memory. The QPU's operations enable the selection of optimal subsets for the first and second feeds at speeds and complexities unattainable by classical systems, especially for highly dynamic, large-scale datasets where traditional expiration logic might be computationally prohibitive. The machine-readable instructions include quantum circuits for feed optimization. The provision of feeds and generation of sharing links are managed by the classical components, interfacing with the QPU for rapid decision-making on content relevance and expiry.
graph TD
    A[Mobile App] -- Submit Media --> B(Hybrid Server System)
    B -- Classical Processor --> C{QPU Interface}
    C -- Quantum Algorithms (Pattern Matching, Probabilistic Filtering) --> D[Quantum Processing Unit (QPU)]
    D -- Optimal Subset Selection (Complex Expiration) --> E{Feed Generation Engine}
    E -- Classical Processor --> F[Feed Provision & Link Generation]
    F -- Provide Feeds --> A
    A -- Share Prompt --> F

Derivative 3.2: Operational Parameter Expansion - Cryogenic Data Center for Hyper-Archival and Instantaneous Recall

  • Enabling Description: The "one or more servers" are housed within a cryogenic data center operating at near-absolute-zero temperatures. This extreme environment enables the use of superconducting memory and processors, allowing for ultra-dense media storage (e.g., petabytes per cubic centimeter) and virtually instantaneous data recall and processing. Media messages, potentially spanning exabytes, are hyper-archived without degradation for millennia. Expiration information, while present, can be overridden by specialized "temporal recall" protocols that allow reconstruction of feeds from any point in the past with nanosecond latency. The "first feed" could be "Current Live Stream," while the "second feed" is "Historical Replay Stream from [specific past date/time]," both rendered and streamed with minimal delay due to the cryogenic architecture. The sharing prompt can generate a link to a specific moment within a historical stream, enabling precise deep dives into archival media content.
graph TD
    A[Mobile App] -- Submit Media --> B(Cryogenic Data Center)
    B -- Superconducting Memory/Processors --> C{Hyper-Archival System}
    C -- Exabyte-Scale Storage --> D[Temporal Recall & Expiration Engine]
    D -- Instantaneous Selection (Current/Historical) --> E[Feed Generation]
    E -- Provide Feed 1 (Live) --> F[Mobile App]
    E -- Provide Feed 2 (Historical) --> F
    F -- Switch Feed -- D
    F -- Share Prompt (Archival Deep Link) --> G[External User]

Derivative 3.3: Cross-Domain Application - Spacecraft Fleet Command & Control System

  • Enabling Description: The "system" functions as a command and control platform for a fleet of autonomous spacecraft (the "mobile devices"). The "one or more servers" are located on an orbital station or a deep-space ground control center. "Media messages" are telemetry data streams, diagnostic videos, and operational status reports from the spacecraft's internal cameras and sensors. Expiration information for these messages is tied to mission-critical timelines, fuel cell degradation schedules, or celestial event windows. A "first feed" ("Mission Critical Alerts") displays urgent anomalies and required interventions, while a "second feed" ("Routine System Diagnostics") provides long-term health monitoring. Mission specialists, interacting with the mobile application (a ruggedized console) on Earth or within the orbital station, can switch between these feeds. The sharing prompt generates secure, authenticated links to specific telemetry plots or diagnostic video segments for review by specialized engineers or autonomous decision-making AI systems.
graph TD
    A[Autonomous Spacecraft] -- Telemetry/Diagnostic Media --> B(Orbital Station/Ground Control Servers)
    B -- Store & Process (Mission DB) --> C{Mission Criticality Engine}
    C -- Expiration Logic (Mission Timelines/Events) --> D[Feed Selection for Specialists]
    D -- Provide Feed 1 (Critical Alerts) --> E[Mission Specialist Console App]
    D -- Provide Feed 2 (Routine Diagnostics) --> E
    E -- Switch Feed -- D
    E -- Share Prompt (Secure Telemetry Link) --> F[Specialized Engineer/AI]

Derivative 3.4: Integration with Emerging Tech - IoT Sensor Network Management with Blockchain for Data Integrity

  • Enabling Description: The "system" is an IoT sensor network management platform. "Mobile devices" are geographically distributed IoT sensor nodes (e.g., environmental monitors, smart city infrastructure sensors) transmitting data via low-power wide-area networks (LPWAN). "Media messages" are encoded sensor readings (e.g., particulate matter levels, traffic density video snippets, structural integrity acoustic data). The "one or more servers" form an IoT data lake and processing hub. Each media message is hashed and timestamped, with the hash committed to a blockchain for immutable proof of origin and integrity. Expiration information is enforced by smart contracts on the blockchain, defining how long data remains "active" in a feed based on regulatory compliance, environmental thresholds, or historical data retention policies. A "first feed" is "Real-time Anomaly Detection," showcasing sensor readings exceeding thresholds. A "second feed" is "Historical Trends Analysis." The mobile application (e.g., smart city dashboard) presents these feeds. The sharing prompt generates a blockchain-verified link to a specific sensor's data stream, providing irrefutable proof of the data's state at a particular time.
graph TD
    A[IoT Sensor Nodes] -- Encoded Sensor Readings --> B(IoT Data Lake Servers)
    B -- Hash & Timestamp --> C{Blockchain Ledger (Data Integrity)}
    C -- Store Media & Commit Hash --> D[Smart Contract (Expiration/Retention)]
    D -- Select Feed 1 (Anomalies) --> E[Smart City Dashboard App]
    D -- Select Feed 2 (Historical Trends) --> E
    E -- Switch Feed -- D
    E -- Share Prompt (Blockchain-Verified Link) --> F[Regulator/Auditor]

Derivative 3.5: The "Inverse" or Failure Mode - Server-Side Malware Containment & Remediation Feed

  • Enabling Description: The "system" is specifically designed to operate as a cybersecurity incident response platform, where "media messages" are threat intelligence reports, malware analysis videos, or compromised system logs generated by automated security agents (the "mobile applications") across an enterprise network. In a "failure mode" where a high-severity malware outbreak is detected, the "one or more servers" automatically shift to a "containment and remediation feed" protocol. Expiration information for threat data is dynamically prioritized based on exploit recency and propagation speed. A "first feed" ("Active Threat Detections") is populated with real-time, high-priority threats, immediately triggering automated containment actions. A "second feed" ("Remediation Progress") shows the status of cleanup efforts and system patches. The sharing prompt, in this mode, generates an encrypted, time-limited link to a specific malware analysis report for a human analyst, along with automated recommendations for mitigation, with all actions logged immutably.
stateDiagram-v2
    state Normal_Operation {
        [*] --> Regular_Threat_Intelligence
        Regular_Threat_Intelligence --> Store_Threat_Data
        Store_Threat_Data --> Analyze_Threats_Normal
        Analyze_Threats_Normal --> Generate_Info_Feeds
    }
    state Malware_Outbreak_Mode {
        [*] --> Detect_Malware_Outbreak
        Detect_Malware_Outbreak --> Shift_to_Containment_Protocol
        Shift_to_Containment_Protocol --> Prioritize_Threat_Expiration
        Prioritize_Threat_Expiration --> Auto_Containment_Actions
        Prioritize_Threat_Expiration --> Generate_Remediation_Feeds
    }

    Regular_Threat_Intelligence --> Detect_Malware_Outbreak : High_Severity_Outbreak
    Generate_Remediation_Feeds --> Human_Analyst_App : Provide_Feeds
    Human_Analyst_App --> Generate_Remediation_Feeds : Share_Encrypted_Report

IV. Derivatives of Independent Claim 24 (System - Mobile + Server Media Generation & Feed Coordination)

Claim 24: A system, comprising: one or more mobile applications executable on a corresponding one or more mobile devices, the one or more mobile applications configured to create a plurality of media messages, wherein respective ones of the plurality of media messages include an image or video captured via a corresponding one or more cameras of the corresponding one or more mobile devices; and one or more servers including memory, machine-readable instructions, and one or more processors, the one or more processors configured to execute the machine-readable instructions to perform operations comprising: receiving, at the one or more servers, the plurality of media messages from the one or more mobile applications; storing the plurality of media messages on the one or more servers, wherein one or more stored media messages are associated with expiration information to determine when the one or more stored media messages can no longer be provided in a feed; selecting, for inclusion in respective ones of a first feed and a second, corresponding ones of a first subset and a second subset of media messages from among the plurality of media messages stored on the one or more servers, wherein the respective selections of the first subset and the second subset of media messages are based at least in part on the expiration information, wherein the second feed differs from the first feed; providing the first feed from the one or more servers to a mobile application executable on a mobile device, the mobile application configured to present the first feed, wherein presentation of the first feed by the mobile application includes presentation of a sharing prompt with a media message included in the first feed, wherein interaction with the sharing prompt via the mobile application facilitates generation of a link configured to enable access to the media message; and providing the second feed from the one or more servers to the mobile application, the mobile application configured to present the second feed, wherein the mobile application is further configured to switch a presentation of the first feed to a presentation of the second feed in response to a user interaction with the mobile application.

Derivative 4.1: Material & Component Substitution - Bio-Integrated Mobile Sensor Array & Liquid-Cooled Server Rack

  • Enabling Description: The "one or more mobile devices" are bio-integrated wearables with embedded cameras and sensor arrays that can capture physiological (e.g., real-time glucose levels, EEG brainwave patterns) and environmental data, forming "media messages" as multimodal streams. These devices utilize flexible, biocompatible polymer substrates. The "one or more servers" comprise liquid-cooled server racks for extreme thermal efficiency, enabling continuous, high-density processing of incoming bio-sensor data streams. The server's memory uses phase-change materials for non-volatile, high-speed storage of physiological profiles. Expiration information for media messages is dynamically determined by the physiological relevance (e.g., a critical blood pressure alert expires upon normalization) or legal retention policies for health data. A "first feed" is "Personal Health Alerts," and a "second feed" "Environmental Health Trends." The sharing prompt generates a highly granular, permission-controlled link to specific bio-data segments, intended for medical professionals or approved AI health assistants, adhering to advanced data minimization principles.
graph TD
    A[Bio-Integrated Wearable] -- Multimodal Physiological/Environmental Data --> B(Mobile App)
    B -- Transmit (High-Density Stream) --> C(Liquid-Cooled Server Rack)
    C -- Phase-Change Memory Storage --> D{Physiological Relevance Engine}
    D -- Dynamic Expiration Logic --> E[Feed Selection for User/Pro]
    E -- Provide Feed 1 (Health Alerts) --> B
    E -- Provide Feed 2 (Env. Trends) --> B
    B -- Switch Feed --> E
    B -- Share Prompt (Permission-Controlled Bio-Data Link) --> F[Medical Professional/AI Assistant]

Derivative 4.2: Operational Parameter Expansion - Planetary-Scale Interplanetary Communication System

  • Enabling Description: This system operates at an interplanetary scale. "Mobile devices" are rover-mounted cameras and science instruments on Mars or other celestial bodies, transmitting "media messages" (e.g., geological panoramas, atmospheric composition videos) across vast distances. The "one or more servers" form a distributed network across Earth-based deep-space communication arrays and relay satellites in orbit around the target planet. Data transmission occurs at extremely low frequencies and bandwidths (requiring advanced error correction and compression) with inherent multi-hour communication delays. Expiration information for media messages is tied to astronomical events (e.g., solar flares disrupting communication, orbital mechanics opening/closing transmission windows) or mission scientific objectives. A "first feed" could be "Rover Hazard Detections" (critical for navigation), and a "second feed" "Geological Survey Imagery" (for scientific analysis). The mobile application (ground control console) on Earth presents these feeds, accounting for latency. The sharing prompt generates a link to a specific geolocated planetary image or data point, with a timestamp corrected for light-travel time.
graph TD
    A[Mars Rover Camera] -- Ultra-Compressed/Error-Corrected Media (Low Freq.) --> B(Interplanetary Network)
    B -- Deep-Space Arrays/Relay Sats --> C(Earth-Based Servers)
    C -- Store (Astronomical/Mission DB) --> D{Interplanetary Expiration Engine}
    D -- Select Feeds (Astro-Event/Mission Objective) --> E[Ground Control Console App]
    D -- Latency Compensation --> E
    E -- Switch Feed -- D
    E -- Share Prompt (Light-Time Corrected Link) --> F[Planetary Scientist]

Derivative 4.3: Cross-Domain Application - Smart Factory Floor Visual Inspection & Maintenance System

  • Enabling Description: In a smart manufacturing context, "mobile devices" are robotic arms with integrated high-speed cameras or handheld augmented reality devices carried by technicians. "Mobile applications" on these devices capture "media messages" consisting of real-time visual inspection footage of assembly lines, component defect videos, or holographic maintenance instructions. The "one or more servers" are an on-premise industrial edge computing cluster. Expiration information for these messages is tied to production batch numbers, quality control thresholds, or scheduled maintenance windows. A "first feed" is "Critical Defect Alerts," immediately flagging major production issues. A "second feed" is "Preventative Maintenance Schedule," displaying upcoming robot servicing. A factory manager or maintenance technician, via a ruggedized tablet or AR headset, switches between these feeds. The sharing prompt generates a link to a specific defect video, overlaid with CAD data, for root cause analysis by engineers or for documentation for regulatory compliance.
graph TD
    A[Robotic Arm/AR Device (Camera)] -- Real-time Inspection/Defect Media --> B(Mobile App)
    B -- Upload (Video + Metadata) --> C(Industrial Edge Cluster Servers)
    C -- Store & Process (Production DB) --> D{Quality/Maintenance Expiration Engine}
    D -- Select Feed 1 (Critical Defects) --> E[Factory Manager/Tech App]
    D -- Select Feed 2 (PM Schedule) --> E
    E -- Switch Feed -- D
    E -- Share Prompt (CAD Overlay Link) --> F[Engineer/Compliance]

Derivative 4.4: Integration with Emerging Tech - Decentralized AI-Driven Content Curation with Federated Learning

  • Enabling Description: The "system" uses decentralized AI for content curation. "Mobile applications" on mobile devices collect user interaction data (e.g., viewing duration, scrolling patterns, explicit likes/dislikes) on media messages. Instead of sending raw user data, these apps train local AI models (e.g., recommender systems) and contribute aggregated model updates to a central server via federated learning. The "one or more servers" orchestrate this federated learning process, iteratively improving a global AI model for content relevance and preference prediction without accessing individual user data. Expiration information for media messages can be dynamically re-evaluated by this global AI based on collective (privacy-preserved) engagement signals, extending the lifespan of highly relevant content or quickly expiring non-engaging material. The "first feed" is "Community-Curated Trending Content," and the "second feed" is "Niche Interest Deep Dives," both powered by the federated AI. The sharing prompt integrates with smart contracts, allowing users to earn micro-rewards (e.g., cryptocurrency tokens) for sharing content that subsequently garners high engagement, incentivizing high-quality curation.
sequenceDiagram
    participant M as Mobile Device
    participant S as Server
    participant B as Blockchain

    M->>M: User Views Media
    M->>M: Local AI Model Update (Engagement Data)
    M->>S: Upload Encrypted Model Update (Federated Learning)
    S->>S: Aggregate Model Updates
    S->>S: Global AI Model Refinement
    S->>S: Dynamic Expiration (Collective Engagement)
    S->>M: Provide Feeds (AI-Curated)
    M->>M: User Shares Content
    M->>B: Smart Contract Invocation (Share Reward)

Derivative 4.5: The "Inverse" or Failure Mode - Context-Dependent Ethical Data Minimization Mode

  • Enabling Description: The "system" incorporates an ethical data minimization mode. "Mobile applications" on "mobile devices" utilize on-device context awareness (e.g., location, time of day, presence of sensitive individuals identified via local AI, user-defined privacy zones) to determine the "sensitivity" of captured media. In a detected "high sensitivity" context, the mobile application automatically applies data minimization techniques to generated "media messages" before transmission. This could involve automatic redaction of faces, removal of GPS metadata, transcoding to lower resolution/bitrate formats, or converting video to a series of still images, prioritizing text over rich media. The "one or more servers" are configured to process these minimized messages, associating them with "ethical expiration information" which dictates strict deletion policies (e.g., immediate deletion after 24 hours unless explicit multi-party consent for retention is provided). A "first feed" could be "Public Anonymized Updates," containing only ethically minimized content, while a "second feed" would be "Private Encrypted Discussions" (only accessible by explicitly authorized parties with zero-knowledge proof of access). The sharing prompt strictly enforces the original minimization settings and requires explicit double-opt-in from all potential recipients for any de-anonymization request.
stateDiagram-v2
    state Normal_Capture {
        [*] --> Capture_Rich_Media
        Capture_Rich_Media --> Transmit_Full_Resolution
    }
    state Ethical_Minimization_Mode {
        [*] --> Detect_High_Sensitivity_Context
        Detect_High_Sensitivity_Context --> Apply_Data_Minimization (Redaction/Metadata_Removal)
        Apply_Data_Minimization --> Generate_Minimized_Media
        Generate_Minimized_Media --> Transmit_Minimized_Media_to_Server
        Transmit_Minimized_Media_to_Server --> Server_Process_Ethical_Expiration
    }

    Transmit_Full_Resolution --> Server_Process_Normal
    Server_Process_Normal --> Provide_Standard_Feeds

    Server_Process_Ethical_Expiration --> Provide_Minimized_Feeds
    Provide_Minimized_Feeds --> Mobile_App_Present_Minimized_Content

    Mobile_App_Present_Minimized_Content --> Share_Prompt_Enforce_Minimization

V. Combination Prior Art Scenarios with Open-Source Standards

These scenarios describe how the concepts of US Patent 12,112,357 could be combined with existing open-source standards to demonstrate obviousness or enhance functionality in publicly available systems.

1. Content Feeds with ActivityPub and WebSub for Decentralized Social Media

  • Scenario Description: Implement the core feed coordination mechanism (receiving, storing with expiration, selecting first/second feeds, providing to mobile app with sharing) using ActivityPub for content distribution and WebSub for real-time feed updates.
  • Open-Source Standard Integration:
    • ActivityPub (W3C standard): Used for creating and delivering "media messages" (Activities) between federated "mobile applications" (Actors). Each media message would be an Activity Stream object with embedded published and custom expires fields. The "one or more servers" would function as an ActivityPub server, handling Inbox and Outbox interactions.
    • WebSub (W3C standard): Used by the server to push real-time updates (new media messages, expiration events) to subscribing "mobile applications" (Hubs and Subscribers). This efficiently provides the "first feed" and "second feed" updates without constant polling, and allows for dynamic switching between feeds by changing subscription topics or filtering on the client.
  • Obviousness/Prior Art Claim: Combining the well-established decentralized content distribution of ActivityPub with the real-time push capabilities of WebSub to manage and present time-sensitive media feeds on mobile devices would be an obvious architectural decision for a PHOSITA seeking to build a resilient, scalable, and decentralized social media or event coordination platform.

2. Live Streaming with HLS/DASH and OpenTelemetry for Observability and Expiration

  • Scenario Description: Implement the streaming media aspects of the patent (e.g., live streaming media files as per description, col. 6, lines 52-54) for the "media messages" using standard HTTP Live Streaming (HLS) or Dynamic Adaptive Streaming over HTTP (DASH), coupled with OpenTelemetry for monitoring and dynamic expiration.
  • Open-Source Standard Integration:
    • HLS/DASH (ISO/IEC standard, Apple standard): Media messages are segmented into small, HTTP-based files (e.g., .ts for HLS, .mpd for DASH) with associated manifest files. The "one or more servers" act as an HLS/DASH origin server and packager. Expiration information for entire streams or individual segments can be embedded in the manifest files (e.g., EXT-X-ENDLIST for live stream termination, or custom tags for segment-level expiry).
    • OpenTelemetry (CNCF standard): End-to-end observability is achieved by instrumenting the mobile application, server-side media processors, and content delivery network (CDN) with OpenTelemetry agents. Metrics (e.g., segment delivery success, buffering rates, viewer count) and traces (e.g., media message processing pipeline) are collected. This data dynamically informs the "expiration information" of a stream (e.g., a stream with zero active viewers for an extended period automatically expires) and optimizes feed selection based on network conditions reported.
  • Obviousness/Prior Art Claim: Using industry-standard adaptive bitrate streaming protocols like HLS or DASH for delivering media, and enhancing server-side content lifecycle management (including "expiration information") with a comprehensive observability framework like OpenTelemetry for dynamic monitoring and event-driven content termination, represents a standard engineering practice for robust streaming platforms.

3. User-Generated Content Workflow with GNU FFMPEG and Nextcloud for Storage and Feed Management

  • Scenario Description: Establish a system for user-generated media content submission, transcoding, storage, and feed presentation using FFMPEG for media processing and Nextcloud as a self-hosted cloud platform.
  • Open-Source Standard Integration:
    • GNU FFMPEG (GPL/LGPL licensed): When "mobile applications" submit "media messages" (e.g., raw video files), the "one or more servers" utilize FFMPEG for robust transcoding, format normalization (e.g., to h.264 mp4 as mentioned in the patent), thumbnail generation, and adaptive bitrate ladder creation. This ensures compatibility and efficient streaming.
    • Nextcloud (AGPL licensed): The "one or more servers" are implemented as a Nextcloud instance. Nextcloud's file storage, user management, and plugin architecture (e.g., for custom feed generation apps) are used. Media messages are stored in user directories. Custom metadata fields in Nextcloud's database can store "expiration information." Feeds are generated by a Nextcloud app that queries the database, selects content, and presents it through web-based interfaces or dedicated mobile clients, enabling "first" and "second" feeds based on custom tags or folder structures. Nextcloud's built-in sharing mechanisms directly implement the "sharing prompt" functionality.
  • Obviousness/Prior Art Claim: Building a user-generated content platform by leveraging a mature media processing library like FFMPEG for all necessary video/audio manipulation, combined with a comprehensive, extensible open-source cloud platform like Nextcloud for storage, user management, and custom application development (including content feeds with expiration logic), would be a straightforward and obvious approach for a PHOSITA in designing such a system.

Generated 5/28/2026, 1:57:57 PM