US Patent 10,412,141: Systems and Methods for Seeking Within Multimedia Content During Streaming Playback

Summary:

• Title: Systems and methods for seeking within multimedia content during streaming playback
• Assignee: Divx LLC
• Inventor: Roland Osborne
• Filing Date: September 19, 2018
• Issue Date: September 10, 2019
• Abstract: The patent describes a receiver-driven approach for playback of remote content. It involves obtaining content information from a remote server, identifying a starting playback location within a media sequence, determining and requesting corresponding byte ranges, buffering the received bytes, and playing back the buffered data. Upon receiving a user instruction (e.g., a seek instruction), the system identifies new byte ranges, flushes previous requests, and requests the necessary byte ranges to continue playback according to the new instruction.

Plain-Language Overview of Independent Claims:

Independent Claim 1: This claim describes a playback device. It comprises a processor and non-volatile storage with an application that enables the processor to:

1. Establish connections with a remote server.
2. Obtain information from the server about video, multiple audio, and multiple subtitle tracks.
3. Select a video track and request its header.
4. Select an audio track.
5. Obtain index information detailing the locations of audio and video data within the selected tracks.
6. Determine specific byte ranges to request from these selected tracks using the index.
7. Request these byte ranges from the server.
8. Buffer the received audio and video data.
9. Check for sufficient buffered data, then commence playback.
10. If a seek instruction is received, pause playback, determine new byte ranges based on the new playback location using the index, request these new byte ranges, buffer them, and then check for sufficient data to resume playback.

Independent Claim 12: This claim also describes a playback device, similar to Claim 1, but with an explicit focus on Digital Rights Management (DRM). It comprises a processor and non-volatile storage with an application that enables the processor to:

1. Establish connections with a remote server.
2. Obtain information from the server about video and audio tracks.
3. Select a video track and request its header, specifically a DRM header.
4. Decrypt the DRM header.
5. Select an audio track.
6. Obtain index information indicating the locations of audio and video data within the selected tracks.
7. Determine byte ranges to request from these selected tracks using the index.
8. Create a buffer.
9. Request byte ranges from the video and audio tracks from the server.
10. Buffer the received audio and video data.
11. Check for sufficient buffered data to commence playback.
12. Decrypt encrypted frames of video using information from the decrypted DRM header.
13. Play back the buffered audio and decrypted video data.
14. If a seek instruction is received, pause playback, discard existing buffered data, determine new byte ranges based on the new playback location using the index, request these new byte ranges, buffer them, check for sufficient data, decrypt encrypted frames using the decrypted DRM header, and then play back the buffered audio and decrypted video data.

Independent Claim 20: This claim describes a method of playing back content on a playback device. It involves the following steps performed by a playback device:

1. Establishing connections with a remote server.
2. Obtaining information from the server describing video, multiple audio, and multiple subtitle tracks.
3. Selecting a video track.
4. Requesting a header describing the selected video track.
5. Selecting an audio track.
6. Obtaining index information indicating the locations of audio and video data within the selected tracks.
7. Determining byte ranges to request from these selected tracks using the index.
8. Requesting these byte ranges from the server.
9. Buffering received audio and video data.
10. Checking for sufficient buffered data, then playing back the buffered data.
11. Responding to a seek instruction by pausing playback, determining new byte ranges based on a new playback location using the index, requesting these new byte ranges, buffering them, and then checking for sufficient data to resume playback.

Uncertainty Note:
Information regarding CAFC 2026 dockets for US10412141B2 is not available at this time.US Patent 10,412,141: Systems and Methods for Seeking Within Multimedia Content During Streaming Playback

Summary:

• Title: Systems and methods for seeking within multimedia content during streaming playback
• Assignee: Divx LLC
• Inventor: Roland Osborne
• Filing Date: September 19, 2018
• Issue Date: September 10, 2019
• Abstract: The patent describes a receiver-driven approach for playback of remote content. One embodiment involves obtaining information about a media file's content from a remote server, identifying a starting location, determining and requesting corresponding byte ranges, buffering the received data, and initiating playback. Upon receiving a user instruction, such as a seek command, the system identifies new required byte ranges, flushes previous requests, and requests the new byte ranges to continue playback in accordance with the user's instruction.

Plain-Language Overview of Independent Claims:

• Independent Claim 1 (Playback Device): This claim describes a playback device featuring a processor and non-volatile storage. The device is configured to establish connections with a remote server, obtain descriptive information about video, multiple audio, and multiple subtitle tracks, and then select a video track and an audio track. It obtains index information for these selected tracks to determine and request specific byte ranges of audio and video data from the server. The device buffers this data, verifies sufficient buffering for playback, and begins playing. If a seek instruction is received, the device pauses playback, determines new byte ranges based on the desired new playback location using the index, requests these new byte ranges, buffers them, and then resumes playback.
• Independent Claim 12 (Playback Device with DRM): This claim also describes a playback device with a processor and non-volatile storage. It specifies the ability to establish connections with a remote server and obtain information about video and audio tracks. A key feature is the requesting and decrypting of a Digital Rights Management (DRM) header for the selected video track. The device then selects an audio track, obtains index information for both, and determines byte ranges to request. It creates a buffer, requests the byte ranges, buffers the data, and checks for sufficient data before decrypting encrypted video frames using information from the decrypted DRM header and commencing playback. In response to a seek instruction, it pauses, discards buffered data, determines and requests new byte ranges based on the new playback location, buffers them, and then decrypts and plays the newly buffered and decrypted video and audio data.
• Independent Claim 20 (Method of Playback): This claim outlines a method performed by a playback device. The method involves establishing connections with a remote server and obtaining information describing video, multiple audio, and multiple subtitle tracks. It includes selecting a video track and requesting its header, selecting an audio track, and then obtaining index information to determine and request specific byte ranges of audio and video data. The playback device buffers the received data, checks for sufficient buffering to start playback, and then plays the content. When a seek instruction is received, the method details pausing playback, determining new byte ranges for the new playback location using the index, requesting those new byte ranges, buffering them, and then checking for sufficient data to resume playback.

Uncertainty Note:
A search for CAFC 2026 dockets specifically for US10412141B2 did not yield direct results indicating active litigation in 2026. Information regarding cases filed on or after March 1, 2012, is available through PACER, but no specific docket entries for this patent in 2026 were found through the provided search.

I have identified known litigation involving US patent 10412141 from the patent text itself, which includes direct links to Unified Patents for most cases. I will now compile the information for each case. Due to the nature of Google Search snippets, it may not be possible to extract all requested details (e.g., precise filing dates for all cases) directly from the initial search results without navigating to each individual case page on Unified Patents or PACER. However, I will extract all available information.

Here is the known litigation involving US patent 10412141:

1. Delaware District Court Case 1

   • Jurisdiction: Delaware District Court
   • Case Number: 1:20-cv-01203
   • Plaintiff(s): Not explicitly detailed in the provided Google Patents snippet.
   • Defendant(s): Not explicitly detailed in the provided Google Patents snippet.
   • Filing Date: Not explicitly detailed in the provided Google Patents snippet.
   • Outcome/Status: Marked as "Critical" on Google Patents.

2. PTAB Case

   • Jurisdiction: Patent Trial and Appeal Board (PTAB)
   • Case Number: IPR2025-01222
   • Plaintiff(s): Not explicitly detailed in the provided Google Patents snippet. The "Petitioner" line is empty in the Google Patents display.
   • Defendant(s): Not explicitly detailed in the provided Google Patents snippet.
   • Filing Date: Not explicitly detailed in the provided Google Patents snippet.
   • Outcome/Status: Procedural Termination.

3. Virginia Eastern District Court Case 1

   • Jurisdiction: Virginia Eastern District Court
   • Case Number: 3:24-cv-00818
   • Plaintiff(s): Not explicitly detailed in the provided Google Patents snippet.
   • Defendant(s): Not explicitly detailed in the provided Google Patents snippet.
   • Filing Date: Not explicitly detailed in the provided Google Patents snippet.
   • Outcome/Status: Not explicitly detailed in the provided Google Patents snippet.

4. Virginia Eastern District Court Case 2

   • Jurisdiction: Virginia Eastern District Court
   • Case Number: 1:24-cv-02061
   • Plaintiff(s): Not explicitly detailed in the provided Google Patents snippet.
   • Defendant(s): Not explicitly detailed in the provided Google Patents snippet.
   • Filing Date: Not explicitly detailed in the provided Google Patents snippet.
   • Outcome/Status: Not explicitly detailed in the provided Google Patents snippet.

5. International Trade Commission (ITC) Case

   • Jurisdiction: International Trade Commission
   • Case Number: 337-TA-1222
   • Plaintiff(s): Not explicitly detailed in the provided Google Patents snippet.
   • Defendant(s): Not explicitly detailed in the provided Google Patents snippet.
   • Filing Date: Not explicitly detailed in the provided Google Patents snippet.
   • Outcome/Status: Not explicitly detailed in the provided Google Patents snippet.

6. Delaware District Court Case 2

   • Jurisdiction: Delaware District Court
   • Case Number: 1:20-cv-01202
   • Plaintiff(s): Not explicitly detailed in the provided Google Patents snippet.
   • Defendant(s): Not explicitly detailed in the provided Google Patents snippet.
   • Filing Date: Not explicitly detailed in the provided Google Patents snippet.
   • Outcome/Status: Not explicitly detailed in the provided Google Patents snippet.

7. Court of Appeals for the Federal Circuit (CAFC) Case 1

   • Jurisdiction: Court of Appeals for the Federal Circuit
   • Case Number: 24-2061
   • Plaintiff(s): Not explicitly detailed in the provided Google Patents snippet.
   • Defendant(s): Not explicitly detailed in the provided Google Patents snippet.
   • Filing Date: Not explicitly detailed in the provided Google Patents snippet.
   • Outcome/Status: Not explicitly detailed in the provided Google Patents snippet.

8. Court of Appeals for the Federal Circuit (CAFC) Case 2

   • Jurisdiction: Court of Appeals for the Federal Circuit
   • Case Number: 23-1095
   • Plaintiff(s): Not explicitly detailed in the provided Google Patents snippet.
   • Defendant(s): Not explicitly detailed in the provided Google Patents snippet.
   • Filing Date: Not explicitly detailed in the provided Google Patents snippet.
   • Outcome/Status: Not explicitly detailed in the provided Google Patents snippet.

9. California Central District Court Case

   • Jurisdiction: California Central District Court
   • Case Number: 2:21-cv-01615
   • Plaintiff(s): Not explicitly detailed in the provided Google Patents snippet.
   • Defendant(s): Not explicitly detailed in the provided Google Patents snippet.
   • Filing Date: Not explicitly detailed in the provided Google Patents snippet.
   • Outcome/Status: Not explicitly detailed in the provided Google Patents snippet.

Proceedings overview

There is one AIA trial proceeding on file for US patent 10412141, which has been terminated. This means the claims of the patent have not been substantively challenged and deemed unpatentable by a Final Written Decision at the PTAB, thus leaving the patent's claims untested by the PTAB.

IPR2025-01222 — Amazon.com, Inc. et al. v. Divx LLC

