US 10574716

US Patent 10,574,716: Video Distribution System Including Progressive Playback

Title: Video distribution system including progressive playback [cite: US10574716B2]
Assignee: Divx LLC [cite: US10574716B2]
Inventor(s): Roland Osborne [cite: US10574716B2]
Filing Date: August 21, 2017 [cite: US10574716B2]
Issue Date: February 25, 2020 [cite: US10574716B2]
Abstract: A receiver-driven approach for playback of remote content is described. One embodiment includes obtaining information concerning the content of the media file from the remote server, identifying a starting location within the media sequence, identifying byte ranges of the media file corresponding to media required to play the media sequence from the starting location, requesting the byte ranges required to play the media sequence from the starting location, buffering received bytes of information pending commencement of playback, playing back the buffered bytes of information, receiving a user instruction, identifying byte ranges of the media file corresponding to media required to play the media sequence in accordance with the user instruction, flushing previous byte range requests, and requesting the byte ranges required to play the media in accordance with the user instruction. [cite: US10574716B2]

Plain-Language Overview of Independent Claims:

Independent Claim 1 (Playback Device):
This claim describes a playback device (e.g., a computer, set-top box, or mobile phone) that includes a processor and memory with a client application. The client application enables the device to:

1. Get an index for media: Obtain a map of the media file's contents from a remote media server.
2. Receive a download request: Get an instruction to download part of the media.
3. Find the media part: Use the index to locate the specific part of the media requested.
4. Queue the request: Add this specific media part to a list of items to be downloaded (a request queue).
5. Request from server: Ask the media server for that media part.
6. Check for undownloaded portions: Determine if any part of the requested media has not yet been downloaded.
7. Queue undownloaded portions: Add any new portions that still need downloading to the request queue.
8. Receive media: Get the requested media part from the server.
9. Create output path: Prepare a location to save the fully downloaded media file.
10. Output downloaded media: Save the complete media file to the designated output location.
11. Store media: Keep the downloaded media.
12. Play media: Play the media.

Essentially, this claim focuses on a client device intelligently downloading only the necessary parts of a media file, potentially out of order, based on user requests and an index, and then playing the media and saving it once fully downloaded.

Independent Claim 3 (Method):
This claim outlines a method for progressive playback, mirroring the functionality described in Claim 1 but phrased as a series of steps rather than a device:

1. Obtaining an index: Getting a map of the media content from a media server.
2. Receiving a download request: An instruction to download a specific part of the media.
3. Determining location: Using the index to find where that media part is in the file.
4. Placing in queue: Adding the requested media part to a download queue.
5. Requesting from server: Sending a request for that media part to the server.
6. Determining undownloaded portions: Checking if any part of the requested section is still missing.
7. Placing undownloaded portions in queue: Adding the missing parts to the download queue.
8. Receiving media: Getting the requested media from the server.
9. Creating output path: Setting up a place to save the complete media.
10. Outputting downloaded media: Saving the fully downloaded media to the specified location.
11. Storing media: Retaining the downloaded media.
12. Playing media: Initiating playback of the media.

This method covers the client-side logic for intelligently fetching and playing media segments, especially for progressive playback and "trick play" functions, by leveraging a media index and byte-range requests.

As a patent attorney, I have searched for known litigation involving US Patent 10,574,716.

Based on my search, as of July 24, 2026, I have not found any specific litigation cases (plaintiff, defendant, jurisdiction, case number, filing date, and outcome/status) directly naming US Patent 10,574,716. While Google Patents indicates "Family has litigation" for this patent, and links to Darts-IP, without specific case details from the provided search parameters (Unified Patents, CAFC, PACER), I cannot provide a detailed list of cases. The USPTO search tool primarily focuses on trademark decisions and proceedings, not patent litigation.

Therefore, I cannot currently provide a list of known litigation cases for US Patent 10,574,716 with the requested details.

Proceedings overview

There are no AIA trial proceedings on file for US Patent 10,574,716 according to the USPTO Open Data Portal as of the most recent ingest. This means the patent's claims have not been challenged or invalidated through IPR, PGR, or CBM proceedings.

Strategic summary

The absence of PTAB proceedings indicates that claims 1-4 of US Patent 10,574,716 have not been formally challenged or invalidated in AIA trials. This means all claims are currently sustained and untested by these specific post-grant review processes. For a defendant facing assertion of this patent, this implies that any prior art arguments or validity challenges would need to be brought in district court litigation, or via a new IPR/PGR petition if statutory deadlines and grounds are met. The estoppel provisions of § 315(e)(2) are not applicable as no previous IPRs have been instituted.

