Obviousness

Under 35 U.S.C. § 103, an invention is considered obvious if "the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains." An obviousness analysis requires identifying prior art, showing that all limitations of the claim are present in the prior art, and demonstrating a motivation for a person having ordinary skill in the art (PHOSITA) to combine the references to achieve the claimed invention.

For US Patent 9762639, the core inventive concept, as outlined in the abstract and summary, involves "dynamically rewriting the timestamps in streams of media that transition from one media source to another (such as from live content to on-demand content, and vice versa)" to ensure continuous timestamps and prevent playback errors. This is achieved by coordinating the creation of a client manifest, which includes "offset information... based on the timing information of the stream of data," with the dynamic creation of media segments.

We will analyze the obviousness of Claim 1, which broadly covers this method:

1. A method of providing media streaming via a data communications network, the method comprising:
   • receiving a stream of data representing live media content;
   • obtaining timing information of the stream of data;
   • receiving, via the data communications network, a request to stream the live media content;
   • creating, with a processing unit, a manifest file, wherein the manifest file includes:
     • information for streaming one or more segments of the live media content via the data communications network;
     • information for streaming one or more segments of a media file, distinct from the live media content; and
     • offset information for streaming the one or more segments of the media file, the offset information based on the timing information of the stream of data; and
   • sending, via the data communications network, the manifest file.

Combination of Prior Art References

A PHOSITA would have been motivated to combine the teachings of:

1. US 8,145,782 B2 ("Dynamic Chunking For Media Streaming"): This patent, which shares the same earliest priority date of June 30, 2010, with US9762639, serves as valid prior art. It teaches methods for processing media streams into smaller "chunks" and storing them for serving to a client. It further describes that a client can request a manifest file (also known as an index file) from a system (e.g., CHIMPS 110), which indicates the locations (e.g., URLs) of each media chunk. The client then uses this manifest file to stream media content by sequentially requesting and receiving multiple manifest files, especially for live media where the stream is still being processed when the client requests the manifest. Thus, US 8,145,782 B2 clearly teaches the dynamic chunking of live media, the creation and sending of manifest files, and the inclusion of information for streaming segments of live media.
2. The "BACKGROUND OF THE INVENTION" section of US9762639 B2 itself: This section explicitly identifies a known technical problem in the art. It states: "The insertion of ads and other on-demand content into a stream of live content can be difficult... because live content can be generated for hours, weeks, or longer, the timestamps associated with live will not be synchronized with the timestamps of ads (or other on-demand content) inserted into the stream of live content. This can cause problems for some clients during playback." This establishes that the issue of timestamp mismatches between live and on-demand content, leading to playback errors, was a recognized problem in the field prior to the claimed invention.

Obviousness Analysis

A PHOSITA in the field of media streaming, familiar with the techniques for dynamic chunking and manifest generation as taught by US 8,145,782 B2, would also be aware of the practical difficulties and playback issues arising from integrating on-demand content (like advertisements) into live media streams, as articulated in the background of US9762639 B2.

The motivation to combine these references would stem from the desire to overcome the acknowledged problem of timestamp discontinuities and the resulting playback errors, thereby providing a seamless and error-free streaming experience for users. Given that US 8,145,782 B2 already describes a system capable of dynamically generating manifest files for live media, it would be a logical and obvious step for a PHOSITA to enhance this system to address the identified timestamp synchronization problem.

Specifically, to address the "timestamps associated with live will not be synchronized with the timestamps of ads (or other on-demand content) inserted into the stream of live content" problem, a PHOSITA would naturally consider how to reconcile these differing timestamps. The most straightforward approach would be to calculate and apply an "offset." The "timing information of the stream of data" (e.g., presentation timestamp (PTS) values, as mentioned in US9762639 B2), which is readily available in a system handling live media, would provide the necessary basis for determining this offset.

Therefore, a PHOSITA would be motivated to modify the manifest generation process described in US 8,145,782 B2 to include "offset information" within the manifest file when inserting segments of a distinct media file (e.g., an advertisement) into the live stream. This offset information would be "based on the timing information of the stream of data" to ensure continuity of timestamps during the transition between live and on-demand content. The API (Application Programming Interface), which is explicitly discussed in US9762639 B2 as being responsible for creating the client manifest and receiving client requests, would be the logical component to perform the calculation of this offset and embed it into the manifest. This modification would be a predictable solution to a known problem, utilizing existing mechanisms of dynamic manifest generation and readily available timing data.

Regarding dependent claims, such as those related to providing a "discontinuity tag" based on client type (e.g., claims 5 and 6), these would also be obvious. The patent itself notes that "some clients may require the discontinuity tag while others may not," and that the API can "determine the type of client... and provide a discontinuity tag if the determined client is of a type that would need such a tag." Given the objective of seamless playback for diverse client devices, it would be a routine matter of engineering and client compatibility for a PHOSITA to conditionally include such a tag in the manifest based on the capabilities or requirements of the requesting client.