US 12112357

Patent Summary: US 12,112,357

Title: Mobile device streaming media application

Assignee: Weple IP Holdings LLC

Inventor: Mary Anne Fletcher

Filing Date: January 25, 2024

Issue Date: October 8, 2024

Abstract: A system and process for coordinating streaming content or messages is provided. A network-connected server maintains a database containing media content-related data, such as the text of a message, accompanying media, time of airing, payment, and related comments. A user can view these feeds or streams of these consciousness messages by downloading a mobile application or browsing to a website. The application can also be used to create, schedule, and pay for a media content message.

Plain-Language Overview of Independent Claims:

Independent Claim 1: This claim describes a method for servers to manage and distribute media messages to a mobile application. The servers receive multiple media messages, store them with expiration dates, and then select different subsets of these messages to create at least two distinct feeds. The mobile app can display one feed and then switch to another based on user interaction. When a feed is displayed, it includes a "sharing" option for a media message, which, when used, creates a link to access that message.

Independent Claim 9: This claim outlines a similar method, but it starts with the creation of the media messages on mobile devices. Specifically, it states that the media messages include an image or video captured by the mobile device's camera. The rest of the process is identical to claim 1: the messages are sent to servers, stored with expiration information, sorted into at least two different feeds, and provided to a mobile app that can switch between them and has a sharing function.

Independent Claim 16: This claim describes the server system that performs the method outlined in claim 1. It details a system with one or more servers equipped with memory and processors. These servers are configured to receive and store media messages with expiration data, select messages for at least two different feeds, and provide these feeds to a mobile application. The mobile application is designed to present the feeds and allow a user to switch between them and to share media messages via a link.

Independent Claim 24: This claim covers the entire system, including both the mobile application and the servers. It describes one or more mobile apps capable of creating media messages containing images or videos from the device's camera. It then describes the server-side operations, which are identical to those in claim 16: receiving, storing, and organizing the messages into different feeds for the mobile app, which can then present the feeds with sharing and switching functionalities.

Litigation and Legal Status:

US Patent 12,112,357, assigned to Weple IP Holdings LLC, was involved in litigation against Meta Platforms (Case No. 2:24-cv-01316) in the Western District of Washington. The lawsuit, which also involved other patents from the same family, alleged infringement by Meta's Facebook and Instagram platforms. The case was ultimately dismissed with prejudice on January 9, 2026, a decision favorable to Meta Platforms.

Additionally, there is a related appeal in the U.S. Court of Appeals for the Federal Circuit (CAFC), case number 26-1476, filed on February 26, 2026, with Weple IP Holdings LLC as the plaintiff and Meta Platforms, Inc. as the defendant. This suggests an appeal of the district court's decision. Other patents in the same family have also faced challenges, including an ex parte reexamination proceeding initiated by Unified Patents for U.S. Patent 11,734,739, which is part of the same patent family as 12,112,357.

As a patent attorney, I can report the following known litigation involving US patent 12,112,357.

District Court Litigation

Weple IP Holdings LLC v. [Meta Platforms Inc.](/litigations/by-plaintiff/Meta%20Platforms%20Inc.)

• Plaintiff(s): Weple IP Holdings LLC
• Defendant(s): Meta Platforms Inc.
• Jurisdiction: U.S. District Court for the Western District of Washington
• Case Number: 2:24-cv-01316
• Filing Date: The case was active from approximately August 2024 to January 2026.
• Outcome/Current Status: The case was dismissed with prejudice on January 9, 2026, resulting in a win for the defendant, Meta Platforms Inc. This dismissal permanently bars Weple IP Holdings from re-asserting the same claims from this case against Meta. The lawsuit involved six patents, including US patent 12,112,357 B2, which relates to computing architectures for social media.

Patent Trial and Appeal Board (PTAB) Proceedings

Based on the information available in the patent's file history, a case was filed at the Patent Trial and Appeal Board.