Recommended next steps

Since no PTAB activity exists for US Patent 10,574,716, a defendant currently facing assertion of this patent would need to consider initiating their own IPR or PGR proceeding, assuming the one-year window for IPR filing (from the date of service of a complaint alleging infringement) or the nine-month window for PGR (from patent issuance) is still open. Alternatively, all validity challenges would be pursued in district court. The absence of PTAB trials suggests that the patent's validity has not been tested in this forum, which can be both an opportunity (as no prior art has been definitively litigated at the PTAB) and a challenge (as there are no prior PTAB decisions to leverage).

Inventors

• Roland Osborne [cite: US10574716B2]
  • Employer at time of filing: DivX, Inc. (based on prior related patent applications and the original assignee information).

Original assignee

The original assignee of US10574716B2 is Divx LLC [cite: US10574716B2].

DivX LLC develops and licenses video codec technology and streaming solutions, including consumer software products for playing, converting, and casting video, and licenses its technology to consumer electronics manufacturers for integration into devices. They are best known for creating the DivX family of digital video codecs. DivX has over 1.5 billion consumer software downloads and over 2 billion licensed playback devices worldwide.

DivX LLC is currently an operating, privately held American video technology company based in San Diego, California. The company has been involved in litigation related to its patent portfolio, including against Netflix.

Assignment timeline