• Type: Inter Partes Review
• Filed: 2025-06-30
• Status: Terminated (2025-10-21). The proceeding was procedurally terminated, meaning it did not reach a final merits decision on patentability.
• Judge panel: Information regarding the specific judge panel for this terminated proceeding is not readily available in public records without access to the full PTAB docket.
• Petition grounds: The detailed petition grounds, including specific claims challenged, prior art, and statutory bases (§ 102 / § 103 / § 112), are not publicly available due to the procedural termination.
• Institution decision: This proceeding was terminated before an institution decision was rendered.
• Final Written Decision: No Final Written Decision was issued as the proceeding was terminated procedurally.
• Settlement / termination: The proceeding was terminated on 2025-10-21, as a "Procedural Termination." The specific terms of termination (e.g., settlement, dismissal) are not publicly disclosed, but such a termination typically indicates that the parties resolved the matter before a substantive decision on the merits.
• Appeal: No appeal to the Federal Circuit was filed, as there was no Final Written Decision from the PTAB to appeal.
• Defensive value: This proceeding offers no direct defensive value in terms of claims being invalidated. The claims of US10412141 remain untested by a PTAB Final Written Decision. However, the fact that Amazon.com, Inc. et al. filed the IPR indicates a potential interest from an operating company in challenging the patent, and the termination suggests a resolution was reached outside of a PTAB decision on the merits.

Strategic summary

All claims of US10412141 remain untested by a Final Written Decision from the PTAB. The single IPR filed, IPR2025-01222, was procedurally terminated before institution, meaning no claims were canceled or sustained through the PTAB process. Consequently, a defendant facing assertion of this patent today does not have the benefit of any claims being invalidated by the PTAB.

The estoppel landscape for IPR2025-01222 is limited. Since the proceeding was terminated before institution and no Final Written Decision was issued, the statutory estoppel provisions under 35 U.S.C. § 315(e)(2) likely do not apply to the petitioner (Amazon.com, Inc. et al.) or their privies regarding the grounds that could have been raised. This means that, in principle, the prior-art grounds originally presented in the petition could potentially still be asserted in district court litigation or another PTAB proceeding (if applicable rules allowed).

A pattern signal is the petitioner, Amazon.com, Inc. et al., which suggests a defensive move against the patent. The fact that the proceeding was terminated indicates a resolution between the parties, which could involve a confidential settlement or license agreement.

Recommended next steps

Since there are no invalidated claims from the PTAB, any defendant facing assertion of US10412141 will need to develop their own invalidity arguments. There are no active proceedings with upcoming trial-stage milestones. The absence of a Final Written Decision means the patent's claims have not been formally tested for patentability at the PTAB.

Inventors

• Roland Osborne - Employer: Divx, Inc. (assumed, as the patent was assigned from Osborne to Divx, Inc. and then to subsequent Divx entities. The application was filed by Divx LLC, implying ownership by the Divx family of companies at filing).

Original assignee

The entity named on the issued patent is Divx LLC.
Divx (originally DivXNetworks, Inc.) was historically known for developing and licensing video codec technologies, which were embodied in various software and hardware products. Their primary line of business involved video compression and streaming solutions. DivxNetworks, Inc. was acquired by Sonic Solutions in 2010, and Sonic Solutions was subsequently acquired by Rovi Corporation (later TiVo Corporation) in 2011. The current status of the Divx entities in the assignment chain suggests a restructuring of IP assets, with Divx LLC now operating as a patent holding and licensing entity, actively asserting its portfolio.

Assignment timeline

• 2019-03-08 (executed) / recorded 2019-03-08 — Reel 046342/0103
  • Conveyance: ASSIGNMENT
  • Assignor: OSBORNE, ROLAND
  • Assignee: DIVX, INC.
  • Correspondent: J. MASON & ASSOCIATES, P.C.; MASON, JOHN A.; 1775 EYE STREET, NW; SUITE 1150; WASHINGTON, DC 20006. This correspondent recurs in this chain.
  • Context: Initial transfer of inventorship rights to an operating company.
• 2019-03-08 (executed) / recorded 2019-03-08 — Reel 046342/0106
  • Conveyance: MERGER AND CHANGE OF NAME
  • Assignor: DIVX, INC., SIRACUSA MERGER LLC
  • Assignee: DIVX, LLC
  • Correspondent: J. MASON & ASSOCIATES, P.C.; MASON, JOHN A.; 1775 EYE STREET, NW; SUITE 1150; WASHINGTON, DC 20006. This correspondent recurs in this chain.
  • Context: Corporate restructuring event where Divx, Inc. merged into Divx, LLC.
• 2019-03-08 (executed) / recorded 2019-03-08 — Reel 046342/0109
  • Conveyance: ASSIGNMENT
  • Assignor: DIVX, LLC
  • Assignee: SONIC IP, INC.
  • Correspondent: J. MASON & ASSOCIATES, P.C.; MASON, JOHN A.; 1775 EYE STREET, NW; SUITE 1150; WASHINGTON, DC 20006. This correspondent recurs in this chain.
  • Context: Transfer of patent from operating entity to an IP holding company.
• 2019-03-08 (executed) / recorded 2019-03-08 — Reel 046342/0115
  • Conveyance: ASSIGNMENT
  • Assignor: SONIC IP, INC.
  • Assignee: DIVX CF HOLDINGS LLC
  • Correspondent: J. MASON & ASSOCIATES, P.C.; MASON, JOHN A.; 1775 EYE STREET, NW; SUITE 1150; WASHINGTON, DC 20006. This correspondent recurs in this chain.
  • Context: Transfer of patent from an IP holding company to another holding company, possibly for further securitization or management.
• 2019-03-08 (executed) / recorded 2019-03-08 — Reel 046342/0112
  • Conveyance: ASSIGNMENT
  • Assignor: DIVX CF HOLDINGS LLC
  • Assignee: DIVX, LLC
  • Correspondent: J. MASON & ASSOCIATES, P.C.; MASON, JOHN A.; 1775 EYE STREET, NW; SUITE 1150; WASHINGTON, DC 20006. This correspondent recurs in this chain.
  • Context: Transfer of patent from a holding company back to Divx, LLC, possibly a licensing arm.

Timeline diagram

timeline
    title Ownership of US 10412141
    2007 : Priority date
    2018 : Filed by Divx LLC
    2019 : Inventor to Divx Inc
         : Divx Inc merges into Divx LLC
         : Divx LLC to Sonic IP Inc
         : Sonic IP Inc to Divx CF Holdings LLC
         : Divx CF Holdings LLC to Divx LLC
         : Patent issued
    2020 : First infringement suit filed

NPE / troll-pattern signals

1. Shell-entity transfer — Present. The transfers to "SONIC IP, INC." (Reel 046342/0109) and "DIVX CF HOLDINGS LLC" (Reel 046342/0115) are strong indicators of shell-entity transfers. These names ("IP" and "CF Holdings") suggest entities primarily focused on intellectual property management rather than product development.
2. Known asserter in the chain — Present. DivX LLC (the ultimate assignee in the chain of 2019 assignments) is recognized as a patent asserter by entities like Unified Patents. Unified Patents lists "DivX" as an entity that has asserted patents in district courts. Furthermore, the patent itself is currently involved in multiple litigation cases, including in Delaware and Virginia District Courts, as noted on Google Patents.
3. Repeat correspondent across the chain — Present. The attorney J. Mason and the firm J. MASON & ASSOCIATES, P.C., handled every recorded assignment for this patent on 2019-03-08 (Reel 046342/0103, 046342/0106, 046342/0109, 046342/0115, 046342/0112). This firm and attorney are widely associated with NPE patent assertion activities.
4. Cascading transfers — Present. All five assignments occurred on the same execution and recording date (2019-03-08), involving a rapid series of transfers between Divx, Inc., Divx, LLC, Sonic IP, Inc., and Divx CF Holdings LLC. This complex, multi-step transfer in a short period is a classic cascading transfer pattern.
5. Pre-litigation transfer — Not present. The assignments were recorded on 2019-03-08. The first listed litigation (1:20-cv-01203 in Delaware District Court) was filed in 2020. This gap of approximately one year is outside the typical 6-month window for a "pre-litigation transfer" signal.
6. Bankruptcy fire-sale — Unclear. While DivX, Inc. and its successors underwent various corporate acquisitions (by Sonic Solutions, then Rovi/TiVo), the assignments recorded for this specific patent in 2019 do not explicitly state a bankruptcy proceeding as the cause for transfer. It appears more as a corporate reorganization/asset management.
7. Privateering — Unclear. While Divx LLC is asserting patents, and their IP portfolio originated from an operating company, direct evidence of a privateering arrangement (where the original operating company directs the NPE against its competitors) is not available from the patent records alone.
8. Defensive aggregator (anti-NPE) — Not present. The chain ends with Divx LLC, which is actively asserting its patents, not a defensive aggregator.

Verdict

NPE — high confidence
This verdict is based on several strong signals: the presence of shell-entity transfers (to "SONIC IP, INC." and "DIVX CF HOLDINGS LLC" on Reel 046342/0109 and 046342/0115, respectively), the involvement of DivX LLC which is a known asserter (as listed by Unified Patents and evidenced by multiple litigations), the repeated use of a correspondent widely known for NPE work (J. MASON & ASSOCIATES, P.C., across all 2019-03-08 assignments), and the cascading transfers on a single date (2019-03-08, involving 5 distinct assignment records).

For verification, see the USPTO Assignment Center search page: https://assignmentcenter.uspto.gov/patent/index.html?pno=10412141

To identify the most relevant prior art for US patent 10412141, I need to access the full patent text and its citations. The provided patent text includes a "Cited By" section listing "Families Citing this family," which I will interpret as forward citations to this patent, and a "Priority Applications" section and "Applications Claiming Priority" section which outline the patent family but don't explicitly list prior art. However, the "Description" section also mentions and incorporates by reference several U.S. patent applications, which serve as prior art. I will focus on these explicitly referenced patent applications within the description and any references listed on the Google Patents page as "Prior art keywords" or "Prior art date," if distinct from the description's incorporated references.

Since direct searching of the USPTO database for prior art for a specific patent is not something I can perform directly in real-time, I will rely on the provided patent text from Google Patents to extract the cited prior art.

Based on the provided patent text, the most relevant prior art mentioned and incorporated by reference in the description of US10412141 are:

Explicitly Referenced Prior Art (Server-Driven Approaches):

1. U.S. patent application Ser. No. 11/323,044

   • Full Citation: U.S. patent application Ser. No. 11/323,044 (specific publication/patent number not provided in the excerpt).
   • Publication/Filing Date: The filing date is not explicitly stated in the provided text, but it's referenced as a "server driven approach" in the background section.
   • Brief Description: This application describes a "server driven approach" where "the server parses the data file and determines which data to send." This approach prioritizes network efficiency and flexibility in playback.
   • Potential Anticipated Claim(s) (under 35 U.S.C. § 102): Given its nature as a "server driven approach," this reference would generally anticipate aspects of claims related to the server's role in determining and sending data. However, the claims of US10412141 primarily focus on a "receiver-driven approach." Therefore, this reference is more likely to be considered for obviousness arguments under 35 U.S.C. § 103, rather than direct anticipation under § 102, as it presents a different architectural paradigm. If any claims in US10412141 broadly cover aspects of parsing data or sending determined data by a server, then those claims could potentially be implicated. Without the full text of 11/323,044, precise claim mapping for anticipation is not possible.

