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 .
Response to Arguments
Applicant’s arguments with respect to claim 1 have been considered but are moot because the arguments do not apply in view of newly found reference Zheng being used in the current rejection. See the new rejection 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.
Claims 1-3, 6-10, and 13-14 are rejected under 35 U.S.C. 103 as being unpatentable over US PG Pub 2017/0359628 to Sachdev (“Sachdev”) in view of US PG Pub 2026/0012664 to Zheng (“Zheng”).
Regarding claim 1, “A system (100) for embedding custom metadata in Over-The-Top (OTT) streaming manifests” reads on the system/method that receives a manifest for video requested by a client device (abstract) disclosed by Sachdev and represented in Fig. 1. Sachdev discloses (¶0002-¶0003, ¶0012) customizing adaptive bitrate streaming manifests delivered over OTT network.
As to “the system comprising: an encoder and packager module (108) configured to generate Adaptive Bitrate (ABR) segments and corresponding media manifests for streaming media, the media manifest including instructions for retrieving one or more media segments associated with the streaming media” Sachdev discloses (¶0012) that the a manifest for ABR streaming is generated where the manifest includes links for segments of the video and retrieves metadata a payload; (¶0020) ABR streaming relies on a packager 107 (encoder) to provide multiple different bitrates for the same video as represented in Fig. 1; (¶0028, ¶0034-¶0035) manifest maybe playlist file where the client device determines which variant the client desires, as listed in the variant playlist, receives the corresponding playlist file, and then retrieves media segments referenced in the playlist file.
As to “a manifest updater (112) configured to embed custom metadata within the media manifest, the custom metadata being configured to provide additional playback control information” Sachdev discloses (¶0050, ¶0052) that the manifest manipulator creates a customized manifest for each client and further manifest manipulator retrieves the metadata payload in real-time, such as from metadata payload entities, and insert the metadata payload into the manifest dynamically with the advertisements; (¶0057) customized metadata payload is inserted into the manifest using a configuration; (¶0051) the manifest generated includes placeholders that mark events for the streaming of the video. For example, the placeholders may be insertion points in which manifest manipulator can insert advertisements. Manifest manipulator inserts ads with the metadata payload; the advertisements that are inserted include links in which client device could use to request the advertisements, such as from an advertisement server.
As to “a storage (110) configured to store the generated ABR segments and media manifests with embedded custom metadata” Sachdev discloses (¶0013, ¶0039) that the video segments and manifests are stored at the origin/cache server.
As to “a Content Delivery Network (CDN) (104) configured to deliver the media manifest and the associated ABR segments to one or more client devices (106)” Sachdev discloses (¶0018, ¶0020, ¶0027) that the video and edited manifest is provided to client device over CDN network as represented in Fig. 1 (elements 112, 104).
Sachdev meets all the limitations of the claim except “wherein the custom metadata is embedded in a format that is ignorable by client devices that do not recognize the custom metadata; and wherein the one or more client devices (106) are configured such that: client devices that recognize the custom metadata process the custom metadata to enhance the streaming experience; and client devices that do not recognize the custom metadata continue playback of the streaming media without processing the embedded custom metadata.” However, Zheng discloses (¶0051) that the client application identifies extended metadata fields in the payload of the frame that are included in metadata blocks appended to the payload of the frame after the portion of the encoded media content; the client application configures decoding operations to play back the media content packetized in the frames based on the extended metadata fields if the client application is configured to support the extended metadata fields. In examples where the client application is a legacy client device or a device that does not support extended metadata fields stored in the payload of a frame, such a client device ignores the metadata block(s) and extract only the encoded media content in the payload; (¶0063) the metadata block(s) offer versatility and improved functionality while maintaining backward compatibility with existing media decoders that might be implemented by a client device receiving a bitstream of one or more frames. Legacy client devices or players can process the one or more frames as legacy players by disregarding the metadata block(s). Therefore, it would have been obvious to one of the ordinary skills in the art before the effective filing date of the invention to modify Sachdev’s system by embedding metadata that is processed by the device and/or that is ignorable by the legacy type client device as taught by Zheng in order to enable more advanced codecs to be utilized and transported using such media container formats, which can increase overall streaming and playback quality and further to enable backward compatibility of legacy media container formats with advanced codecs that require additional metadata beyond the limitations imposed by the container format header block, which is particularly advantageous in the context of streaming media content to a wide variety of streaming clients (Zheng - ¶0009).
Regarding claim 2, “The system as claimed in claim 1, wherein the encoder and packager module (108) is configured to generate the media manifest in accordance with at least one of: Dynamic Adaptive Streaming over Hypertext Transfer Protocol (DASH) protocol and Hypertext Transfer Protocol Live Streaming (HLS) protocol” Sachdev discloses (¶0032-¶0033) that the adaptive bitrate streaming method have been implemented in formats including HLS, DASH; HLS format is used to illustrate the principles of manifest files including non-standard variants.
Regarding claim 3, “The system as claimed in claim 2, wherein the manifest updater (112) embeds the custom metadata as a new Extensible Markup Language (XML) element in a Media Presentation Description (MPD) file for the DASH protocol” Sachdev discloses (¶0060, ¶0066-¶0069) that the Xpath uses an XML based response where (¶0071) the value for the identifier is included from a manifest manipulator service response and a fallback included in the configuration if the manifest manipulator service response XML element is not present in the manifest manipulator configuration; (¶0028) a corresponding playlist file in a playlist manifest may be provided. The playlist file identifies the media file segments that are available to client device. It is noted that the terms manifest and playlist files may be referred to interchangeably herein. Also, manifest may be a variant playlist or playlist file. However, for discussion purposes, the manipulation of the manifest may be with the playlist file. In operation, client device determines which variant the client desires, as listed in the variant playlist, receives the corresponding playlist file, and then retrieves media segments referenced in the playlist file.
Regarding claim 6, “The system as claimed in claim 1, wherein the media manifest is transmitted through an adaptive bitrate streaming protocol to optimize playback quality based on real-time network conditions” Sachdev discloses (¶0040) that the use of an adaptive bitrate system that segments media files allows the client to switch between different quality (size) segments of a given asset, as dictated by network performance.
Regarding claim 7, “The system as claimed in claim 1, wherein the custom metadata comprises information for controlling playback features, including one or more of: content advisories, scene-specific annotations, in-scene advertisements, user-specific content settings, and interactive elements” Sachdev discloses (¶0051) that the manifest manipulator inserts advertisements with the metadata payload, where the advertisements that are inserted include links in which client device could use to request the advertisements, such as from an advertisement server.
Regarding claim 8, see rejection similar to claim 1.
Regarding claim 9, see rejection similar to claim 2.
Regarding claim 10, see rejection similar to claim 3.
Regarding claim 13, see rejection similar to claim 6.
Regarding claim 14, see rejection similar to claim 7.
Claims 4-5 and 11-12 are rejected under 35 U.S.C. 103 as being unpatentable over Sachdev in view of Zheng, and further in view of US PG Pub 2023/0056531 to Pedagadi (“Pedagadi”).
Regarding claim 4, “The system as claimed in claim 2, wherein the manifest updater (112) embeds the custom metadata as a custom 8-bit Unicode Transformation Format (UTF-8) tag in an M3U8 playlist for the HLS protocol” Sachdev discloses (¶0033) that in HLS, an m3u8 format is used to illustrate principles of manifest files.
As to “wherein the manifest updater (11) embeds the custom metadata … such that the client devices that do not recognize the custom UTF-8 tag, ignore the tag and continue playback of the streaming media without interruption” Zheng discloses (¶0051) that the client application identifies extended metadata fields in the payload of the frame that are included in metadata blocks appended to the payload of the frame after the portion of the encoded media content; the client application configures decoding operations to play back the media content packetized in the frames based on the extended metadata fields if the client application is configured to support the extended metadata fields. In examples where the client application is a legacy client device or a device that does not support extended metadata fields stored in the payload of a frame, such a client device ignores the metadata block(s) and extract only the encoded media content in the payload; (¶0063) the metadata block(s) offer versatility and improved functionality while maintaining backward compatibility with existing media decoders that might be implemented by a client device receiving a bitstream of one or more frames. Legacy client devices or players can process the one or more frames as legacy players by disregarding the metadata block(s).
Combination of Sachdev and Zheng meets all the limitations of the claim except “the manifest updater (112) embeds the custom metadata as a custom 8-bit Unicode Transformation Format (UTF-8) tag in an M3U8 playlist for the HLS protocol.” However, Pedagadi discloses (¶0026) that the system analyzes streams in real-time and generates metadata for inclusion in a stream; (¶0028-¶0029) video and metadata is multiplexed and provided to a client device where the codec uses UTF-8 encoded packet for video frames in the video data; the server system capable of supporting a protocol for client playback where the server represents http HLS server. Therefore, it would have been obvious to one of the ordinary skills in the art before the effective filing date of the invention to modify Sachdev and Zheng’s systems by embedding the metadata as a UTF-8 tag as taught by Pedagadi in order to synchronize the meta-data with streaming video data on a frame-by-frame basis (Pedagadi - ¶0018).
Regarding claim 5, “The system as claimed in claim 1, wherein the custom metadata is encoded in a base64-encoded JavaScript Object Notation (JSON) format to facilitate flexible, extensible and compact representation of metadata fields” Pedagadi discloses (¶0028, ¶0033, claims 4-5) that the video and metadata is multiplexed and provided to a client device where the metadata is encoded in the JSON file format.
Regarding claim 11, see rejection similar to claim 4.
Regarding claim 12, see rejection similar to claim 5.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 PINKAL R CHOKSHI whose telephone number is (571)270-3317. The examiner can normally be reached Monday - Friday, 8am-5pm.
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, BRIAN T PENDLETON can be reached at (571)272-7527. 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.
/PINKAL R CHOKSHI/Primary Examiner, Art Unit 2425
Prosecution Insights