DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Response to Arguments
Applicant's arguments filed January 16, 2026 have been fully considered but they are not persuasive.
Applicant argues that the prior art fails to disclose the independent claim features. Specifically, Applicant argues that the claim requires "receiving, by a packager included in a video processing pipeline, an index file corresponding to a source media file, where the index file indicates location information associated with a plurality of encoded portions of the source media file and metadata indicating one or more video encoding properties of the plurality of encoded portions of the source media file.” Remarks on page 8. Applicant further argues “the metadata is separate form the location information, and an assembler included in the video processing pipeline receives the metadata associated with the plurality of encoded portions of the source media file, and the assembler generates the index file based on the metadata independently of the plurality of encoded portions of the source media file.” Applicant argues that none of the cited reference teaches or suggests these limitations.
Examiner respectfully disagrees, and maintains that the combination of Hertel in view of Begen render the claims obvious under 35 USC 103. Hertel discloses a distributed multi-datacenter video packaging system. E.g., title. In Hertel, “certain information regarding representations (e.g., resolution, bitrate, codec, relative quality ranking, etc.) and segments (e.g., duration, addressing scheme) can exist in the manifest file). Begen, which relates to use of metadata for aiding adaptive streaming clients (title), provides “gathering metadata from a plurality of media stream representations that are provided by the input; creating one or more metadata segments corresponding to the plurality of media stream representations in order to generate a metadata track; and making at least a portion of the metadata track available to a client device, where the portion of the metadata track is provided separate from a manifest file.” E.g., abstract. For additional explanation on how Begen combined with Hertel renders the claims obvious, please see the 35 USC 103 rejection section below.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, 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. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 2, 6-8, 11, 12 and 16-21 are rejected under 35 U.S.C. 103 as being unpatentable over Hertel et al. (U.S. Publication No. 2019/0082217 A1, hereinafter referred to as “Hertel”), which was previously recited on PTO-892 of December 11, 2023 in view of Begen et al. (U.S. Patent No. 9,338,209 B1, hereinafter referred to as “Begen”)
Regarding claim 1, Hertel discloses a computer-implemented method for processing media files, the method comprising: (e.g., abstract, figure 8 and paragraphs [0023] and [0079]
receiving, by a packager included in a video processing pipeline, an index file corresponding to a source media file, wherein the index file indicates location information associated with a plurality of encoded portions of the source media file and (“the index may be made up of one or more files that include relevant identifiers utilized by the video packaging and origination service 120 to identify the storage location of the received and processed encoded components.” In addition, the content management service can generate the index based on input from the ingress nodes that can identify the location and attributes on received encoded content segments. Additionally, the content management service can provide the index to all egress nodes information to allow for access to the encoded content segments at the time of responding to requests for streaming content. In this regarding, the egress nodes can dynamically generate content packages by collecting or compiling the stored, processed segments as identified in the index. Index file is received at the egress nodes that relate to streaming content. Index relates to source video content)(e.g., paragraph [0068], see also paragraphs [0015], [0023], [0025], and [0072])
metadata indicating one or more video encoding properties of the plurality of encoded portions of the source media file, (“The content provider can then make at least a subset of the multiple bitrate encoded versions available to clients responsive to a request for a particular encoded bitrate version and format. Generally, a content provider can generate a catalog identifying the video segments and encoded bitrates for each identified video segment. The catalog can be written into a manifest file that is provided to individual client computing devices that have requested the video file. Thereafter, once all the versions of an encoded segment are received by the packaging and origination service, the packaging and origination service is available to receive and process requests for encoded content. More specifically, client computing devices, through a respective software application, can request individual video segments according to the available encoded bitrates and formats as published in the manifest file.” “Such attributes may include geographic information, network location or traffic information, user configurations, general service levels, resource load information, and the like. For example, the video packaging and origination service 120 can identify a computing device that will function as the ingress component 122 and that is located in a region or availability zone that is determined to be proximate to the original content provider 130.”)(e.g., paragraphs [0017], [0018], [0021], [0052], [0053] and [0056])
and wherein an assembler included in the video processing pipeline receives the metadata associated with the plurality of encoded portions of the source media file independently of the plurality of encoded portions of the source media file and (“The catalog can be written into a manifest file that is provided to individual client computing devices that have requested the video file.” “[T]he ingress component 122 causes the generation or updating of an index identifying the location of the received encoded content.” E.g., paragraph [0068]. “The content management service can generate the index based on input from the ingress nodes that can identify the location and attributes on received encoded content segments.” E.g., paragraph [0023]. The attributes are considered to be metadata that is associated with the segments of the source file, which are used to generate the index that is supplied to the egress nodes to allow access to the encoded segments.(e.g., paragraphs [0018], [0023], [0068] and [0069])
the assembler generates the index file based on the metadata independently of the plurality of encoded portions of the source media file; (“the ingress component 122 may store all received encoded content regardless of whether it is duplicative or alternative to what will be used by the video packaging and origination service 120. As will be described in greater detail below, the ingress component 122 can illustratively utilize local storage resources to maintain the received encoded content segments regardless of whether the local storage resources maintain all the received encoded content segments. At (7), the ingress component 122 causes the generation or updating of an index identifying the location of the received encoded content. As will be described below, the index will be utilized by a separate egress component 124 to respond to content requests from requesting entities. Illustratively, the index may be made up of one or more files that include relevant identifiers utilized by the video packaging and origination service 120 to identify the storage location of the received and processed encoded components. In some embodiments, the index files may be serialized in a manner to facilitate transmission of the index to other computing devices or storage in memory.” Since the index includes one or more files that include relevant identifiers utilized… to identify the storage location,” The segments may be stored outside of local storage or location of the received segments – this is considered to be index file being generated based on metadata independently of the plurality of encoded portions of the source media file)(e.g., paragraph [0054])
retrieving two or more encoded portions included in the plurality of encoded portions from at least one storage device based on the index file; and (two or more encoded portions from the plurality of encoded portions are retrieved from the storage device based on the index file. The egress component 124 of the video packaging and origination service 120 processes the received index to identify the storage location of the encoded segments previously processed and stored by the ingress components 122. “Encoded content segments” are considered to be “two or more encoded portions.”)(e.g., figure 8 and paragraphs [0023], [0025], [0029], [0072] and [0073])
generating a packaged media file based on the two or more encoded portions, wherein the packaged media file is subsequently streamed to a client device for playback. (egress component 124 compiles or packages the encoded content to be provided based on the identified storage location of the encoded data stream. At block 810, the egress component 124 causes the transmission of the content responsive to the content request to be streamed to a client device for playback.)(e.g., figure 8 and paragraphs [0023], [0025], [0029], [0035], [0072] and [0073]).
However, Hertel does not appear to specifically disclose wherein the metadata is separate from the location information, and wherein an assembler included in the video processing pipeline receives the metadata associated with the plurality of encoded portions of the source media file independently of the plurality of encoded portions of the source media file and
On the other hand, Begen, which relates to use of metadata for aiding adaptive streaming clients (title), does disclose wherein the metadata is separate from the location information, (“Certain information regarding representations (e.g., resolution, bitrate, codec, relative quality ranking, etc.) and segments (e.g., duration, addressing scheme) can exist in the manifest file.” “gathering metadata from a plurality of media stream representations that are provided by the input; creating one or more metadata segments corresponding to the plurality of media stream representations in order to generate a metadata track; and making at least a portion of the metadata track available to a client device, where the portion of the metadata track is provided separate from a manifest file.” “The encapsulator can produce indices to signal the access point locations to the client. By looking at this information, the client can form the byte-range requests and, by virtue of these byte ranges, the exact size of the fetch is therefore known to the client. But again, the quality information is still not available to the client. Moreover, a constant quality streaming scheme needs certain additional information (referred to as metadata herein) that is not carried inside the manifest file (or indexing boxes).”)(e.g., abstract and col 4 lines 5-8 and 30-39) wherein an assembler included in the video processing pipeline receives the metadata associated with the plurality of encoded portions of the source media file independently of the plurality of encoded portions of the source media file and (“the system of the present disclosure can publish essential metadata in a metadata stream, where enhanced clients could simply fetch this information just like any other media stream. This fetching could occur in parallel to the fetching of the audio/video streams. By using a separate metadata track, the system would avoid adding additional overhead to the manifest file or the media fragments. This would ensure that the manifest size remains small and the media segments remain unmodified. Additionally, standard clients that are not capable of benefiting from the additional metadata would not fetch this track and, instead, run their typical decision algorithms. This simplified approach avoids additional hooks that would otherwise be positioned in the manifest file.”)(e.g., abstract and col 6 lines 19-32).
Hertel discloses an index file that is used to assemble packages having video content segments. E.g., paragraphs [0072]-[0073]. Hertel discloses employing both location information and metadata; however, Hertel does not disclose that the location information and metadata is separate and independently processed. On the other hand, Begen, which also relates to streaming data (title and abstract), does disclose that a manifest file (location information) can be maintained separately from metadata track. E.g., abstract. “Such a framework could allow, for example, additional metadata from multiple media representations to be used to improve streaming capabilities (e.g., constant-quality (CQ) streaming). Additionally, such an architecture could allow the system to achieve enhanced performance without modifying (and subsequently bloating) the client manifest file. Moreover, such a solution can be provided without adding new boxes to media segments or modifying the media segments in a non-backwards-compatible manner: boxes that could result in backwards incompatibility issues, as well as reducing the efficiency of the media segment creation.” E.g., col 2 line 62 – col 3 line 6. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the storage of metadata separate from location data and to access the metadata independently from the location data as disclosed in Begen to Hertel to improve streaming capabilities. Begen: e.g., col 2 line 62 – col 3 line 6.
Regarding claim 2, Hertel in view of Begen discloses the method of claim 1. Hertel in view of Begen further discloses further discloses wherein the location information specifies, for each encoded portion included in the plurality of encoded portions, a location of the encoded portion within the at least one storage device. (location information provides information on location of encoded content segment)(Hertel: e.g., paragraphs [0023], [0054], [0057], [0072] and [0073])(manifest file)(Begen: e.g., abstract).
Regarding claim 6, Hertel in view of Begen discloses the method of claim 1. Hertel further discloses further comprising receiving a request for an encoded version of the source media file from an application, wherein the two or more encoded portions are retrieved and the packaged media file is generated in response to the request. (At block 810, the egress component causes the transmission of the content responsive to the content request from a user on an application or media player.)(e.g., figure 8 and paragraphs [0035] and [0073]).
Regarding claim 7, Hertel in view of Begen discloses the method of claim 6. Hertel further discloses wherein retrieving the two or more encoded portions comprises selecting the two or more encoded portions from the plurality of encoded portions based on the request. (the two or more segments are selected from the plurality of encoded portions based on the request)(e.g., figure 8 and paragraphs [0058], [0066] and [0072]-[0073]).
Regarding claim 8, Hertel in view of Begen discloses the method of claim 6. Hertel further discloses further comprising transmitting the packaged media file to the application for playback. (the egress component causes the transmission of the content responsive to the content request. The transmission of content segments to requesting entities can include a number of interactions and considerate of the specific protocols implemented to stream content.)(e.g., figure 8 and paragraphs [0025], [0062], [0063], [0072] and [0073]).
Regarding claim 11, Hertel discloses one or more non-transitory computer-readable media storing instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of: (non-transitory computer readable storage medium that stores instructions that processors use to execute)(e.g., paragraph [0079])
receiving, by a packager included in a video processing pipeline, an index file corresponding to a source media file, wherein the index file indicates location information associated with a plurality of encoded portions of the source media file and (“the index may be made up of one or more files that include relevant identifiers utilized by the video packaging and origination service 120 to identify the storage location of the received and processed encoded components.” In addition, the content management service can generate the index based on input from the ingress nodes that can identify the location and attributes on received encoded content segments. Additionally, the content management service can provide the index to all egress nodes information to allow for access to the encoded content segments at the time of responding to requests for streaming content. In this regarding, the egress nodes can dynamically generate content packages by collecting or compiling the stored, processed segments as identified in the index. Index file is received at the egress nodes that relate to streaming content. Index relates to source video content)(e.g., paragraph [0068], see also paragraphs [0015], [0023], [0025], and [0072])
metadata indicating one or more video encoding properties of the plurality of encoded portions of the source media file, (“The content provider can then make at least a subset of the multiple bitrate encoded versions available to clients responsive to a request for a particular encoded bitrate version and format. Generally, a content provider can generate a catalog identifying the video segments and encoded bitrates for each identified video segment. The catalog can be written into a manifest file that is provided to individual client computing devices that have requested the video file. Thereafter, once all the versions of an encoded segment are received by the packaging and origination service, the packaging and origination service is available to receive and process requests for encoded content. More specifically, client computing devices, through a respective software application, can request individual video segments according to the available encoded bitrates and formats as published in the manifest file.” “Such attributes may include geographic information, network location or traffic information, user configurations, general service levels, resource load information, and the like. For example, the video packaging and origination service 120 can identify a computing device that will function as the ingress component 122 and that is located in a region or availability zone that is determined to be proximate to the original content provider 130.”)(e.g., paragraphs [0017], [0018], [0021], [0052], [0053] and [0056])
and wherein an assembler included in the video processing pipeline receives the metadata associated with the plurality of encoded portions of the source media file independently of the plurality of encoded portions of the source media file and (“[T]he ingress component 122 causes the generation or updating of an index identifying the location of the received encoded content.” E.g., paragraph [0068]. “The content management service can generate the index based on input from the ingress nodes that can identify the location and attributes on received encoded content segments.” E.g., paragraph [0023]. The attributes are considered to be metadata that is associated with the segments of the source file, which are used to generate the index that is supplied to the egress nodes to allow access to the encoded segments.(e.g., paragraphs [0023], [0068] and [0069])
the assembler generates the index file based on the metadata independently of the plurality of encoded portions of the source media file; (“the ingress component 122 may store all received encoded content regardless of whether it is duplicative or alternative to what will be used by the video packaging and origination service 120. As will be described in greater detail below, the ingress component 122 can illustratively utilize local storage resources to maintain the received encoded content segments regardless of whether the local storage resources maintain all the received encoded content segments. At (7), the ingress component 122 causes the generation or updating of an index identifying the location of the received encoded content. As will be described below, the index will be utilized by a separate egress component 124 to respond to content requests from requesting entities. Illustratively, the index may be made up of one or more files that include relevant identifiers utilized by the video packaging and origination service 120 to identify the storage location of the received and processed encoded components. In some embodiments, the index files may be serialized in a manner to facilitate transmission of the index to other computing devices or storage in memory.” Since the index includes one or more files that include relevant identifiers utilized… to identify the storage location,” The segments may be stored outside of local storage or location of the received segments – this is considered to be index file being generated based on metadata independently of the plurality of encoded portions of the source media file)(e.g., paragraph [0054])
retrieving two or more encoded portions included in the plurality of encoded portions from at least one storage device based on the index file; and (two or more encoded portions from the plurality of encoded portions are retrieved from the storage device based on the index file. The egress component 124 of the video packaging and origination service 120 processes the received index to identify the storage location of the encoded segments previously processed and stored by the ingress components 122. “Encoded content segments” are considered to be “two or more encoded portions.”)(e.g., figure 8 and paragraphs [0023], [0025], [0029], [0072] and [0073])
generating a packaged media file based on the two or more encoded portions, wherein the packaged media file is subsequently streamed to a client device for playback. (egress component 124 compiles or packages the encoded content to be provided based on the identified storage location of the encoded data stream. At block 810, the egress component 124 causes the transmission of the content responsive to the content request to be streamed to a client device for playback.)(e.g., figure 8 and paragraphs [0023], [0025], [0029], [0035], [0072] and [0073]).
However, Hertel does not appear to specifically disclose wherein the metadata is separate from the location information, and wherein an assembler included in the video processing pipeline receives the metadata associated with the plurality of encoded portions of the source media file independently of the plurality of encoded portions of the source media file and
On the other hand, Begen, which relates to use of metadata for aiding adaptive streaming clients (title), does disclose wherein the metadata is separate from the location information, (“Certain information regarding representations (e.g., resolution, bitrate, codec, relative quality ranking, etc.) and segments (e.g., duration, addressing scheme) can exist in the manifest file.” “gathering metadata from a plurality of media stream representations that are provided by the input; creating one or more metadata segments corresponding to the plurality of media stream representations in order to generate a metadata track; and making at least a portion of the metadata track available to a client device, where the portion of the metadata track is provided separate from a manifest file.” “The encapsulator can produce indices to signal the access point locations to the client. By looking at this information, the client can form the byte-range requests and, by virtue of these byte ranges, the exact size of the fetch is therefore known to the client. But again, the quality information is still not available to the client. Moreover, a constant quality streaming scheme needs certain additional information (referred to as metadata herein) that is not carried inside the manifest file (or indexing boxes).”)(e.g., abstract and col 4 lines 5-8 and 30-39) wherein an assembler included in the video processing pipeline receives the metadata associated with the plurality of encoded portions of the source media file independently of the plurality of encoded portions of the source media file and (“the system of the present disclosure can publish essential metadata in a metadata stream, where enhanced clients could simply fetch this information just like any other media stream. This fetching could occur in parallel to the fetching of the audio/video streams. By using a separate metadata track, the system would avoid adding additional overhead to the manifest file or the media fragments. This would ensure that the manifest size remains small and the media segments remain unmodified. Additionally, standard clients that are not capable of benefiting from the additional metadata would not fetch this track and, instead, run their typical decision algorithms. This simplified approach avoids additional hooks that would otherwise be positioned in the manifest file.”)(e.g., abstract and col 6 lines 19-32).
It would have been obvious to combine Begen with Hertel for the same reasons as set forth in claim 1, above.
Claims 12, 16 and 17 have substantially similar limitations as stated in claims 2, 6 and 7, respectively; therefore, they are rejected under the same subject matter.
Regarding claim 18, Hertel in view of Begen discloses the one or more non-transitory computer-readable media of claim 11. Hertel further discloses wherein the request specifies two or more frames included in the source media file, and selecting the two or more encoded portions from the plurality of encoded portions comprises determining that the two or more encoded portions correspond to the two or more frames based on the index file. (The content provider can then make at least a subset of the multiple bitrate encoded versions available to clients responsive to a request for a particular encoded bitrate version and format. client computing devices, through a respective software application, can request individual video segments according to the available encoded bitrates and formats as published in the manifest file. Index is used to determine corresponding frames / segments based on the index file.)(e.g., paragraphs [0018], [0023], [0054] and [0072]).
Regarding claim 19, Hertel in view of Begen discloses the one or more non-transitory computer-readable media of claim 17. Hertel further discloses further comprising receiving a request for an encoded version of the source media file from an application, wherein the two or more encoded portions are retrieved and the packaged media file is generated in response to the request. (The identification and processing of the index is completed substantially contemporaneously with the processing of the content request. Accordingly, the generation of the encoded content segments package that form the content stream is dynamic and can be adjusted by the video packaging and origination service 120. The egress component 124 causes the transmission of the content responsive to the content request.)(e.g., figure 8 and paragraphs [0072]-[0073]).
Regarding claim 20, Hertel discloses a system comprising: one or more memories storing instructions; and one or more processors that are coupled to the one or more memories and, when executing the instructions, perform the steps of: (system having processors and memory)(e.g., figure 3 and paragraphs [0036] and [0079])
receiving, by a packager included in a video processing pipeline, an index file corresponding to a source media file, wherein the index file indicates location information associated with a plurality of encoded portions of the source media file and (“[T]he ingress component 122 causes the generation or updating of an index identifying the location of the received encoded content.” E.g., paragraph [0068]. “The content management service can generate the index based on input from the ingress nodes that can identify the location and attributes on received encoded content segments.” E.g., paragraph [0023]. The attributes are considered to be metadata that is associated with the segments of the source file, which are used to generate the index that is supplied to the egress nodes to allow access to the encoded segments.(e.g., paragraphs [0023], [0068] and [0069])
metadata indicating one or more video encoding properties of the plurality of encoded portions of the source media file, (“The content provider can then make at least a subset of the multiple bitrate encoded versions available to clients responsive to a request for a particular encoded bitrate version and format. Generally, a content provider can generate a catalog identifying the video segments and encoded bitrates for each identified video segment. The catalog can be written into a manifest file that is provided to individual client computing devices that have requested the video file. Thereafter, once all the versions of an encoded segment are received by the packaging and origination service, the packaging and origination service is available to receive and process requests for encoded content. More specifically, client computing devices, through a respective software application, can request individual video segments according to the available encoded bitrates and formats as published in the manifest file.” “Such attributes may include geographic information, network location or traffic information, user configurations, general service levels, resource load information, and the like. For example, the video packaging and origination service 120 can identify a computing device that will function as the ingress component 122 and that is located in a region or availability zone that is determined to be proximate to the original content provider 130.”)(e.g., paragraphs [0017], [0018], [0021], [0052], [0053] and [0056])
the assembler generates the index file based on the metadata independently of the plurality of encoded portions of the source media file; (“the ingress component 122 may store all received encoded content regardless of whether it is duplicative or alternative to what will be used by the video packaging and origination service 120. As will be described in greater detail below, the ingress component 122 can illustratively utilize local storage resources to maintain the received encoded content segments regardless of whether the local storage resources maintain all the received encoded content segments. At (7), the ingress component 122 causes the generation or updating of an index identifying the location of the received encoded content. As will be described below, the index will be utilized by a separate egress component 124 to respond to content requests from requesting entities. Illustratively, the index may be made up of one or more files that include relevant identifiers utilized by the video packaging and origination service 120 to identify the storage location of the received and processed encoded components. In some embodiments, the index files may be serialized in a manner to facilitate transmission of the index to other computing devices or storage in memory.” Since the index includes one or more files that include relevant identifiers utilized… to identify the storage location,” The segments may be stored outside of local storage or location of the received segments – this is considered to be index file being generated based on metadata independently of the plurality of encoded portions of the source media file)(e.g., paragraph [0054])
retrieving two or more encoded portions included in the plurality of encoded portions from at least one storage device based on the index file; and (two or more encoded portions from the plurality of encoded portions are retrieved from the storage device based on the index file. The egress component 124 of the video packaging and origination service 120 processes the received index to identify the storage location of the encoded segments previously processed and stored by the ingress components 122. “Encoded content segments” are considered to be “two or more encoded portions.”)(e.g., figure 8 and paragraphs [0023], [0025], [0029], [0072] and [0073])
generating a packaged media file based on the two or more encoded portions, wherein the packaged media file is subsequently streamed to a client device for playback. (egress component 124 compiles or packages the encoded content to be provided based on the identified storage location of the encoded data stream. At block 810, the egress component 124 causes the transmission of the content responsive to the content request to be streamed to a client device for playback.)(e.g., figure 8 and paragraphs [0023], [0025], [0029], [0035], [0072] and [0073]).
However, Hertel does not appear to specifically disclose wherein the metadata is separate from the location information, and wherein an assembler included in the video processing pipeline receives the metadata associated with the plurality of encoded portions of the source media file independently of the plurality of encoded portions of the source media file and
On the other hand, Begen, which relates to use of metadata for aiding adaptive streaming clients (title), does disclose wherein the metadata is separate from the location information, (“Certain information regarding representations (e.g., resolution, bitrate, codec, relative quality ranking, etc.) and segments (e.g., duration, addressing scheme) can exist in the manifest file.” “gathering metadata from a plurality of media stream representations that are provided by the input; creating one or more metadata segments corresponding to the plurality of media stream representations in order to generate a metadata track; and making at least a portion of the metadata track available to a client device, where the portion of the metadata track is provided separate from a manifest file.” “The encapsulator can produce indices to signal the access point locations to the client. By looking at this information, the client can form the byte-range requests and, by virtue of these byte ranges, the exact size of the fetch is therefore known to the client. But again, the quality information is still not available to the client. Moreover, a constant quality streaming scheme needs certain additional information (referred to as metadata herein) that is not carried inside the manifest file (or indexing boxes).”)(e.g., abstract and col 4 lines 5-8 and 30-39) wherein an assembler included in the video processing pipeline receives the metadata associated with the plurality of encoded portions of the source media file independently of the plurality of encoded portions of the source media file and (“the system of the present disclosure can publish essential metadata in a metadata stream, where enhanced clients could simply fetch this information just like any other media stream. This fetching could occur in parallel to the fetching of the audio/video streams. By using a separate metadata track, the system would avoid adding additional overhead to the manifest file or the media fragments. This would ensure that the manifest size remains small and the media segments remain unmodified. Additionally, standard clients that are not capable of benefiting from the additional metadata would not fetch this track and, instead, run their typical decision algorithms. This simplified approach avoids additional hooks that would otherwise be positioned in the manifest file.”)(e.g., abstract and col 6 lines 19-32).
It would have been obvious to combine Begen with Hertel for the same reasons as set forth in claim 1, above.
Regarding claim 21, Hertel in view of Begen discloses the method of claim 1. Hertel further discloses wherein the metadata associated with the plurality of encoded portions includes location information for each encoded portion included in the plurality of encoded portions, and the assembler combines the location information for each encoded portion when generating the index file. (“At block 714, the ingress component 122 causes the generation or updating of an index identifying the location of the received encoded content. As will be described below, the index will be utilized by a separate egress component 124 or local cache components 129 to respond to content requests from requesting entities. Illustratively, the index may be made up of one or more files that include relevant identifiers utilized by the video packaging and origination service 120 to identify the storage location of the received and processed encoded components.” “if one or more encoded segments are determined to have an error, the video packaging and origination service 120 can receive a different version of the encoded segment from the original content provider 130 or otherwise identify a redundant version of the encoded segment and update the index accordingly. Similarly, if a specific ingress component 122 may be considered offline or unable to process requests or the storage location associated with stored encoded segments blocks becomes unavailable or beyond capacity to service additional information, the video packaging and origination service 120 can select additional or redundant versions of the encoded segment that have been processed and update the index accordingly.”)(e.g., paragraphs [0068]-[0069]).
Claim(s) 9 is rejected under 35 U.S.C. 103 as being unpatentable over Hertel in view of Begen and in further view of Watson et al. (U.S. Publication No. 2014/0143301 A1, hereinafter referred to as “Watson”).
Regarding claim 9, Hertel in view of Begen discloses the method of claim 6. Hertel discloses further comprising storing the packaged media file as an encoded media file (The packing of the encoded content segments for transmission as encoded content streams (e.g., encoded bitrate and format) can occur at the time of request which facilitates the management of individual encoded content segments. Egress component compiles or packages the encoded content to be provided based on the identified storage location of the encoded data stream. As described above, the generation of the packages are illustratively completed substantially in real time and responsive to the request for the content, which facilitates the management of the encoded content.)(e.g., paragraphs [0058] and [0073])
However, neither reference appears to specifically disclose within a file system accessible by the application.
On the other hand, Watson, which also relates to streaming content (title), does disclose further comprising storing the packaged media file as an encoded media file within a file system accessible by the application. (file download application stores the at least part of the encoded version of the source media file as an encoded media file within the file system that can be accessed by the application.)(e.g., figure 3 and paragraphs [0029], [0030] and [0045]).
It would have been obvious to combine Begen with Hertel for the reasons set forth in claim 1, above. Hertel discloses an index file that is used to assemble packages having video content segments. E.g., paragraphs [0072]-[0073]. However, Hertel does not disclose that the packaged file is stored as an encoded version within a file system accessible by the application. On the other hand, Watson, which also relates to streaming content, does disclose that it is known for downloading or storing the content as an encoded media file within a file system accessible by the application. This provides the enhanced ability to view content when network connection is unavailable. Therefore, it would have been obvious to one of ordinary skill in the art at the time of Applicant’s filing to combine the storing as disclosed in Watson to the Hertel-Begen combination to provide the ability to view the content when the device is not connected to the network.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action. Any inquiry concerning this communication or earlier communications from the examiner should be directed to RICHARD L BOWEN whose telephone number is (571)270-5982. The examiner can normally be reached Monday through Friday 7:30AM - 4:00PM EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Aleksandr Kerzhner can be reached at (571)270-1760. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/RICHARD L BOWEN/ Primary Examiner, Art Unit 2165