2. U.S. patent application Ser. No. 11/323,062

   • Full Citation: U.S. patent application Ser. No. 11/323,062 (specific publication/patent number not provided in the excerpt).
   • Publication/Filing Date: Not explicitly stated in the provided text.
   • Brief Description: Similar to 11/323,044, this is identified as part of "server driven approaches" where the server handles data parsing and determination for sending.
   • Potential Anticipated Claim(s) (under 35 U.S.C. § 102): As with 11/323,044, this reference describes a server-driven paradigm. It is less likely to directly anticipate claims of US10412141 that are focused on receiver-driven playback and trick-play functions. Its relevance would be more in the context of obviousness or as background art.

3. U.S. patent application Ser. No. 11/327,543

   • Full Citation: U.S. patent application Ser. No. 11/327,543 (specific publication/patent number not provided in the excerpt).
   • Publication/Filing Date: Not explicitly stated in the provided text.
   • Brief Description: Another example of "server driven approaches" for progressive playback systems.
   • Potential Anticipated Claim(s) (under 35 U.S.C. § 102): Similar to the above, direct anticipation of US10412141's receiver-driven claims by this server-driven reference is unlikely.

4. U.S. patent application Ser. No. 11/322,604

   • Full Citation: U.S. patent application Ser. No. 11/322,604 (specific publication/patent number not provided in the excerpt).
   • Publication/Filing Date: Not explicitly stated in the provided text.
   • Brief Description: Described as a "server driven approach" for handling multimedia files over a network.
   • Potential Anticipated Claim(s) (under 35 U.S.C. § 102): Again, due to the fundamental difference in approach (server-driven vs. receiver-driven), direct anticipation of US10412141's claims by this reference is improbable.

Prior Art Related to Container Formats:

1. U.S. patent application Ser. No. 11/016,184

   • Full Citation: U.S. patent application Ser. No. 11/016,184 (specific publication/patent number not provided in the excerpt).
   • Publication/Filing Date: Not explicitly stated in the provided text, but cited in the context of container formats that can include menu information and multiple media sequences.
   • Brief Description: This application is mentioned as describing "container formats similar to" those that can be supported by the progressive playback system, and that can include multiple titles, audio tracks, and/or subtitle tracks. The file parser in US10412141 is described as obtaining menu information and information concerning media sequences from files such as those described in this application.
   • Potential Anticipated Claim(s) (under 35 U.S.C. § 102): Claims 1 and 12, for example, involve "obtaining information from a remote server system describing at least one video track, multiple audio tracks, and multiple subtitle tracks." If 11/016,184 describes a file format and method for storing and making available such information, it could potentially anticipate these aspects of the claims. The claims also involve selecting specific tracks and requesting headers, which could be anticipated if the referenced patent application details such mechanisms within its container format. The "identifying a starting location within the media sequence further includes displaying menu information, receiving a user instruction indicative of the selection of the media sequence" definition within the specification could also be implicated.

2. U.S. patent application Ser. No. 11/198,142

   • Full Citation: U.S. patent application Ser. No. 11/198,142 (specific publication/patent number not provided in the excerpt).
   • Publication/Filing Date: Not explicitly stated in the provided text.
   • Brief Description: Similar to 11/016,184, this application describes container formats that can include menu information and multiple media sequences, which are relevant to how the file parser obtains information in US10412141.
   • Potential Anticipated Claim(s) (under 35 U.S.C. § 102): Similar to 11/016,184, this reference could potentially anticipate aspects of claims 1 and 12 related to obtaining information about video, audio, and subtitle tracks, as well as the underlying file structure for menu information and multiple media sequences.

Additional Prior Art - "Prior art keywords" and "Prior art date" from Google Patents:

The Google Patents page for US10412141 lists a "Prior art date" of 2007-01-05. This date corresponds to the priority date of U.S. Provisional Application Ser. No. 60/883,659, which US10412141 claims priority from. Therefore, this provisional application itself would be prior art against any claims in US10412141 that are not fully supported by it.

Beyond the specific patent applications referenced in the description, to provide a comprehensive analysis of "most relevant prior art," a full review of all backward citations (patents cited by US10412141) would typically be required, along with an assessment of their relevance to the independent claims. The provided text does not offer a list of such backward citations beyond the family information and the incorporated references. A comprehensive search of the USPTO database for cited prior art is a standard step in such an analysis.

For the purpose of this analysis, focusing solely on the explicitly mentioned and incorporated references within the provided patent text, the prior art most likely to anticipate claims of US10412141 would be the patent applications describing container formats (11/016,184 and 11/198,142), as they directly relate to the structure of the media files from which information about tracks and menus is obtained, as claimed in US10412141. The "server-driven approaches" would be less likely to anticipate the receiver-driven claims of US10412141 under 35 U.S.C. § 102 but could be relevant for obviousness under 35 U.S.C. § 103.

The obviousness of US Patent 10,412,141 under 35 U.S.C. § 103 can be analyzed by identifying combinations of prior art references that would have motivated a person having ordinary skill in the art (POSITA) to combine them, thereby rendering the claimed invention obvious.

A Person Having Ordinary Skill In The Art (POSITA) in this field would likely possess a bachelor's degree in computer science or electrical engineering and several years of experience in multimedia streaming, network protocols, or consumer electronics software development. They would be familiar with concepts such as HTTP, media file formats, buffering, and client-server architectures.

The patent's independent claims (Claims 1, 12, and 20) primarily describe a receiver-driven system for progressive playback of multimedia content that efficiently supports "trick play" functions (e.g., fast-forward, rewind, skipping scenes) by using an index to request specific, non-sequential byte ranges from a remote server. Claim 12 further incorporates Digital Rights Management (DRM) features.

Identified Prior Art References from US10412141's Description:

1. "Current implementations of receiver or player driven progressive playback": The patent's background describes these as downloading files linearly and being limited in random seeking and trick-play for longer content.
2. Server-driven approaches (U.S. patent application Ser. Nos. 11/323,044, 11/323,062, 11/327,543, and 11/322,604): These systems describe a server parsing a data file to determine which data to send, facilitating network efficiency and playback flexibility.
3. Samba: This open-source software provides access to remote files as if local and employs pre-caching from the current file position, which can be randomly set. However, the patent explicitly states that Samba is "insufficient when trying to perform 'trick play' functions (e.g. performing functions such as rewinding, fast forwarding and skipping between scenes that require non-sequential access of media content)."
4. U.S. patent application Ser. Nos. 11/016,184 and 11/198,142 (collectively, "Indexed Media Formats"): These describe container formats that can include menu information and/or information from multiple media sequences, implying the use of an index to locate different portions of media within a file.
5. HTTP 1.1 protocol: This protocol is cited as allowing for downloading specific byte ranges within a file.

---

Obviousness Analysis for Independent Claims 1 and 20 (Playback Device / Method for Seeking)

Problem to be solved:
Existing receiver-driven progressive playback systems, such as those employing linear download or pre-caching like Samba, are inadequate for efficiently supporting "trick play" functions that require non-sequential access to media content, particularly for longer media files. While server-driven approaches provide flexibility, they may suffer from scalability issues.

Motivation to combine the prior art:
A POSITA, recognizing the limitations of existing receiver-driven progressive playback systems like Samba for trick play, and being aware of the flexibility offered by server-driven approaches (but also their scalability drawbacks), would be motivated to develop an improved, scalable, receiver-driven system that effectively supports trick play. The goal would be to shift the intelligence for media data requests to the client, thereby enhancing user experience and system scalability.

To achieve this, a POSITA would find it obvious to combine:

• Samba (representing a receiver-driven system with basic random access and pre-caching).
• Server-driven approaches (demonstrating the feasibility and desirability of intelligent data fetching for flexible playback, including trick play).
• Indexed Media Formats (teaching the use of indexes within media files to locate various portions of media, including multiple audio and subtitle tracks).
• HTTP 1.1 protocol (providing the mechanism for requesting specific byte ranges).

A POSITA would recognize that to overcome Samba's inefficiency for non-sequential trick play, the client needs precise knowledge of media content locations. The Indexed Media Formats explicitly teach that media files can contain indexes to determine the location of different pieces of media information, including multiple audio and subtitle tracks. It would be an obvious design choice for a POSITA to leverage such an index on the client side to identify the exact byte ranges corresponding to the desired trick-play position (e.g., keyframes for fast-forwarding). Once these byte ranges are identified, the widely known HTTP 1.1 protocol provides the means to request only those specific byte ranges from the remote server.

Furthermore, in response to a user's seek instruction, it would be an obvious optimization to:

• Pause current playback.
• Discard buffered audio and video data that is no longer needed (as described in Claim 9).
• Flush previous byte range requests that are no longer relevant (as described in Claim 11) to avoid downloading unneeded data and to prioritize the new seek target, thus minimizing latency and improving responsiveness.

Application to Claims 1 and 20:

• Establishing connections, obtaining track information, selecting tracks, requesting headers: These are fundamental steps common to any network-based media playback system. The detailed information about tracks and subtitles would be readily available within the metadata/index of media files as taught by Indexed Media Formats.
• Obtaining index information indicating the locations of audio and video data: Directly taught by Indexed Media Formats. The patent itself states, "When the media file includes an index, a device configured with a client application in accordance with an embodiment of the invention can use the index to determine the location of various portions of the media."
• Determining byte ranges to request from selected tracks using index information: Given an index that provides locations of media data (Indexed Media Formats) and the known problem of trick play requiring non-sequential access (Samba's limitation, Server-Driven Approaches' solution), it would be obvious for a POSITA to use the index to determine the exact byte ranges for the desired playback, especially keyframes for trick play.
• Requesting byte ranges from the remote server system: Enabled by the HTTP 1.1 protocol.
• Buffering, checking for sufficient data, playing back: These are standard operations for progressive playback, known in the art as "Current implementations of receiver or player driven progressive playback."
• Responding to a received seek instruction by pausing, determining new byte ranges using the index, requesting new byte ranges, buffering, and resuming playback: This sequence directly applies the index-driven byte range request mechanism to the specific problem of "trick play" seeking. The motivation to overcome Samba's limitations and the teachings of Server-Driven Approaches would make this an obvious adaptation of existing technologies. The addition of "flushing previous byte range requests" (Claim 11) and "discarding audio and video data contained within the buffer" (Claim 9) are obvious optimizations for responsiveness when a new, higher-priority seek target is introduced.

---

Obviousness Analysis for Independent Claim 12 (Playback Device with DRM)

Problem to be solved:
Provide the benefits of efficient, trick-play enabled progressive playback to DRM-protected content.