• Case Number: IPR2026-00079
• Status: The proceeding was "Not Instituted - Procedural." This indicates that a trial to review the patentability of the claims was not initiated.

At present, no other litigation involving US patent 12,112,357 is publicly known.

Based on the provided information and public records concerning US patent 12,112,357, here is an analysis of all AIA trial proceedings on file.

Proceedings overview

There has been one AIA trial proceeding filed against US patent 12,112,357. That proceeding, an Inter Partes Review (IPR), was discretionarily denied at the institution stage and did not proceed to a trial on the merits. This means the patent has survived its only PTAB challenge to date, but because the denial was procedural and not based on the substance of the prior art, the patent has not been "hardened" by the proceeding, and the petitioner is not estopped from re-asserting the same invalidity grounds in other venues.

---

IPR2026-00079 — Meta Platforms, LLC v. Weple IP Holdings LLC

• Type: Inter Partes Review
• Filed: 2025-10-31
• Status: Discretionary Denial. The Patent Trial and Appeal Board (PTAB) declined to institute a trial, meaning the case was dismissed before a formal review of the merits of the invalidity arguments could begin. This was a procedural denial, not a decision that the patent claims were valid over the asserted prior art.
• Judge panel: I do not have access to the specific judge panel for this proceeding. This information would be available in the papers filed for this case on the USPTO's PTAB E2E portal.
• Petition grounds: I do not have access to the specific claims challenged or the prior art asserted in the petition. This information would be detailed in the petition document, which is typically available on the USPTO's PTAB E2E portal for the corresponding proceeding number.
• Institution decision: The petition was denied institution on 2026-04-06. According to the provided patent data, the reason was procedural. These types of discretionary denials often occur when there is a co-pending district court litigation between the same parties concerning the same patent. Under the Fintiv framework, the PTAB may decline to institute an IPR if the parallel court case is sufficiently advanced, in order to avoid duplicative efforts and the potential for conflicting outcomes.
• Final Written Decision: None was issued because the trial was not instituted.
• Settlement / termination: The proceeding was terminated by the PTAB's denial of institution, not by a settlement between the parties.
• Appeal: A petitioner cannot appeal a non-institution decision to the Federal Circuit. Therefore, there was no appeal.
• Defensive value: This proceeding provides limited defensive value. While the patent survived, it was not tested on the merits. The specific prior art and arguments raised by Meta in its petition are publicly available and can be evaluated and potentially used by other defendants. Crucially, because institution was denied, the petitioner (Meta) and its privies are not subject to statutory estoppel under 35 U.S.C. § 315(e)(2), leaving them free to raise the same invalidity grounds again in district court.

Strategic summary

No claims of US patent 12,112,357 have been canceled or substantively validated by the PTAB. All 30 claims of the patent remain untested in an AIA trial. The sole IPR filed against the patent was terminated at the earliest possible stage due to a discretionary, procedural denial.

The estoppel landscape for this patent is currently clear. Because IPR2026-00079 was not instituted, no statutory estoppel applies. A defendant currently facing assertion of this patent, including Meta Platforms, is free to challenge the patent's validity in district court or at the PTAB using any available prior-art grounds, including those that may have been raised in the denied IPR petition.

The pattern of activity indicates that the patent is being asserted by a patent licensing entity (Weple IP Holdings LLC) against a major technology company (Meta), which is a common scenario for patent litigation. The fact that an IPR was filed and discretionarily denied suggests there is active, parallel district court litigation (as indicated by the reference to a case in the Western District of Washington in the patent data source). Defendants should investigate the status of that litigation, as it will likely inform the patent owner's strategy and timelines.

Recommended next steps

For a defendant facing a demand letter citing US patent 12,112,357, the key takeaway is that the patent's validity has not been confirmed by the USPTO in a contested proceeding.