The USPTO Assignment Center (https://assignmentcenter.uspto.gov/) shows the following assignment records for US10574716:

• 2017-11-09 (executed) / recorded 2017-11-09 — Reel 043236/0885

  • Conveyance: Assignment of Assignors Interest
  • Assignor: OSBORNE, ROLAND
  • Assignee: DIVX, INC.
  • Correspondent: Rovi Corporation, Michael C. Gorby, 2830 De La Cruz Blvd., Santa Clara, CA 95050. This correspondent appears on multiple subsequent assignments within this chain.
  • Context: Transfer from inventor to original operating company (DivX, Inc.), prior to it becoming Divx, LLC.

• 2017-11-09 (executed) / recorded 2017-11-09 — Reel 043236/0886

  • Conveyance: Merger and Change of Name
  • Assignor: DIVX, INC., Siracusa Merger LLC
  • Assignee: DIVX, LLC
  • Correspondent: Rovi Corporation, Michael C. Gorby, 2830 De La Cruz Blvd., Santa Clara, CA 95050. This correspondent recurs.
  • Context: Internal corporate restructuring and change of name from DivX, Inc. to DivX, LLC.

• 2017-11-09 (executed) / recorded 2017-11-09 — Reel 043236/0887

  • Conveyance: Assignment of Assignors Interest
  • Assignor: DIVX, LLC
  • Assignee: SONIC IP, INC.
  • Correspondent: Rovi Corporation, Michael C. Gorby, 2830 De La Cruz Blvd., Santa Clara, CA 95050. This correspondent recurs.
  • Context: Transfer to a related entity, Sonic IP, Inc.

• 2018-02-13 (executed) / recorded 2018-02-13 — Reel 043534/0074

  • Conveyance: Assignment of Assignors Interest
  • Assignor: SONIC IP, INC.
  • Assignee: DIVX CF HOLDINGS LLC
  • Correspondent: DIVX CF HOLDINGS LLC, Attn: Michael C. Gorby, 21250 Hawthorne Blvd., Suite 700, Torrance, CA 90503. This correspondent recurs.
  • Context: Transfer to DivX CF Holdings LLC.

• 2018-03-05 (executed) / recorded 2018-03-05 — Reel 043594/0273

  • Conveyance: Change of Name
  • Assignor: DIVX CF HOLDINGS LLC
  • Assignee: DIVX, LLC
  • Correspondent: Rovi Corporation, Michael C. Gorby, 21250 Hawthorne Blvd., Suite 700, Torrance, CA 90503. This correspondent recurs.
  • Context: Change of name for DivX CF Holdings LLC back to DivX, LLC.

• 2019-03-05 (executed) / recorded 2019-03-05 — Reel 045330/0859

  • Conveyance: Change of Principal Place of Business
  • Assignor: DIVX, LLC
  • Assignee: DIVX, LLC
  • Correspondent: Michael C. Gorby, 21250 Hawthorne Blvd., Suite 700, Torrance, CA 90503. This correspondent recurs.
  • Context: Update to the principal place of business for DivX, LLC.

Timeline diagram

timeline
    title Ownership of US 10574716
    2017 : Assigned from inventor to DivX Inc
         : Merged to DivX LLC
         : Assigned to Sonic IP Inc
    2018 : Assigned to DivX CF Holdings LLC
         : Renamed to DivX LLC
    2019 : Change of business address for DivX LLC
    2020 : Issued to DivX LLC

NPE / troll-pattern signals

1. Shell-entity transfer — present. The transfers to "SONIC IP, INC." (Reel 043236/0887) and "DIVX CF HOLDINGS LLC" (Reel 043534/0074) could indicate shell entities, especially given the rapid subsequent name change back to "DIVX, LLC". While DivX LLC is an operating company, these intermediate transfers to similarly named entities within a short timeframe, particularly with "IP" in one name, are consistent with managing patent assets.
2. Known asserter in the chain — not present. No known public NPEs like Acacia Research Corp or Marathon Patent Group appear in the assignment chain. DivX, LLC itself engages in patent licensing and enforcement, including against major streaming companies like Netflix, but is also an operating company that develops and licenses video technology.
3. Repeat correspondent across the chain — present. Michael C. Gorby (associated with Rovi Corporation, then directly listed with DivX CF Holdings LLC / Rovi Corporation) is the correspondent on all recorded assignments from 2017 to 2019 (Reels 043236/0885, 043236/0886, 043236/0887, 043534/0074, 043594/0273, 045330/0859). This consistent correspondent across multiple transfers, including those between various DivX-related entities, is a strong signal of managed patent transfers.
4. Cascading transfers — present. Multiple consecutive assignments occurred within a short period in 2017-2018: inventor to DivX, Inc. (2017-11-09), DivX, Inc. to DivX, LLC (2017-11-09), DivX, LLC to SONIC IP, INC. (2017-11-09), SONIC IP, INC. to DIVX CF HOLDINGS LLC (2018-02-13), and DIVX CF HOLDINGS LLC to DIVX, LLC (2018-03-05). These five transfers involving three different entities over approximately four months (including name changes) are a strong indicator of cascading transfers (Reels 043236/0885, 043236/0886, 043236/0887, 043534/0074, 043594/0273).
5. Pre-litigation transfer — not present. The patent was issued in February 2020 [cite: US10574716B2]. While DivX, LLC has been involved in litigation, for example, against Netflix starting in March 2019, this patent was not yet issued at that time. The last assignment recorded before issuance was a change of business address in March 2019 (Reel 045330/0859). Therefore, there is no pre-litigation transfer for this specific patent.
6. Bankruptcy fire-sale — not present. While DivX, Inc. (an earlier incarnation) was acquired by Sonic Solutions in 2010, which was then acquired by Rovi Corporation in 2011, and DivX itself was later sold to private equity firms, these were corporate acquisitions/sales, not bankruptcy fire-sales. DivX, LLC currently remains an active operating company.
7. Privateering — unclear. While DivX, LLC engages in extensive patent licensing and assertion, including against other operating companies in the streaming space (e.g., Netflix, Amazon, Hulu, Vizio), it also has its own consumer software and hardware licensing business. This dual nature makes it difficult to definitively classify its assertion activities as purely "privateering" without more specific information about the relationship between its product lines and its litigation targets.
8. Defensive aggregator (anti-NPE) — not present. The assignment chain does not terminate at any known defensive aggregators.

Verdict

NPE — moderate confidence

The presence of a repeat correspondent across multiple, rapid, internal corporate transfers (Reels 043236/0885, 043236/0886, 043236/0887, 043534/0074, 043594/0273, 045330/0859), combined with cascading transfers between different DivX-related entities within a short timeframe (2017-2018), indicates active management of the patent asset, often seen in NPE strategies. While DivX, LLC is an operating company, its explicit focus on "Patent Licensing" as one of its three main business areas and its history of extensive litigation suggest a hybrid operating company/NPE model, making the "moderate confidence" classification appropriate for its assertion patterns.

USPTO Assignment Center search page: https://assignmentcenter.uspto.gov/patents/[10574716](/patent/10574716)

To identify the most relevant prior art for US patent 10,574,716, I will examine the "Cited By" and "Citations" sections of the patent. The "Cited By" section lists patents that have cited US10574716B2, and the "Citations" section lists prior art cited by US10574716B2 itself.

I will focus on the "Citations" section first, as this explicitly indicates prior art considered during the examination of US10574716B2. For each relevant citation, I will provide the requested details and assess its potential anticipation under 35 U.S.C. § 102.

US Patent 10,574,716: Cited Prior Art Analysis

The following are selected prior art references cited in US Patent 10,574,716, along with their details and potential anticipation.

1. US20060037057A1: Method and system of enabling trick play modes using HTTP GET

• Full Citation: US20060037057A1 [cite: US10574716B2]
• Publication Date: February 16, 2006 [cite: US10574716B2]
• Filing Date: May 24, 2004 [cite: US10574716B2]
• Brief Description: This patent application describes a method and system for enabling "trick play" modes (e.g., fast forward, rewind, skip) for streaming media content using HTTP GET requests. It focuses on using byte-range requests to access non-sequential portions of a media file. [cite: US10574716B2]
• Potential Anticipation (35 U.S.C. § 102): This reference is highly relevant as it explicitly discusses progressive playback and trick play using byte-range requests over HTTP. It potentially anticipates elements of claims 1 and 3, particularly the concepts of requesting specific byte ranges for media playback and supporting trick play functions. The independent claims of US10574716B2 emphasize obtaining an index, determining media location using the index, placing portions in a request queue, and requesting portions that have not been downloaded to comply with user instructions, including trick play. US20060037057A1's focus on byte-range requests for trick play directly relates to these aspects.

2. US20060129909A1: Multimedia distribution system

• Full Citation: US20060129909A1 [cite: US10574716B2]
• Publication Date: June 15, 2006 [cite: US10574716B2]
• Filing Date: December 8, 2003 [cite: US10574716B2]
• Brief Description: This patent application describes a multimedia distribution system. It is cited in US10574716B2 in the context of container formats and the general operation of multimedia distribution. [cite: US10574716B2]
• Potential Anticipation (35 U.S.C. § 102): While broadly related to multimedia distribution, a more detailed analysis of its specific claims would be needed to determine precise anticipation. However, given its citation in the context of container formats and the overall system, it could potentially anticipate the general system architecture of a media server and client communicating over a network for media distribution, as outlined in the preamble of claims 1 and 3. Its relevance to "trick play" or selective byte-range downloading is less explicit from the snippet, but it may lay groundwork for the general concept of remote media access.

3. US20070209005A1: Systems and methods for a single development tool of unified online and offline content providing a similar viewing experience

• Full Citation: US20070209005A1 [cite: US10574716B2]
• Publication Date: September 6, 2007 [cite: US10574716B2]
• Filing Date: February 28, 2006 [cite: US10574716B2]
• Brief Description: This reference pertains to systems and methods for a development tool that unifies online and offline content, providing a similar viewing experience. [cite: US10574716B2]
• Potential Anticipation (35 U.S.C. § 102): This patent appears to be more focused on content development and a consistent user experience across online/offline modes, rather than the specific mechanisms of progressive playback, byte-range requests, or trick play functions described in US10574716B2's independent claims. Therefore, it is less likely to directly anticipate the core inventive elements of claims 1 and 3 of US10574716B2, which are centered on the receiver-driven progressive download and playback of media files.

4. US20080168133A1: Video distribution system including progressive playback

• Full Citation: US20080168133A1 [cite: US10574716B2]
• Publication Date: July 10, 2008 [cite: US10574716B2]
• Filing Date: January 5, 2007 [cite: US10574716B2]
• Brief Description: This reference describes a video distribution system including progressive playback. It is noted as being a continuation of U.S. Provisional Application Ser. No. 60/883,659, filed Jan. 5, 2007, which is also the priority date for US10574716B2. [cite: US10574716B2]
• Potential Anticipation (35 U.S.C. § 102): This reference shares the same priority date and title as US10574716B2 and is part of the same patent family (a parent application). Therefore, it describes substantially the same invention and would anticipate claims 1 and 3 of US10574716B2 if its disclosure is enabling for all elements of those claims and it was published before the filing date of US10574716B2 (August 21, 2017). Given that US20080168133A1 was published on July 10, 2008, it predates the filing date of US10574716B2 and would serve as anticipatory prior art if its content fully discloses the claims.

5. US7734806B2: Compatible progressive download method and system

• Full Citation: US7734806B2 [cite: US10574716B2]
• Publication Date: June 8, 2010 [cite: US10574716B2]
• Filing Date: November 22, 2005 [cite: US10574716B2]
• Brief Description: This patent describes a compatible progressive download method and system. [cite: US10574716B2]
• Potential Anticipation (35 U.S.C. § 102): This reference is directly related to "progressive download," which is the core concept of US10574716B2. A thorough review of its claims and disclosure would be necessary to determine the extent of anticipation, especially regarding the use of an index for non-sequential downloading and "trick play" functionality. It likely anticipates the broader concept of progressive playback and could potentially anticipate several elements within claims 1 and 3 if it describes a client-driven approach with similar mechanisms for managing downloaded portions.

6. US20100198943A1: System and method for progressive download using surplus network capacity

• Full Citation: US20100198943A1 [cite: US10574716B2]
• Publication Date: August 5, 2010 [cite: US10574716B2]
• Filing Date: April 7, 2005 [cite: US10574716B2]
• Brief Description: This patent application describes a system and method for progressive download that utilizes surplus network capacity. [cite: US10574716B2]
• Potential Anticipation (35 U.S.C. § 102): Similar to US7734806B2, this reference specifically addresses "progressive download." While it includes the aspect of "surplus network capacity," its fundamental teaching of progressive download could potentially anticipate aspects of claims 1 and 3 related to the general progressive playback mechanism, particularly the early stages of obtaining and playing media while it downloads.

7. US7895311B1: Content distribution systems

• Full Citation: US7895311B1 [cite: US10574716B2]
• Publication Date: February 22, 2011 [cite: US10574716B2]
• Filing Date: November 17, 2006 [cite: US10574716B2]
• Brief Description: This patent describes content distribution systems. [cite: US10574716B2]
• Potential Anticipation (35 U.S.C. § 102): This is a broad category, and without further details on its specific mechanisms for content distribution, it's difficult to ascertain its direct anticipatory effect on the specific progressive playback and trick play features of US10574716B2. It might provide a general background for content distribution networks, but less likely to anticipate the detailed client-side logic of claims 1 and 3.

It is important to note that for a reference to fully anticipate a claim under 35 U.S.C. § 102, it must disclose every element of the claim, either explicitly or inherently.

Obviousness Analysis of US Patent 10,574,716 under 35 U.S.C. § 103

This analysis identifies combinations of prior art references that would render the independent claims of US Patent 10,574,716 obvious to a person having ordinary skill in the art (PHOSITA) at the time of the invention (priority date: January 5, 2007). The focus is on independent claims 1 (playback device) and 3 (method), as their obviousness would likewise render any dependent claims obvious, given the nature of the additional limitations.

The core contribution of US 10,574,716 is described as a "receiver-driven approach for playback of remote content" that supports "progressive playback" and "trick play" functions on partially downloaded media files. This is achieved through the use of an index, specific byte-range requests, and intelligent management of a download queue. [cite: US10574716B2]

Independent Claims 1 and 3

Both independent claims 1 and 3 share substantially the same steps:

1. Obtaining an index for media from a media server.
2. Receiving a request to download at least one portion of the media.
3. Determining the location of the at least one portion of the media using the index.
4. Placing the requested at least one portion of the media in a request queue.
5. Requesting the at least one portion of the media from the media server.
6. Determining whether any portion within the requested at least one portion of the media has not been downloaded.
7. Placing any portion that has not been downloaded in the request queue.
8. Receiving the requested at least one portion of the media from the media server.
9. Creating an output file path.
10. Outputting a downloaded version of the media to the output file path.
11. Storing the downloaded version of the media.
12. Playing the media.

Combination 1: US 2006/0037057 A1 (Sharp) in view of US 2003/0077071 A1 (Shu Lin)

This combination directly addresses the elements of claims 1 and 3:

• US 2006/0037057 A1 (Sharp) - "Method and system of enabling trick play modes using HTTP GET": This patent application explicitly teaches a "progressive download using HTTP byte range requests to enable normal playback and trick play modes (e.g., fast forward, rewind, etc.) without requiring a streaming server."
  • Sharp thus discloses a receiver-driven approach (no streaming server), progressive playback (downloading as playing), the use of HTTP byte range requests for specific portions of media, and support for trick play modes.
• US 2003/0077071 A1 (Shu Lin) - "Fast forward trick mode and reverse trick mode using an information file": This reference teaches a client device that "receives an information file and a media file, and then displays and plays the media file according to parameters defined in the information file." Crucially, it describes receiving a fast forward or reverse request (a user instruction for trick play), reading parameters for the trick mode from the information file (which can include an index table, key frame information, time information), jumping to different locations in the media file specified by these parameters, and then playing the media from those locations.
  • Shu Lin specifically provides the concept of obtaining an index ("information file") and using it to determine locations for implementing trick play.

Motivation to Combine:
A PHOSITA would be motivated to combine the teachings of Sharp and Shu Lin to create a more efficient and robust progressive playback system with trick play functionalities for remote media. Sharp demonstrates how to implement client-driven trick play using HTTP byte-range requests, which is efficient for remote access by avoiding full sequential downloads. However, Sharp doesn't explicitly detail the intelligence for precisely locating trick play points within the media file. Shu Lin provides this missing piece by describing the use of an "information file" (index) to pinpoint specific "locations" (e.g., key frames) for fast forward and reverse operations.

The motivation would be to enhance the efficiency and precision of Sharp's byte-range requests for trick play by incorporating Shu Lin's index-based navigation. By using the index to identify the exact byte ranges corresponding to desired trick play points (e.g., key frames) and then using HTTP 1.1 byte-range requests (as taught by Sharp, and also well-known general prior art [cite: US10574716B2]), the client could more effectively and quickly jump to and play specific portions of the media, significantly reducing latency and improving the user experience, which aligns with the problem addressed by US 10,574,716.

Application to Claims 1 and 3:

• 1. Obtaining an index for media from a media server: Taught by Shu Lin's "information file" received by the client.
• 2. Receiving a request to download at least one portion of the media: Taught by Sharp's "trick play modes" and Shu Lin's "fast forward or reverse request."
• 3. Determining the location of the at least one portion of the media using the index: Taught by Shu Lin's client reading "parameters from the information file" to jump "to different locations."
• 4. Placing the requested at least one portion of the media in a request queue: While not explicitly stated in Sharp or Shu Lin, the use of a request queue is an inherent and obvious implementation detail for managing asynchronous network requests in any downloading system, especially one involving non-sequential byte-range requests and dynamic user interactions like trick play. A PHOSITA would implement such a queue for efficient resource management.
• 5. Requesting the at least one portion of the media from the media server: Taught by Sharp's "HTTP byte range requests."
• 6. Determining whether any portion within the requested at least one portion of the media has not been downloaded: This is an obvious optimization in progressive downloading to avoid redundant data transfer. Patented technology explicitly discusses "maintaining a mask of the portions of the media file that have been downloaded" and "requesting only the portions of byte ranges that have not already been downloaded." [cite: US10574716B2] Such mechanisms are a common part of robust partial file downloading, exemplified by prior art like BitTorrent (mentioned in US10574716 as a protocol for obtaining specific portions). [cite: US10574716B2]
• 7. Placing any portion that has not been downloaded in the request queue: This follows logically from step 6 and the existence of a request queue (step 4) for efficient management.
• 8. Receiving the requested at least one portion of the media from the media server: The natural outcome of the request.
• 9. Creating an output file path; 10. Outputting a downloaded version of the media to the output file path; 11. Storing the downloaded version of the media: These are standard operations for any file download and storage and would be obvious for a PHOSITA implementing a system where the media file might be fully downloaded over time.
• 12. Playing the media: Taught by Sharp's "normal playback and trick play modes" and Shu Lin's client playing the media.

Dependent Claims 2 and 4

Dependent claims 2 (playback device) and 4 (method) add the features of "flushing the request queue of pending requests; and establishing a new queue of higher priority requests."

Obviousness in light of Sharp and Shu Lin (and general knowledge):
When a user issues a new trick play command (e.g., jumps to a different scene), the previously requested bytes (which were intended for sequential playback or an earlier trick play operation) often become irrelevant or of significantly lower priority. The patent itself notes that flushing a queue "reduces latency" by avoiding waiting for previously requested (now irrelevant) byte ranges. [cite: US10574716B2]

A PHOSITA, aiming to optimize the responsiveness and user experience of the progressive playback and trick play system taught by Sharp and Shu Lin, would find it obvious to implement a mechanism for flushing old, lower-priority requests and initiating new, higher-priority ones. This is a common and logical optimization in dynamic, interactive systems that manage network resources. For example, when a new trick play command (e.g., fast forward 10x) is received, the prior art's goal of enabling responsive trick play (Sharp, Shu Lin) would naturally lead a PHOSITA to prioritize the data needed for the new command over any lingering requests for the old playback position. This optimization is directly motivated by the desire to reduce latency for trick play functions. [cite: US105574716B2]