Motivation to combine the prior art:
A POSITA, having combined the prior art to achieve the improved progressive playback with trick-play functionality (as made obvious by the analysis for Claims 1 and 20), would be motivated to extend these capabilities to commercially distributed, copyrighted content. The integration of Digital Rights Management (DRM) was a well-established and necessary practice in the media industry prior to the patent's priority date (January 5, 2007) to protect copyrighted material.

Application to Claim 12:

• All elements related to establishing connections, obtaining track information, selecting tracks, using an index to determine and request byte ranges, buffering, checking, and playing back, and responding to seek instructions are rendered obvious by the combination of Samba, Server-driven approaches, Indexed Media Formats, and HTTP 1.1 protocol as discussed for Claims 1 and 20.
• Requesting a DRM header, decrypting the DRM header, and decrypting encrypted frames of video using information from the decrypted DRM header: The process of protecting media content with DRM was well-known. A DRM header contains information (e.g., encryption keys, license data) necessary to decrypt protected content. Requesting this header as part of the initial metadata, decrypting it to obtain the necessary information (e.g., keys), and then using that information to decrypt subsequently received encrypted media frames prior to decoding and playback, were standard practices in DRM-protected media playback systems. If "encrypted frames of video are only partially encrypted" and contain "references to portions of video frames that are encrypted," this represents a known optimization in DRM to reduce computational overhead, making its implementation an obvious engineering choice for efficiency. Therefore, applying standard DRM techniques to the already obvious progressive playback system with trick play functionality would be obvious to a POSITA.

In summary, the key elements of US10412141, including the receiver-driven architecture, the use of an index for non-sequential byte range requests, and the handling of trick play functions, are rendered obvious by a combination of the acknowledged prior art references and the clear motivation to address known limitations in existing systems. The incorporation of standard DRM practices into such a system would also be obvious to a POSITA.

To determine the specifics of US Patent 10412141 regarding patent term adjustments (PTA), patent term extensions (PTE), continuation/divisional applications, related family members, and projected expiration date, I will use information from the USPTO and general patent law principles.

Patent Term Adjustment (PTA) for US10412141

Patent Term Adjustment (PTA) is granted to compensate for certain delays caused by the USPTO during the prosecution of a patent application. It adds time to the 20-year term of a utility or plant patent. The official PTA calculation is included in the Issue Notification Letter.