• Review the IPR File Wrapper: The most critical next step is to obtain and analyze the complete file for IPR2026-00079 from the USPTO's PTAB E2E portal. The petition will detail Meta's invalidity arguments and the asserted prior art, providing a well-researched starting point for your own validity analysis.
• Analyze the Denial Decision: The Decision Denying Institution, likely issued on or around 2026-04-06, should be reviewed carefully. It will explain the specific procedural reasons for the denial. If it was a Fintiv-based denial, the decision will provide insight into the status of the parallel district court case, which is valuable intelligence.
• No Claims Invalidated: Be aware that the patent owner may characterize this outcome as a "win." You should be prepared to counter that a procedural, discretionary denial is not a decision on the merits and has no bearing on whether the claims are actually valid. No claims have been canceled.

Inventors

The sole inventor is Mary Anne Fletcher. No employer at the time of filing is listed in the provided documents. The patent was assigned by the inventor to Weple IP Holdings LLC on the same day the application was filed, which is a common practice.

Original assignee

The original and current assignee of record is Weple IP Holdings LLC. The name "IP Holdings LLC" suggests a non-practicing entity (NPE) created for the purpose of holding and monetizing intellectual property rather than producing goods or services. Public records indicate Weple IP Holdings LLC is actively involved in patent litigation, asserting patents from this family against operating companies. There is no evidence that the assignee has ever shipped a product embodying the claims.

Assignment timeline

A search of the USPTO Patent Assignment Search database for US patent 12112357 reveals a single recorded assignment.

• 2024-01-25 (executed) / recorded 2024-02-05 — Reel 069635/0670
  • Conveyance: Assignment of Assignor's Interest
  • Assignor: Mary Anne Fletcher (Inventor)
  • Assignee: Weple IP Holdings LLC
  • Correspondent: Robert P. Lord, Law Office of Robert P. Lord, P.O. Box 1064, Groton, MA, 01450
  • Context: This is the initial assignment transferring the invention from the inventor to the holding company on the same day the patent application was filed.

Timeline diagram

timeline
    title Ownership of US 12112357
    2010 : Priority date established
    2024 : Application filed
         : Assigned to Weple IP Holdings LLC
         : Granted as US 12112357
         : Family member patent asserted vs T-Mobile

NPE / troll-pattern signals

1. Shell-entity transfer — Present. The patent was transferred on the day of its filing from the inventor directly to Weple IP Holdings LLC. The assignee name, a "Holdings LLC," is characteristic of a non-practicing entity established for licensing or litigation rather than product development (Reel 069635/0670).

2. Known asserter in the chain — Present. The assignee, Weple IP Holdings LLC, is a known patent asserter. It is listed as the plaintiff in litigation against T-Mobile (case 2:24-cv-01316, Western District of Washington) involving a related patent from the same family, as documented by Unified Patents.

3. Repeat correspondent across the chain — Not present. Only one assignment is on record, so there is no recurrence of the correspondent, Robert P. Lord.

4. Cascading transfers — Not present. There is only a single recorded assignment from the inventor to the current assignee.

5. Pre-litigation transfer — Present. The assignment to Weple IP Holdings LLC was executed on 2024-01-25. While this patent (issued 2024-10-08) has not yet been asserted, a sibling patent from the same family was asserted in litigation filed on 2024-09-11. The initial transfer to the holding company was a foundational step taken in the same year that litigation began, indicating a strategy of monetization through assertion from the outset.

6. Bankruptcy fire-sale — Not present. There is no indication of bankruptcy proceedings.

7. Privateering — Not present. There is no evidence of an operating company transferring the patent to be asserted on its behalf.

8. Defensive aggregator (anti-NPE) — Not present. The chain does not involve any known defensive aggregators.

Verdict

NPE — high confidence

The assignee, Weple IP Holdings LLC, is a non-practicing entity with "IP Holdings" in its name, and it received the patent directly from the inventor at the time of filing (Reel 069635/0670). This same entity is confirmed by Unified Patents to be actively litigating other patents from the same family within months of this patent's application, establishing a clear pattern of assertion. The combination of a shell-like holding company structure and active litigation provides high confidence in its status as an NPE.

