Obviousness

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.