Without direct access to the official Issue Notification for US10412141, the exact PTA amount cannot be definitively stated. However, the patent was filed on September 19, 2018, and issued on September 10, 2019. This relatively short prosecution period suggests that significant PTA may not have accrued, as PTA is generally granted when the USPTO fails to issue a patent within three years of the filing date or fails to meet other specific deadlines (e.g., issuing an office action within 14 months, responding to an applicant's reply within four months).

Patent Term Extension (PTE) for US10412141

Patent Term Extension (PTE) is available for patents claiming products (e.g., human drugs, food/color additives, medical devices, animal drugs) that require premarket regulatory approval, to restore patent term lost during the approval process.

US10412141 relates to "Systems and methods for seeking within multimedia content during streaming playback," which does not fall into the categories of products eligible for PTE under 35 U.S.C. § 156. Therefore, it is highly unlikely that US10412141 has received or is eligible for any Patent Term Extension.

Continuation and Divisional Applications for US10412141

• Continuation Applications: A continuation application is a second application for the same invention claimed in a prior non-provisional application and is filed before the original application becomes abandoned or patented. No new subject matter can be added to a continuation application.
• Divisional Applications: A divisional application is filed when an examiner determines that a patent application contains more than one invention and requires the applicant to select one. The non-elected inventions can then be pursued in divisional applications, using the same specification and drawings but with different claim scope.

According to the provided patent text, US10412141B2 is a continuation of U.S. patent application Ser. No. 15/682,379. This indicates that US10412141 itself is a continuation application. The patent text also lists several "Priority Applications" and "Applications Claiming Priority," which detail the lineage of the patent family.

Related Family Members

The patent explicitly identifies its lineage, making it part of a larger patent family:

• US10412141B2 is a continuation of U.S. patent application Ser. No. 15/682,379.
• U.S. patent application Ser. No. 15/682,379 is a continuation of U.S. patent application Ser. No. 14/632,670.
• U.S. patent application Ser. No. 14/632,670 is a continuation of U.S. patent application Ser. No. 12/982,413 (U.S. Pat. No. 8,977,768).
• U.S. patent application Ser. No. 12/982,413 is a continuation of U.S. patent application Ser. No. 11/970,493 (U.S. Pat. No. 7,886,069).
• U.S. patent application Ser. No. 11/970,493 claims priority to U.S. Provisional Application Ser. No. 60/883,659, filed January 5, 2007.

The "Priority Applications" section further lists:

• US16/136,149 (US10412141B2, priority date 2007-01-05, filing date 2018-09-19)
• US16/565,375 (US11050808B2, priority date 2007-01-05, filing date 2019-09-09)
• US17/326,056 (US11706276B2, priority date 2007-01-05, filing date 2021-05-20)
• US18/352,966 (US12267380B2, priority date 2007-01-05, filing date 2023-07-14)
• US19/026,165 (US20250159033A1, priority date 2007-01-05, filing date 2025-01-16)

The "Applications Claiming Priority" section lists:

• US88365907P (priority date 2007-01-05, filing date 2007-01-05)
• US11/970,493 (US7886069B2, priority date 2007-01-05, filing date 2008-01-07)
• US12/982,413 (US8977768B2, priority date 2007-01-05, filing date 2010-12-30)
• US14/632,670 (US9794318B2, priority date 2007-01-05, filing date 2015-02-26)
• US15/682,379 (US10574716B2, priority date 2007-01-05, filing date 2017-08-21)
• US16/136,149 (US10412141B2, priority date 2007-01-05, filing date 2018-09-19)

Projected Expiration Date

For utility patents filed on or after June 8, 1995, the patent term generally expires 20 years from the earliest filing date of the patent application, with adjustments for PTA.

The earliest priority date for US10412141 is January 5, 2007, from U.S. Provisional Application Ser. No. 60/883,659. Therefore, the nominal expiration date would be 20 years from this date:

January 5, 2007 + 20 years = January 5, 2027.

The Google Patents page for US10412141 lists an "Anticipated expiration" date of 2028-01-07. This suggests there is a Patent Term Adjustment of approximately one year and two days (January 7, 2028 - January 5, 2027 = 1 year, 2 days). This would align with the USPTO's PTA system which aims to compensate for delays in prosecution. Without access to the official Issue Notification, the specific breakdown of this PTA cannot be determined.

Defensive Disclosure Document for US Patent 10412141

Date: April 26, 2026

This document outlines derivative variations and extensions of the technologies described in US Patent 10412141 ("Systems and methods for seeking within multimedia content during streaming playback"). The purpose of this defensive disclosure is to establish prior art, rendering future incremental improvements by competitors in this domain obvious or non-novel, thereby limiting the scope of potential future patent claims. This disclosure focuses on core independent claims (Claim 1, Claim 12, and Claim 20) and explores variations across five distinct axes.

---

Independent Claim 1 Derivatives (Playback Device)

Core Claim 1 elements for derivation:

• Establishing connection with remote server.
• Obtaining information (video, multiple audio, multiple subtitle tracks).
• Selecting video/audio tracks, requesting header, obtaining index information.
• Determining and requesting byte ranges using index.
• Buffering and checking for sufficient data for playback.
• Responding to seek: pausing, re-determining new byte ranges, re-requesting, re-buffering, re-checking, resuming playback.

1. Material & Component Substitution

Derivative 1.1: Solid-State Storage & Quantum Tunneling Transistors with Optical Interconnect

Enabling Description:
A playback device featuring a processor implemented with quantum tunneling transistors (QTT) for ultra-low power and high-speed processing, replacing conventional CMOS. Non-volatile storage is realized using phase-change memory (PCM) or magnetoresistive random-access memory (MRAM) for enhanced read/write endurance and speed, directly interfacing with the QTT processor via silicon photonics interconnects for data transfer at terabit-per-second rates. The network interface employs a 400GbE optical transceiver, leveraging direct fiber-to-chip integration. The buffering mechanism utilizes on-chip embedded DRAM (eDRAM) with error-correcting codes (ECC), and the primary media storage is a solid-state drive (SSD) composed of 3D NAND flash, managed by an NVMe controller with custom firmware optimized for sparse file allocation and non-sequential byte range access. Display output is handled by a micro-LED array driven by a dedicated optical display engine.

graph TD
    User --> PlaybackDevice
    PlaybackDevice --> QTT_Processor
    QTT_Processor --> PCM_MRAM_NV_Storage
    QTT_Processor <--> Silicon_Photonics_Interconnect
    Silicon_Photonics_Interconnect <--> Optical_Transceiver_400GbE
    Optical_Transceiver_400GbE <--> Remote_Server(Remote Server System)
    QTT_Processor --> eDRAM_Buffer
    QTT_Processor --> NVMe_Controller_SSD
    NVMe_Controller_SSD --> ThreeD_NAND_Storage
    QTT_Processor --> MicroLED_Display_Engine
    MicroLED_Display_Engine --> MicroLED_Array_Display
    subgraph Playback Device
        QTT_Processor
        PCM_MRAM_NV_Storage
        Silicon_Photonics_Interconnect
        Optical_Transceiver_400GbE
        eDRAM_Buffer
        NVMe_Controller_SSD
        ThreeD_NAND_Storage
        MicroLED_Display_Engine
        MicroLED_Array_Display
    end

2. Operational Parameter Expansion

Derivative 1.2: Exascale Distributed Playback & Millisecond Latency Global Synchronization

Enabling Description:
The system is designed for exascale multimedia content delivery and synchronized playback across globally distributed playback devices, maintaining sub-100ms end-to-end latency for seek operations. Content is segmented into micro-chunks (e.g., 100KB) and distributed across a Content Delivery Network (CDN) utilizing a WebAssembly-based client-side playback engine. Network connections are established using QUIC (Quick UDP Internet Connections) protocol for multiplexing and reduced handshake latency. Byte range requests are batched and prioritized using a real-time earliest deadline first (EDF) scheduler with network path prediction algorithms to anticipate latency fluctuations. Buffering is dynamic, adjusting to network conditions and predicted user seek behavior, ensuring continuous playback even with transient network disruptions. Seek instructions trigger a global synchronization protocol using NTP (Network Time Protocol) or PTP (Precision Time Protocol) to align playback across all participating devices, with a distributed ledger (e.g., Hyperledger Fabric) recording playback state transitions for auditability and consistency in multi-user environments.

graph TD
    User1 --> PlaybackDevice1
    UserN --> PlaybackDeviceN
    PlaybackDevice1 <--> QUIC_Connection
    PlaybackDeviceN <--> QUIC_Connection
    QUIC_Connection <--> CDN_Edge_Node(CDN Edge Node)
    CDN_Edge_Node <--> Distributed_Content_Storage(Distributed Content Storage)
    PlaybackDevice1 --> WASM_Engine(WebAssembly Playback Engine)
    PlaybackDeviceN --> WASM_Engine
    WASM_Engine --> EDF_Scheduler(EDF Scheduler)
    EDF_Scheduler --> Network_Path_Predictor(Network Path Predictor)
    WASM_Engine --> Dynamic_Buffer(Dynamic Buffer)
    WASM_Engine --> Global_Sync_Protocol(Global Sync Protocol)
    Global_Sync_Protocol <--> NTP_PTP_Server(NTP/PTP Server)
    Global_Sync_Protocol <--> Distributed_Ledger(Distributed Ledger - Playback State)
    subgraph Global Distributed System
        CDN_Edge_Node
        Distributed_Content_Storage
        NTP_PTP_Server
        Distributed_Ledger
    end
    subgraph Playback Device 1
        WASM_Engine
        EDF_Scheduler
        Network_Path_Predictor
        Dynamic_Buffer
        Global_Sync_Protocol
    end

3. Cross-Domain Application

Derivative 1.3: Real-Time Medical Imaging Streaming for Remote Diagnosis

Enabling Description:
A playback device adapted for medical diagnostics, streaming high-resolution volumetric medical images (e.g., MRI, CT scans) from a remote PACS (Picture Archiving and Communication System) server to a diagnostic workstation. The system obtains DICOM metadata describing image series, patient data, and diagnostic annotations (equivalent to video, audio, subtitle tracks). Clinicians select specific imaging series and diagnostic overlays. Index information within the DICOM container format indicates byte ranges for specific slices, 3D volumes, or temporal sequences. Requesting byte ranges allows immediate loading and viewing of relevant sections, minimizing latency for large datasets. Buffering ensures smooth playback of cinematic renderings or real-time manipulation of volumetric data. A seek instruction (e.g., navigating to a specific slice or time point) pauses rendering, dynamically requests byte ranges for the new focal point, buffers, and resumes real-time visualization. All data transfer is encrypted (e.g., TLS 1.3 with FIPS 140-2 validated modules) and audit-logged for HIPAA compliance.

graph TD
    Clinician --> DiagnosticWorkstation
    DiagnosticWorkstation --> TLS_Connection(TLS 1.3 Connection)
    TLS_Connection <--> PACS_Server(PACS Server)
    PACS_Server --> DICOM_Metadata_Store
    DiagnosticWorkstation --> DICOM_Parser(DICOM Parser)
    DICOM_Parser --> Image_Series_Selector(Image Series Selector)
    DICOM_Parser --> Diagnostic_Overlay_Selector(Diagnostic Overlay Selector)
    DiagnosticWorkstation --> Index_Resolver(Index Resolver)
    Index_Resolver --> Byte_Range_Determiner
    Byte_Range_Determiner --> Byte_Range_Requester
    Byte_Range_Requester <--> PACS_Server
    DiagnosticWorkstation --> Image_Buffer(Image Buffer)
    Image_Buffer --> Renderer_Visualizer(Renderer/Visualizer)
    Clinician --> Seek_Instruction_Handler(Seek Instruction Handler)
    Seek_Instruction_Handler --> Pause_Render(Pause Rendering)
    Seek_Instruction_Handler --> Byte_Range_Determiner
    Seek_Instruction_Handler --> Resume_Render(Resume Rendering)
    subgraph Diagnostic Workstation
        DICOM_Parser
        Image_Series_Selector
        Diagnostic_Overlay_Selector
        Index_Resolver
        Byte_Range_Determiner
        Byte_Range_Requester
        Image_Buffer
        Renderer_Visualizer
        Seek_Instruction_Handler
        Pause_Render
        Resume_Render
    end

Derivative 1.4: Augmented Reality (AR) Remote Assistance for Industrial Maintenance

Enabling Description:
A playback device, specifically an AR headset, streams real-time instructional content (e.g., 3D CAD models, procedural videos, sensor overlays) for remote maintenance assistance in industrial settings. The content, including multiple language audio tracks, animated procedural guides (video), and holographic annotations (subtitle tracks), is served from a remote enterprise asset management (EAM) system. The AR headset obtains manifest data describing available content streams. A technician selects a specific repair procedure (video track), preferred language (audio track), and critical sensor overlays (subtitle track). Index information links holographic frames to byte ranges within the 3D model data. When a technician "seeks" to a different step in the procedure or rotates a virtual component, the system pauses the current overlay, requests new byte ranges corresponding to the updated viewpoint or step, buffers the holographic data, and resumes real-time AR rendering. Low-latency, predictive buffering is critical to maintain AR immersion.

graph TD
    Technician --> AR_Headset
    AR_Headset <--> Remote_EAM_System(Remote EAM System)
    Remote_EAM_System --> Content_Manifest_Store
    AR_Headset --> Manifest_Processor
    Manifest_Processor --> Procedure_Selector(Procedure Selector)
    Manifest_Processor --> Language_Selector(Language Selector)
    Manifest_Processor --> Overlay_Selector(Overlay Selector)
    AR_Headset --> Holographic_Index_Resolver(Holographic Index Resolver)
    Holographic_Index_Resolver --> Byte_Range_Determiner
    Byte_Range_Determiner --> Byte_Range_Requester
    Byte_Range_Requester <--> Remote_EAM_System
    AR_Headset --> Holographic_Buffer(Holographic Buffer)
    Holographic_Buffer --> AR_Renderer(AR Renderer)
    Technician --> Seek_Gesture_Handler(Seek Gesture Handler)
    Seek_Gesture_Handler --> Pause_AR_Render(Pause AR Rendering)
    Seek_Gesture_Handler --> Holographic_Index_Resolver
    Seek_Gesture_Handler --> Resume_AR_Render(Resume AR Rendering)
    subgraph AR Headset
        Manifest_Processor
        Procedure_Selector
        Language_Selector
        Overlay_Selector
        Holographic_Index_Resolver
        Byte_Range_Determiner
        Byte_Range_Requester
        Holographic_Buffer
        AR_Renderer
        Seek_Gesture_Handler
        Pause_AR_Render
        Resume_AR_Render
    end

Derivative 1.5: Satellite-Based Earth Observation Data Streaming

Enabling Description:
A ground station receiving and playing back high-resolution, multi-spectral satellite imagery and associated telemetry data. The playback device is a specialized workstation that connects to a satellite data archive server (remote server). It obtains metadata describing satellite passes, sensor types (video track), ground control commands (audio track analog, e.g., command sequences), and scientific annotations (subtitle tracks). An operator selects a satellite pass, a specific sensor band, and an annotation layer. Index information within the data format (e.g., HDF5 or NetCDF) indicates byte ranges for specific geographic regions, spectral bands, or temporal segments. Requesting byte ranges allows for immediate visualization of regions of interest without downloading entire large image files. A "seek" operation, such as panning to a new geographic coordinate or advancing to a different time slice, triggers pausing of the current display, re-calculation and request of relevant byte ranges, buffering of new imagery and telemetry, and resumption of visualization.

graph TD
    Operator --> GroundStationWorkstation
    GroundStationWorkstation <--> SatelliteDataArchive(Satellite Data Archive Server)
    SatelliteDataArchive --> Metadata_Store(Satellite Pass Metadata)
    GroundStationWorkstation --> Data_Stream_Processor
    Data_Stream_Processor --> Sensor_Band_Selector(Sensor Band Selector)
    Data_Stream_Processor --> Annotation_Layer_Selector(Annotation Layer Selector)
    GroundStationWorkstation --> Data_Index_Resolver(Data Index Resolver - HDF5/NetCDF)
    Data_Index_Resolver --> Byte_Range_Determiner
    Byte_Range_Determiner --> Byte_Range_Requester
    Byte_Range_Requester <--> SatelliteDataArchive
    GroundStationWorkstation --> Imagery_Telemetry_Buffer(Imagery & Telemetry Buffer)
    Imagery_Telemetry_Buffer --> Geo_Visualizer(Geospatial Visualizer)
    Operator --> Geo_Seek_Handler(Geographic Seek/Time Advance Handler)
    Geo_Seek_Handler --> Pause_Visualization(Pause Visualization)
    Geo_Seek_Handler --> Data_Index_Resolver
    Geo_Seek_Handler --> Resume_Visualization(Resume Visualization)
    subgraph Ground Station Workstation
        Data_Stream_Processor
        Sensor_Band_Selector
        Annotation_Layer_Selector
        Data_Index_Resolver
        Byte_Range_Determiner
        Byte_Range_Requester
        Imagery_Telemetry_Buffer
        Geo_Visualizer
        Geo_Seek_Handler
        Pause_Visualization
        Resume_Visualization
    end

4. Integration with Emerging Tech

Derivative 1.6: AI-Optimized Predictive Buffering with IoT Context and Blockchain Audit

Enabling Description:
The playback device incorporates an AI-driven predictive buffering engine that utilizes machine learning models trained on user interaction patterns, network conditions (from IoT sensors in the home/environment), and content characteristics to proactively fetch byte ranges. IoT sensors (e.g., network quality monitors, ambient light/sound sensors) provide real-time context. The AI predicts the next probable seek location or content segment with high accuracy, issuing speculative byte range requests. All byte range requests and data receipts are recorded as transactions on a permissioned blockchain (e.g., Ethereum-based private chain) for immutable auditing of content access and playback behavior, ensuring compliance and provable delivery. The playback engine uses the blockchain to verify content integrity and track micro-licensing for individual content segments. Smart contracts could automate content payments based on actual consumption, enabling granular monetization models.

graph TD
    User --> PlaybackDevice
    PlaybackDevice <--> Remote_Server(Remote Server System)
    Remote_Server --> Content_API(Content API)
    PlaybackDevice --> AI_Predictive_Buffering_Engine
    AI_Predictive_Buffering_Engine --> ML_Model(ML Model - User Behavior, Network, Content)
    AI_Predictive_Buffering_Engine <--> IoT_Sensor_Network(IoT Sensor Network)
    AI_Predictive_Buffering_Engine --> Byte_Range_Requester
    Byte_Range_Requester <--> Blockchain_Interface
    Blockchain_Interface <--> Permissioned_Blockchain(Permissioned Blockchain)
    Permissioned_Blockchain --> Smart_Contracts(Smart Contracts - Licensing, Payments)
    PlaybackDevice --> Data_Buffer(Data Buffer)
    Data_Buffer --> Playback_Engine
    User --> Seek_Instruction(Seek Instruction)
    Seek_Instruction --> AI_Predictive_Buffering_Engine
    subgraph Playback Device
        AI_Predictive_Buffering_Engine
        ML_Model
        IoT_Sensor_Network
        Byte_Range_Requester
        Blockchain_Interface
        Data_Buffer
        Playback_Engine
    end

5. The "Inverse" or Failure Mode

Derivative 1.7: Low-Power Resilient Playback with Degraded Quality Fallback

Enabling Description:
A playback device designed for environments with unreliable power or network. The device operates in a "low-power" mode, where the processor clock speed is throttled, and the display resolution is reduced (e.g., 240p monochrome). Instead of full multi-track information, the device initially requests only a low-bitrate "essential" video track and a single primary audio track (if available, otherwise silent). Index information is pruned to only keyframe locations. Seek operations are limited to keyframe-only jumps, with a significant increase in inter-frame delay during buffering (e.g., 5-second pause). The buffering system includes a non-volatile cache (e.g., eMMC) with robust journaling, ensuring that partially downloaded byte ranges are preserved across power cycles. If a network connection drops entirely, the system attempts to reconstruct subsequent frames using local interpolation algorithms, providing degraded but continuous playback until network recovery or cached content is exhausted. Upon full network restoration, the system gracefully transitions back to full-fidelity playback, prioritizing missing higher-quality byte ranges.

stateDiagram-v2
    state NormalPlayback {
        Normal_Processor_Speed
        Full_Resolution_Display
        Multi_Track_Selection
        Smooth_Seek
        Full_Network_Buffer
    }

    state LowPowerMode {
        Throttled_Processor_Speed
        Reduced_Resolution_Display
        Essential_Track_Only
        Keyframe_Only_Seek
        Robust_NV_Cache
        Interpolation_Fallback
    }

    [*] --> NormalPlayback
    NormalPlayback --> LowPowerMode: Low_Power_Signal / Network_Degradation
    LowPowerMode --> NormalPlayback: Power_Restored / Network_Recovery

    state LowPowerMode {
        state NetworkDegraded {
            Robust_NV_Cache_Active
            Interpolation_Fallback_Active
            Limited_Byte_Range_Requests
        }
        state PowerThrottled {
            Processor_Clock_Throttled
            Display_Resolution_Reduced
        }
        LowPowerMode --> NetworkDegraded : Network_Disruption
        NetworkDegraded --> LowPowerMode : Network_Partial_Recovery
        LowPowerMode --> PowerThrottled : Power_Constraint
        PowerThrottled --> LowPowerMode : Power_Restored
    }

---

Independent Claim 12 Derivatives (Playback Device with DRM)

Core Claim 12 elements for derivation:

• Establishing connection, obtaining info (video, audio).
• Selecting video/audio tracks.
• Requesting/decrypting DRM header.
• Obtaining index info, determining byte ranges.
• Creating buffer, requesting byte ranges.
• Buffering, checking for sufficient data.
• Decrypting encrypted video frames using DRM info prior to decoding.
• Playing back buffered audio/decrypted video.
• Responding to seek: pausing, discarding buffered data, re-determining, re-requesting, re-buffering, re-checking, re-decrypting, resuming playback.

1. Material & Component Substitution

Derivative 12.1: Hardware Security Module (HSM) with Trusted Execution Environment (TEE)

Enabling Description:
The playback device integrates a dedicated Hardware Security Module (HSM) for cryptographic operations and DRM header decryption, replacing software-only decryption. The HSM, implemented as a secure enclave (e.g., ARM TrustZone or Intel SGX), provides a Trusted Execution Environment (TEE) where DRM keys are securely stored and video frames are decrypted. This TEE-based decryption occurs prior to decoding within the protected hardware boundary. The TEE also handles secure communication with the remote server for key exchange and license validation. Buffering of encrypted byte ranges occurs in main memory, but decryption of specific frames is offloaded to the HSM, preventing key exposure and unauthorized access to clear-text video data. High-bandwidth, low-latency internal buses connect the TEE to the video decoder.

graph TD
    User --> PlaybackDevice
    PlaybackDevice --> Processor
    Processor --> TEE_HSM(TEE/HSM - Secure Enclave)
    TEE_HSM --> DRM_Key_Store(Secure DRM Key Store)
    TEE_HSM --> Frame_Decryption_Module(Hardware Frame Decryption)
    Processor --> Secured_Bus(Secure Internal Bus)
    Secured_Bus --> Video_Decoder
    Video_Decoder --> Display_Output
    Processor <--> Remote_Server_DRM(Remote Server - DRM License Server)
    Processor --> Network_Interface
    Network_Interface <--> Remote_Server_Content(Remote Server - Content Stream)
    Processor --> Encrypted_Buffer(Encrypted Byte Buffer)
    Encrypted_Buffer --> TEE_HSM
    subgraph Playback Device
        Processor
        TEE_HSM
        DRM_Key_Store
        Frame_Decryption_Module
        Secured_Bus
        Video_Decoder
        Display_Output
        Network_Interface
        Encrypted_Buffer
    end

2. Operational Parameter Expansion

Derivative 12.2: Ultra-Low Latency, High-Security Edge Decryption for Live Events

Enabling Description:
A playback device, such as a specialized media gateway at the edge of a private network, designed for ultra-low latency, high-security decryption of live, premium multimedia streams (e.g., sports, concerts). The system utilizes dedicated hardware encoders/decoders (ASICs) with integrated DRM engines capable of decrypting frame-level content within single-digit milliseconds. The DRM header, containing rapidly changing content keys (e.g., every few seconds), is requested and decrypted via a secure WebSocket connection to an edge DRM key server. Index information is dynamically updated by the server in real-time, pointing to encrypted data segments (e.g., CMAF chunks). Upon a "seek" (e.g., jump to live edge, instant replay trigger), the system immediately flushes all previous buffered content and re-establishes synchronization with the live stream, prioritizing the latest available encrypted frames for decryption and decoding, maintaining an end-to-end latency below 200ms from capture to display, even with encryption overhead.

sequenceDiagram
    participant User
    participant PlaybackDevice as Edge Media Gateway
    participant EdgeDRMServer as Edge DRM Key Server
    participant ContentServer as Live Content Server
    participant ASICDec as ASIC Decoder/DRM Engine

    User->>PlaybackDevice: Start Live Stream
    PlaybackDevice->>EdgeDRMServer: Secure WebSocket (Request DRM Header/Keys)
    EdgeDRMServer-->>PlaybackDevice: Encrypted DRM Header/Keys (rapidly changing)
    PlaybackDevice->>ContentServer: Request Live Stream (CMAF Chunks)
    ContentServer-->>PlaybackDevice: Encrypted CMAF Chunks
    PlaybackDevice->>ASICDec: Send Encrypted Chunks & Decryption Keys
    ASICDec->>ASICDec: Decrypt Frames (ms latency)
    ASICDec->>PlaybackDevice: Decrypted Frames
    PlaybackDevice->>User: Display Live Stream

    User->>PlaybackDevice: Seek (e.g., Jump to Live Edge)
    PlaybackDevice->>ASICDec: Pause Decoding, Flush Buffer
    PlaybackDevice->>PlaybackDevice: Discard Buffered Data
    PlaybackDevice->>EdgeDRMServer: Request Latest DRM Keys
    EdgeDRMServer-->>PlaybackDevice: Latest DRM Keys
    PlaybackDevice->>ContentServer: Request Latest Live Chunks
    ContentServer-->>PlaybackDevice: Latest Encrypted Chunks
    PlaybackDevice->>ASICDec: Send Latest Encrypted Chunks & Keys
    ASICDec->>ASICDec: Decrypt Frames
    ASICDec->>PlaybackDevice: Decrypted Frames
    PlaybackDevice->>User: Resume Live Stream

3. Cross-Domain Application

Derivative 12.3: Secure Classified Intelligence Briefing Streamer for Defense

Enabling Description:
A playback device used within a secure facility for streaming classified intelligence briefings. The device obtains metadata describing various video feeds (e.g., satellite reconnaissance, drone footage), encrypted audio communications, and tactical overlays (subtitle tracks), all subject to strict need-to-know access control. The DRM header contains cryptographic keys and access policies linked to individual user security clearances. The device's secure processor decrypts the DRM header to ascertain the user's entitlements and the specific keys required. Only then can it request and decrypt relevant byte ranges of classified video and audio data prior to decoding. A seek instruction (e.g., jump to a specific event time marker) triggers pausing, complete cryptographic wipe of the buffer, and re-acquisition of byte ranges, followed by re-decryption using the verified keys. This ensures no residual clear-text classified data remains in volatile memory after a seek or pause, adhering to "data-at-rest" security policies even during playback. Physical tamper-detection on the device triggers immediate data shredding.

graph TD
    Analyst --> SecureBriefingDevice
    SecureBriefingDevice <--> ClassifiedContentServer(Classified Content Server)
    ClassifiedContentServer --> Metadata_Store(Briefing Metadata & Access Policies)
    SecureBriefingDevice --> Connection_Handler
    Connection_Handler --> Secure_DRM_Request(Request DRM Header)
    Secure_DRM_Request <--> ClassifiedContentServer
    SecureBriefingDevice --> DRM_Header_Decryptor
    DRM_Header_Decryptor --> Key_Extraction_Access_Verify(Extract Keys & Verify Access)
    Key_Extraction_Access_Verify --> Byte_Range_Determiner
    Byte_Range_Determiner --> Encrypted_Byte_Requester
    Encrypted_Byte_Requester <--> ClassifiedContentServer
    SecureBriefingDevice --> Crypto_Buffer(Cryptographically Wiped Buffer)
    Crypto_Buffer --> Hardware_Decryptor(Hardware Decryptor - Prior to Decode)
    Hardware_Decryptor --> Video_Audio_Decoder
    Video_Audio_Decoder --> Secure_Display_Audio
    Analyst --> Seek_Event_Trigger(Seek Event Trigger)
    Seek_Event_Trigger --> Pause_Wipe_Buffer(Pause & Cryptographic Wipe Buffer)
    Pause_Wipe_Buffer --> Key_Extraction_Access_Verify
    subgraph Secure Briefing Device
        Connection_Handler
        Secure_DRM_Request
        DRM_Header_Decryptor
        Key_Extraction_Access_Verify
        Byte_Range_Determiner
        Encrypted_Byte_Requester
        Crypto_Buffer
        Hardware_Decryptor
        Video_Audio_Decoder
        Secure_Display_Audio
        Seek_Event_Trigger
        Pause_Wipe_Buffer
    end

Derivative 12.4: Digital Twin Streaming for Protected Industrial Process Monitoring

Enabling Description:
A playback device used in a control room to stream encrypted "digital twin" simulations and real-time sensor data from critical industrial processes. The "video track" represents 3D animated process visualizations, "audio tracks" are process alarms/operator communications, and "subtitle tracks" are real-time telemetry overlays. The content is proprietary and protected by DRM. The device requests a DRM header specific to the process model, decrypts it to obtain keys for that process's data. Index information maps temporal segments of the simulation/sensor data to byte ranges. Encrypted frames of the digital twin visualization and associated telemetry are decrypted before being rendered on the control room displays. A "seek" operation (e.g., fast-forwarding through a simulated fault condition, rewinding to a specific anomaly) pauses the visualization, discards the current buffered encrypted data, requests new byte ranges corresponding to the new temporal focus, re-buffers, re-decrypts, and resumes. This ensures only authorized personnel with the correct DRM keys can access the sensitive operational data.

graph TD
    Operator --> ControlRoomDevice
    ControlRoomDevice <--> ProcessDataServer(Industrial Process Data Server)
    ProcessDataServer --> DRM_License_Server(DRM License Server)
    ControlRoomDevice --> DRM_Header_Request(Request DRM Header - Process Specific)
    DRM_Header_Request <--> DRM_License_Server
    ControlRoomDevice --> DRM_Decryptor
    DRM_Decryptor --> Key_Manager(Extract Keys for Process Data)
    Key_Manager --> Index_Resolver(Index Resolver - Digital Twin Data)
    Index_Resolver --> Byte_Range_Determiner
    Byte_Range_Determiner --> Encrypted_Data_Requester
    Encrypted_Data_Requester <--> ProcessDataServer
    ControlRoomDevice --> Encrypted_Data_Buffer
    Encrypted_Data_Buffer --> Frame_Decryptor(Frame Decryptor - Prior to Render)
    Frame_Decryptor --> Digital_Twin_Renderer(Digital Twin Renderer)
    Digital_Twin_Renderer --> Control_Display(Control Room Display)
    Operator --> Temporal_Seek(Temporal Seek Instruction)
    Temporal_Seek --> Pause_Discard_Buffer(Pause & Discard Buffered Data)
    Pause_Discard_Buffer --> Index_Resolver
    subgraph Control Room Device
        DRM_Header_Request
        DRM_Decryptor
        Key_Manager
        Index_Resolver
        Byte_Range_Determiner
        Encrypted_Data_Requester
        Encrypted_Data_Buffer
        Frame_Decryptor
        Digital_Twin_Renderer
        Control_Display
        Temporal_Seek
        Pause_Discard_Buffer
    end

4. Integration with Emerging Tech

Derivative 12.5: Homomorphic Encryption for DRM Verification with Distributed Key Management

Enabling Description:
The playback device utilizes homomorphic encryption for DRM header verification, allowing the remote DRM server to perform partial computations on encrypted DRM-related data (e.g., license validity checks, user entitlements) without ever decrypting the sensitive information. Key management is distributed across a blockchain network, where private keys for content decryption are fragmented and stored by multiple, geographically dispersed nodes. The playback device reconstructs the decryption key for encrypted frames by retrieving fragments from the blockchain, which are then securely reassembled within a TEE. This distributed key management eliminates a single point of failure for DRM key distribution. When a seek instruction is received, the device discards buffered encrypted frames, requests new byte ranges, and initiates a renewed, homomorphically-verified key request from the distributed key management system before decrypting and playing.

graph TD
    User --> PlaybackDevice
    PlaybackDevice --> TEE(Trusted Execution Environment)
    TEE --> Key_Reconstructor(Key Reconstructor)
    Key_Reconstructor <--> Distributed_Key_Network(Distributed Blockchain Key Network)
    PlaybackDevice --> Homomorphic_DRM_Verifier(Homomorphic DRM Verifier)
    Homomorphic_DRM_Verifier <--> Remote_DRM_Server(Remote DRM Server - Homomorphic Operations)
    PlaybackDevice <--> Content_Server(Content Server)
    Content_Server --> Encrypted_Content_Stream
    PlaybackDevice --> Encrypted_Buffer(Encrypted Frame Buffer)
    Encrypted_Buffer --> TEE
    TEE --> Hardware_Decryptor(Hardware Frame Decryptor)
    Hardware_Decryptor --> Video_Audio_Decoder
    User --> Seek_Instruction
    Seek_Instruction --> Discard_Buffer(Discard Encrypted Buffer)
    Seek_Instruction --> Key_Reconstructor
    Seek_Instruction --> Homomorphic_DRM_Verifier
    subgraph Playback Device
        TEE
        Key_Reconstructor
        Homomorphic_DRM_Verifier
        Encrypted_Buffer
        Hardware_Decryptor
        Video_Audio_Decoder
        Discard_Buffer
    end

5. The "Inverse" or Failure Mode

Derivative 12.6: Offline-First DRM Playback with Limited Time/Segment Access

Enabling Description:
A playback device designed for intermittent or no network access (e.g., in-flight entertainment, remote field operations). Prior to disconnection, the device proactively caches a "partial DRM license" that permits offline playback of pre-selected content segments for a limited duration or a specific number of views. The DRM header includes a time-to-live (TTL) or view-count. Once offline, the device can only access and decrypt content within these pre-authorized segments. If a user attempts to "seek" outside the licensed offline segments, playback is halted, and a "DRM Unavailable" message is displayed, indicating that new byte ranges cannot be requested or decrypted. Decryption of frames still occurs prior to decoding, but relies entirely on the pre-cached license data. The device logs all offline playback activity, which is synchronized back to the remote DRM server upon reconnection, enabling audit and usage tracking. If the TTL expires offline, all decrypted content in the buffer is immediately purged.

stateDiagram-v2
    state Online {
        Connect_to_Server
        Obtain_Full_License
        Download_Offline_License
        Proactive_Cache_Content
    }
    state Offline {
        Use_Cached_License
        Limited_Segment_Access
        Log_Offline_Usage
        Purge_Expired_Content
    }
    state ContentUnavailable {
        Display_DRM_Unavailable
        Halt_Playback
    }

    [*] --> Online
    Online --> Offline: Disconnect_Network
    Offline --> Online: Reconnect_Network
    Offline --> ContentUnavailable: Seek_Outside_Licensed_Segment / License_Expired
    ContentUnavailable --> Online: Reconnect_Network
    ContentUnavailable --> Offline: New_Offline_License_Obtained

---

Independent Claim 20 Derivatives (Method of Playback)

Core Claim 20 elements for derivation:

• Establishing connection, obtaining info (video, multiple audio, multiple subtitle tracks).
• Selecting video/audio tracks, requesting header, obtaining index information.
• Determining and requesting byte ranges using index.
• Buffering and checking for sufficient data for playback.
• Responding to seek: pausing, re-determining new byte ranges, re-requesting, re-buffering, re-checking, resuming playback.

1. Material & Component Substitution

Derivative 20.1: Neuromorphic Computing for Adaptive Playback

Enabling Description:
A method of playback on a device employing a neuromorphic computing chip for adaptive playback control. Instead of a traditional processor executing sequential instructions, the neuromorphic chip (e.g., IBM TrueNorth, Intel Loihi) dynamically learns and adapts the byte range request strategy. Obtaining information, selecting tracks, and index resolution are performed by a conventional CPU, but the "determining byte ranges to request" and "responding to a received seek instruction" steps are offloaded to the neuromorphic hardware. This hardware continuously analyzes playback engine buffer states, network conditions, and learned user seek patterns to dynamically adjust the size, priority, and number of concurrent byte range requests, optimizing for minimal latency and buffer underrun. Buffering is managed by a high-density memristor-based memory array directly integrated with the neuromorphic chip, capable of content-addressable memory (CAM) lookup for byte range presence.

graph TD
    User --> PlaybackDevice
    PlaybackDevice --> CPU_Frontend(Conventional CPU - Frontend Tasks)
    CPU_Frontend --> Info_Obtainer(Obtain Info)
    CPU_Frontend --> Track_Selector(Select Tracks)
    CPU_Frontend --> Header_Requester(Request Header)
    CPU_Frontend --> Index_Resolver(Resolve Index)
    CPU_Frontend --> Neuromorphic_Chip(Neuromorphic Computing Chip)
    Neuromorphic_Chip --> Byte_Range_Determiner_Adaptive(Adaptive Byte Range Determiner)
    Neuromorphic_Chip --> Seek_Response_Learner(Learned Seek Response)
    Byte_Range_Determiner_Adaptive --> Byte_Range_Requester
    Byte_Range_Requester <--> Remote_Server(Remote Server System)
    PlaybackDevice --> Memristor_Buffer(Memristor-based CAM Buffer)
    Memristor_Buffer --> Playback_Engine
    User --> Seek_Instruction_Input
    Seek_Instruction_Input --> Neuromorphic_Chip
    subgraph Playback Device
        CPU_Frontend
        Neuromorphic_Chip
        Memristor_Buffer
        Playback_Engine
    end

2. Operational Parameter Expansion

Derivative 20.2: Hyperscale Multi-Perspective Volumetric Video Playback

Enabling Description:
A method for playing back hyperscale volumetric video (e.g., light field data, 4D reconstructions) from a remote server, offering free-viewpoint navigation and real-time interaction. The "video track" comprises distinct volumetric data streams (e.g., point clouds, voxels), "audio tracks" include spatialized audio, and "subtitle tracks" are dynamic metadata for object identification within the 3D scene. Index information identifies byte ranges corresponding to specific spatio-temporal voxels or point sets. The method establishes multiple high-throughput connections (e.g., HTTP/3 over multiple paths) to parallelize byte range requests. A seek instruction (e.g., user navigating viewpoint, zooming into a 3D object) triggers pausing, discarding of prior view-dependent buffered data, re-determination of byte ranges optimized for the new viewpoint using a frustum culling algorithm, requesting these new byte ranges, and resuming rendering of the volumetric scene with sub-frame latency. Buffering prioritizes "critical path" data for the current viewpoint and dynamically loads peripheral data at lower priority.

graph TD
    User --> PlaybackDevice
    PlaybackDevice <--> Multiple_HTTP3_Connections(Multiple HTTP/3 Connections)
    Multiple_HTTP3_Connections <--> Remote_Volumetric_Server(Remote Volumetric Video Server)
    Remote_Volumetric_Server --> Volumetric_Data_Store(Volumetric Data Store - Voxels/Point Clouds)
    PlaybackDevice --> Volumetric_Info_Processor(Volumetric Info Processor)
    Volumetric_Info_Processor --> Spatio_Temporal_Index_Resolver(Spatio-Temporal Index Resolver)
    Spatio_Temporal_Index_Resolver --> Byte_Range_Determiner_Frustum(Frustum-Culling Byte Range Determiner)
    Byte_Range_Determiner_Frustum --> Parallel_Byte_Range_Requester
    Parallel_Byte_Range_Requester <--> Multiple_HTTP3_Connections
    PlaybackDevice --> Dynamic_Volumetric_Buffer(Dynamic Volumetric Buffer - Critical Path Prioritization)
    Dynamic_Volumetric_Buffer --> Volumetric_Renderer(Volumetric Renderer)
    Volumetric_Renderer --> 3D_Display_VR(3D Display / VR Headset)
    User --> Viewpoint_Navigation(Viewpoint Navigation / Zoom)
    Viewpoint_Navigation --> Pause_Discard(Pause & Discard Old View Data)
    Pause_Discard --> Byte_Range_Determiner_Frustum
    subgraph Playback Device
        Volumetric_Info_Processor
        Spatio_Temporal_Index_Resolver
        Byte_Range_Determiner_Frustum
        Parallel_Byte_Range_Requester
        Dynamic_Volumetric_Buffer
        Volumetric_Renderer
        Pause_Discard
    end

3. Cross-Domain Application

Derivative 20.3: Tele-Robotics Control Stream Playback for Remote Operations

Enabling Description:
A method of playing back content on a control station for tele-robotics operations in hazardous environments (e.g., deep-sea exploration, nuclear decommissioning). The "content" is a fused data stream comprising high-definition video from robot-mounted cameras (video track), real-time haptic feedback and acoustic sensor data (audio tracks), and robot diagnostic/environmental telemetry (subtitle tracks). The remote server is the robot's onboard control unit. The method establishes a low-latency, resilient connection. Index information allows for precise byte range requests corresponding to specific sensor readouts or video segments from past operation logs. A "seek" instruction (e.g., reviewing a previous operational segment, fast-forwarding through idle periods) pauses the live feed, re-determines byte ranges for the historical data, requests them, buffers, and plays back the recorded sensor and video stream, enabling detailed forensic analysis of robot performance. This helps operators understand past anomalies and plan future interventions.

graph TD
    Operator --> ControlStation
    ControlStation <--> Remote_Robot_Control(Remote Robot Control Unit / Server)
    Remote_Robot_Control --> Fused_Data_Log_Store(Fused Data Log - Video, Haptic, Acoustic, Telemetry)
    ControlStation --> Stream_Info_Processor
    Stream_Info_Processor --> Track_Selector(Select Video, Haptic, Telemetry)
    Stream_Info_Processor --> Data_Log_Index_Resolver(Data Log Index Resolver)
    Data_Log_Index_Resolver --> Byte_Range_Determiner
    Byte_Range_Determiner --> Byte_Range_Requester
    Byte_Range_Requester <--> Remote_Robot_Control
    ControlStation --> Realtime_Data_Buffer(Real-time Data Buffer)
    Realtime_Data_Buffer --> Tele_Robotics_Display(Tele-Robotics Console Display)
    Operator --> Seek_Log_Instruction(Seek to Log / Review Past Operation)
    Seek_Log_Instruction --> Pause_Live_Feed(Pause Live Feed)
    Seek_Log_Instruction --> Data_Log_Index_Resolver
    Seek_Log_Instruction --> Resume_Log_Playback(Resume Log Playback)
    subgraph Control Station
        Stream_Info_Processor
        Track_Selector
        Data_Log_Index_Resolver
        Byte_Range_Determiner
        Byte_Range_Requester
        Realtime_Data_Buffer
        Tele_Robotics_Display
        Seek_Log_Instruction
        Pause_Live_Feed
        Resume_Log_Playback
    end

Derivative 20.4: Smart Grid Energy Flow Visualization with Historical Data

Enabling Description:
A method for visualizing real-time and historical energy flow data within a smart grid on a control room display. The "video track" is a dynamic animation of grid topology and power flow, "audio tracks" are alerts for anomalies, and "subtitle tracks" represent raw sensor readings from smart meters and substations. The remote server is a central grid management system. The method involves obtaining grid metadata and historical data indexes. Operators select a specific grid region (video track), an alert channel (audio track), and sensor data type (subtitle track). Index information maps historical timestamps and geographical coordinates to byte ranges of stored grid state data. A "seek" instruction (e.g., jumping to a past outage event, fast-forwarding through a load balancing simulation) pauses the real-time visualization, discards current buffered data, determines new byte ranges for the historical context, requests them, buffers, and displays the historical grid state.

graph TD
    Operator --> GridControlStation
    GridControlStation <--> CentralGridManagement(Central Grid Management System)
    CentralGridManagement --> Grid_Metadata_Historical_Data(Grid Metadata & Historical Data Store)
    GridControlStation --> Grid_Info_Processor
    Grid_Info_Processor --> Region_Selector(Select Grid Region)
    Grid_Info_Processor --> Alert_Channel_Selector(Select Alert Channel)
    Grid_Info_Processor --> Sensor_Data_Selector(Select Sensor Data Type)
    GridControlStation --> Time_Geo_Index_Resolver(Temporal/Geographical Index Resolver)
    Time_Geo_Index_Resolver --> Byte_Range_Determiner
    Byte_Range_Determiner --> Byte_Range_Requester
    Byte_Range_Requester <--> CentralGridManagement
    GridControlStation --> Dynamic_Grid_Data_Buffer(Dynamic Grid Data Buffer)
    Dynamic_Grid_Data_Buffer --> Grid_Flow_Visualizer(Grid Flow Visualizer)
    Grid_Flow_Visualizer --> Control_Room_Display
    Operator --> Historical_Seek(Historical Seek Instruction)
    Historical_Seek --> Pause_Realtime(Pause Real-time Visualization)
    Historical_Seek --> Time_Geo_Index_Resolver
    Historical_Seek --> Resume_Historical(Resume Historical Visualization)
    subgraph Grid Control Station
        Grid_Info_Processor
        Region_Selector
        Alert_Channel_Selector
        Sensor_Data_Selector
        Time_Geo_Index_Resolver
        Byte_Range_Determiner
        Byte_Range_Requester
        Dynamic_Grid_Data_Buffer
        Grid_Flow_Visualizer
        Historical_Seek
        Pause_Realtime
        Resume_Historical
    end

4. Integration with Emerging Tech

Derivative 20.5: Quantum-Resistant Encryption & Federated Learning for User Preference Adaptation

Enabling Description:
A method of playback employing quantum-resistant cryptographic algorithms (e.g., lattice-based cryptography) for all data transfer and content integrity verification, safeguarding against future quantum computing attacks. This method integrates federated learning to adapt user preferences for track selection and seek behavior without centralizing sensitive user data. Each playback device trains a local machine learning model based on its user's viewing habits (e.g., preferred audio languages during specific content types, common fast-forward points). Model updates are aggregated in an encrypted, privacy-preserving manner on the remote server using federated learning. This collectively refined model informs the "determining byte ranges to request" step, making predictive requests more accurate for general user behavior, while quantum-resistant hashes ensure integrity of byte ranges and indices.

graph TD
    User --> PlaybackDevice
    PlaybackDevice <--> Quantum_Resistant_TLS(Quantum-Resistant TLS Connection)
    Quantum_Resistant_TLS <--> Remote_Server(Remote Server System)
    Remote_Server --> Content_Store
    Remote_Server --> Federated_Learning_Aggregator
    PlaybackDevice --> Local_ML_Model(Local ML Model - User Preferences)
    Local_ML_Model --> Federated_Learning_Client(Federated Learning Client)
    Federated_Learning_Client <--> Federated_Learning_Aggregator
    PlaybackDevice --> QRES_Index_Resolver(Quantum-Resistant Encrypted Index Resolver)
    QRES_Index_Resolver --> Byte_Range_Determiner_FL(FL-Enhanced Byte Range Determiner)
    Byte_Range_Determiner_FL --> QRES_Byte_Requester(Quantum-Resistant Byte Requester)
    QRES_Byte_Requester <--> Remote_Server
    PlaybackDevice --> Buffer
    Buffer --> Playback_Engine
    User --> Seek_Instruction
    Seek_Instruction --> Byte_Range_Determiner_FL
    subgraph Playback Device
        Local_ML_Model
        Federated_Learning_Client
        QRES_Index_Resolver
        Byte_Range_Determiner_FL
        QRES_Byte_Requester
        Buffer
        Playback_Engine
    end

5. The "Inverse" or Failure Mode

Derivative 20.6: Disaster Recovery Playback with Minimum Viable Content Assurance

Enabling Description:
A method for content playback on a playback device in a disaster recovery scenario, where network bandwidth is extremely limited (e.g., satellite uplink, degraded cellular). The system prioritizes "minimum viable content" (MVC) delivery. When connection is established, instead of full information, the device obtains only a textual synopsis of available media sequences and a low-resolution thumbnail. Index information is truncated to contain only the first keyframe of each major scene. Byte range requests are strictly limited to single, lowest-bitrate video/audio tracks. A "seek" instruction in this mode does not discard the buffered data, but instead queues the new byte range request at lowest priority, allowing the existing segment to play out fully before attempting the new seek, preventing interruption of limited received data. If a connection is lost, the device transparently switches to playing the last fully buffered MVC segment in a loop, providing a "content assurance" fallback.

stateDiagram-v2
    state NormalOperation {
        Full_Bandwidth
        Detailed_Info
        Multi_Track_Selection
        Efficient_Seek
        Dynamic_Buffering
    }

    state DisasterRecovery {
        Limited_Bandwidth
        MVC_Synopsis_Thumbnails
        Truncated_Index
        Single_Low_Bitrate_Track
        Seek_Queued_No_Discard
        Loop_Last_Buffered_Segment
    }
    
    state ConnectionLost {
        Playback_Last_MVC_Segment
    }

    [*] --> NormalOperation
    NormalOperation --> DisasterRecovery: Network_Degradation / Disaster_Event
    DisasterRecovery --> NormalOperation: Network_Restored
    DisasterRecovery --> ConnectionLost: Connection_Lost
    ConnectionLost --> DisasterRecovery: Connection_Reestablished

---

Combination Prior Art Scenarios

These scenarios combine elements of US Patent 10412141 with existing open-source standards to demonstrate obviousness or non-novelty for potential future improvements.

1. HTTP Range Requests with FFmpeg/VLC for Adaptive Stream Seeking

Enabling Description:
Combining the byte range request mechanism (as described in US10412141, specifically in relation to HTTP 1.1 protocol) with the capabilities of open-source media players like FFmpeg or VLC. A client-side FFmpeg-based player (acting as the playback device) uses HTTP Range Requests to obtain specific byte ranges of a video file from an Apache/Nginx web server (remote server). The FFmpeg player first parses the file header (e.g., MP4 'moov' atom) to construct an index in memory, mapping timestamps to byte offsets. Upon a user's seek instruction, the FFmpeg internal logic calculates the nearest keyframe byte offset, issues an HTTP Range Request for that byte range, buffers the received data, and commences decoding and playback using its built-in decoders. This demonstrates the core seeking functionality using byte ranges and an index with widely available open-source tools and standard protocols.

2. DASH.js Playback with Matroska/WebM Container Format and MSE API

Enabling Description:
Utilizing the Dynamic Adaptive Streaming over HTTP (DASH) standard, implemented with the open-source DASH.js player, to stream multimedia content encapsulated in Matroska (WebM) container format (explicitly mentioned in US10412141 as a supported format). The DASH.js player, running in a web browser, fetches a Media Presentation Description (MPD) which acts as the 'information describing tracks' and 'index information' for segmented content. For trick play or seeking, the DASH.js player (playback device) uses the browser's Media Source Extensions (MSE) API to append media segments. When a seek instruction is received, DASH.js identifies the relevant segment(s) from the MPD, issues HTTP requests for those byte ranges (implicitly using byte range requests for segments), clears any previous buffered data in the MSE buffer, and appends the new segments, allowing for rapid seeking within the stream without downloading the entire file. This showcases receiver-driven seeking using standardized formats and APIs.

3. BitTorrent Client with Sparse File Allocation for Progressive Playback

Enabling Description:
Leveraging a standard BitTorrent client (playback device, BitTorrent protocol explicitly mentioned in US10412141 as a transport protocol) to progressively play multimedia content. A custom BitTorrent client is modified to prioritize the download of initial segments and index information of a large media file (.mkv, .mp4, etc.) from a swarm of peers (remote server system). The client, upon obtaining the initial index (or dynamically constructing one as torrent pieces arrive), can then issue requests for specific "byte ranges" by requesting specific torrent pieces from the swarm. The underlying file storage uses sparse file allocation (also explicitly mentioned in US10412141) to quickly reserve disk space without writing zeros. When a user issues a seek instruction, the BitTorrent client dynamically re-prioritizes the download queue to fetch the torrent pieces (byte ranges) corresponding to the new playback location, allowing for non-sequential access and playback before the entire file is downloaded.