Verification link: USPTO Assignment Search for US 12112357

Key Prior Art and Potential Anticipation of Claims

Based on an analysis of the citations for U.S. Patent No. 12,112,357, the following prior art references are among the most relevant for assessing the novelty of its claims under 35 U.S.C. § 102. The analysis focuses on references that describe systems for receiving, managing, and distributing media content to mobile devices, which is the core of the invention claimed in the '357 patent.

The independent claims (1, 9, 16, and 24) of the '357 patent generally describe a method and system involving:

• Receiving media messages from mobile applications.
• Storing these messages, with some having expiration information.
• Selecting subsets of messages for inclusion in at least two different feeds.
• Providing these feeds to a mobile application.
• The mobile application is configured to present the feeds, allow switching between them, and includes a sharing prompt to generate a link to a media message.

Analysis of Key Prior Art References

1. US Patent Application Publication No. US2009/0156170 A1

• Full Citation: Rossano, Anthony. "Methods and systems for transmitting video messages to mobile communication devices." US Patent Application Publication No. 2009/0156170 A1, filed December 12, 2007, and published June 18, 2009.
• Description: This reference discloses a system for users to upload video messages from mobile devices to a central server. The server can then transmit these video messages to other mobile devices. It describes creating a "video mail" or "video message" that is stored and forwarded.
• Potential Anticipation: This reference appears to describe several core elements of the '357 patent's claims. It discloses receiving media (video messages) from mobile devices and storing them on a server for distribution to other mobile devices (a "feed"). The concept of creating and sending a message implies a form of selection and provision. However, it may not explicitly detail the management of multiple distinct feeds (e.g., "first feed" and "second feed") that a user can switch between, nor the specific "expiration information" as claimed. It is most relevant to the broader concepts in claims 1, 9, 16, and 24 concerning the reception, storage, and provision of media messages from and to mobile devices.

2. US Patent Application Publication No. US2007/0174490 A1

• Full Citation: "System and methods for managing content in pre-existing mobile applications." Greystripe Inc. US Patent Application Publication No. 2007/0174490 A1, filed January 25, 2006, and published July 26, 2007.
• Description: This publication describes a system for embedding and managing content, including advertisements, within mobile applications. A server provides content that can be displayed in various applications, and this content can be updated or changed dynamically.
• Potential Anticipation: This reference is relevant to the elements of providing content to a mobile application from a server. While focused on advertising, the underlying system of serving dynamic content could be interpreted as a "feed." The concept of updating content suggests a temporal limitation, which could relate to the "expiration information" in claims 1, 9, 16, and 24. The presentation of an "advertisement prompt" as described in dependent claims 6, 12, 21, and 27 is also directly addressed.

3. US Patent Application Publication No. US2008/0248788 A1

• Full Citation: Smith, Daniel C. "Systems and methods for multi-modal mobile media services." US Patent Application Publication No. 2008/0248788 A1, filed February 5, 2007, and published October 9, 2008.
• Description: This reference details a system that allows users to capture, upload, and share various media types from their mobile devices. It describes a platform where users can access and interact with this shared media, including features for commenting and social sharing.
• Potential Anticipation: This publication covers the generation of media on a mobile device and its transmission to a server for storage and distribution, as outlined in claims 1, 9, 16, and 24. The description of a platform for accessing shared media implies the existence of a "feed." Furthermore, the functionality for social interaction, such as commenting, aligns with the limitations in dependent claims 5, 11, 20, and 26. The concept of sharing functionality may anticipate the "sharing prompt" that facilitates link generation.

4. US Patent No. 8,037,093 B2

• Full Citation: "Feeding updates to landing pages of users of an online social network from external sources." Facebook, Inc. US Patent No. 8,037,093 B2, filed September 12, 2006, and issued October 11, 2011.
• Description: This patent describes the core functionality of a social media news feed, where updates from various sources (users and external systems) are aggregated and presented to a user. It discusses formatting these updates for presentation on a user's page.
• Potential Anticipation: As a foundational patent for social media feeds, this reference is highly relevant. It explicitly describes the concept of a "feed" that includes various types of media messages provided by a server to a user interface. This directly relates to the central concept of providing a "first feed" and "second feed" in claims 1, 9, 16, and 24. The idea of a continuously updating feed of content from multiple users anticipates the general system described in the '357 patent. The ability to have different types of feeds or content streams (e.g., from different groups or sources) could anticipate the "first feed" and "second feed" that a user can switch between.

Conclusion

While several prior art references disclose individual elements of the claims in US Patent 12,112,357, a determination of direct anticipation under 35 U.S.C. § 102 requires that a single reference discloses every element of a claim. The combination of features—specifically, the management of multiple, switchable feeds selected based on expiration information and including a specific type of sharing prompt—may not be present in a single prior art document. However, references like US 8,037,093 B2 (Facebook) and US 2008/0248788 A1 (Smith) describe systems that are structurally and functionally very similar, and a more detailed analysis would be required to determine if they, or other cited art, fully anticipate the independent claims of the '357 patent. The dependent claims, which add features like commenting and advertising prompts, are likely anticipated by references such as US 2007/0174490 A1 and US 2008/0248788 A1, assuming the independent claims they depend on are also anticipated.

Based on my analysis as a technical patent analyst on May 13, 2026, the claims of US patent 12,112,357 appear to be vulnerable to an obviousness challenge under 35 U.S.C. § 103. The primary combination of prior art that renders the claims obvious is US 8,037,093 B2 (hereinafter "Facebook '093") in view of common industry practices and design principles known at the time, further evidenced by references such as US 2002/0052781 A1 (hereinafter "Avantgo '781").

A person having ordinary skill in the art (PHOSITA) in early 2010 would have been familiar with social networking systems, mobile application development, and common user interface (UI) design paradigms for managing content. The claimed invention essentially combines the established concept of a social media feed with predictable features for content organization and management.

Breakdown of Obviousness Argument

The independent claims (1, 9, 16, and 24) share a core set of limitations. The following analysis focuses on the method of claim 1, but the reasoning applies equally to the system claims and the claims specifying content generation from a mobile device camera.

Primary Reference: US 8,037,093 B2 (Facebook)

• Priority Date: September 12, 2006
• Disclosure: Facebook '093 discloses the foundational system for modern social media feeds. It teaches a system where a server receives updates from users and third-party sources (text, photos, links, etc.) and generates a personalized feed of stories for display to other users. This directly teaches or suggests several key elements of the '357 patent claims:
  • Receiving media messages from users: Facebook '093 describes receiving various types of content from users to be included in a feed.
  • Storing the messages on a server: This is an inherent requirement of the system described in Facebook '093.
  • Providing a feed to an application: Facebook '093 is centered on generating and providing a feed of updates to a user's landing page or application.
  • Sharing prompt and link generation: The ability to share a story, which generates a unique link (or "permalink") to the content, was a fundamental and widely understood feature of social networks and blogs at the time, including the system described by Facebook. The motivation is self-evident: to promote viral content distribution and platform growth.

Motivation to Combine and Add Missing Elements

While Facebook '093 provides the core feed architecture, a PHOSITA would have been motivated to combine its teachings with other well-known concepts to arrive at the invention claimed in '357.

1. Multiple, Switchable Feeds (Claim 1, elements C and E)

• Missing from Primary Reference: Facebook '093 focuses on generating a single, algorithmically-sorted news feed. It does not explicitly teach a user interface with a button to switch between multiple, distinct feeds (e.g., a "News" feed and a "Music" feed as contemplated by the '357 patent in column 7, lines 53-56).
• Obvious Modification: By 2010, organizing content into different, user-selectable categories was a ubiquitous and conventional UI design pattern. News websites used tabs for "Sports," "Business," and "World News." Email clients had filters and folders. A PHOSITA, tasked with improving the user experience of a social feed to prevent information overload, would have found it obvious to apply this common tabbed or categorized view paradigm. Providing different "feeds" based on content type (e.g., Photos, Links, Events) or social connection (e.g., Family, Co-workers) would have been a predictable step to enhance usability. The motivation is clear: to give users more control over the content they consume, thereby increasing engagement.

2. Storing and Selecting Based on Expiration Information (Claim 1, element B)

• Missing from Primary Reference: Content in the Facebook '093 feed ages and loses relevance over time, but the patent does not describe a system of storing a specific "expiration date" that is used to affirmatively disqualify a message from being included in a feed.
• Obvious Modification: The concept of time-limited content was well-established. Prior art like Avantgo '781, which discusses mobile advertising, inherently deals with content (advertisements) that is only valid for a specific campaign duration. A PHOSITA would understand that certain types of messages, such as event announcements, promotional offers, or breaking news alerts, have a finite period of relevance.
• Motivation to Combine: To improve the quality and relevance of a content feed, a PHOSITA would have been motivated to prevent stale, time-sensitive information from being displayed. For example, a "24-hour flash sale" message should not appear in a feed two days later. The most direct and obvious way to implement this would be to associate the message with expiration data upon creation and to filter out expired messages when the server generates the feed. This would be a predictable solution to a known problem in content management.

Conclusion

A PHOSITA in 2010, starting with the foundational social feed system taught by Facebook '093, would have been motivated to enhance it to improve user experience and content relevance. The problems of information overload and stale content were well-known. The solutions—providing categorized, switchable views and filtering content based on an expiration date—were also well-known and commonly used in the broader art of web and application design. Combining these established solutions with the social feed of Facebook '093 would have been an obvious, predictable path for innovation, rendering the claims of US patent 12,112,357 obvious under 35 U.S.C. § 103.

Based on my analysis of the provided information for US patent 12,112,357, here are the details regarding its prosecution history and family.

Patent Term and Expiration

• Patent Term Adjustment (PTA) / Extension (PTE): The provided documentation for US patent 12,112,357 does not indicate any specific grant of Patent Term Adjustment or Patent Term Extension.
• Projected Expiration Date: The patent's term is calculated from the earliest non-provisional application in its priority chain. According to the "CROSS-REFERENCE TO RELATED APPLICATIONS" section, the earliest non-provisional filing was U.S. patent application Ser. No. 13/027,191, filed on February 14, 2011. Therefore, the standard 20-year term results in a projected expiration date of February 14, 2031. This is consistent with the "Anticipated expiration" date listed in the patent data.

Application and Family Details

• Continuation Applications: This patent is part of an extensive series of continuation applications. The "CROSS-REFERENCE TO RELATED APPLICATIONS" section explicitly states that the application for this patent (Ser. No. 18/423,160) is a continuation of U.S. patent application Ser. No. 18/346,318 (now patent US 12,511,668). This chain of continuation applications extends back through more than ten predecessor applications to the original U.S. Provisional Patent Application No. 61/304,331, filed on February 12, 2010.

• Divisional Applications: Based on the provided patent text, there is no mention of any divisional applications related to US patent 12,112,357. The prosecution history appears to consist exclusively of a chain of continuation applications.

• Related Family Members: US patent 12,112,357 belongs to a large patent family (Family ID 44370394) that shares the same priority date of February 12, 2010. This family includes numerous granted patents, such as:

  • US 8,516,063
  • US 8,862,678
  • US 9,294,527
  • US 9,456,013
  • US 10,102,553
  • US 10,565,628
  • US 10,909,583
  • US 11,074,627
  • US 11,605,112
  • US 11,734,730
  • US 12,511,668

This extensive family indicates a long-term strategy of protecting various aspects of the core invention through continuing applications.

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.