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 filed July 22, 2026 have been fully considered but they are not persuasive.
With regard to claim 1, Applicant submits that the cited prior art does not teach “receiving, by the client device and from the first server, an ad manifest patch in response to the first request for the ad manifest, wherein the ad manifest patch comprises information indicative of a storage location for one or more ad segments and playback information associated with the one or more ad segments,” as recited in claim 1. In particular, Applicant submits that Thomas does not teach “playback information associated with the one or more ad segments,” as recited in the claim 1.
In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
Claim 1 is rejected under 35 USC §103 over a combination of Thomas et al. (US 2019/0342356) and Cava et al. (US 2019/0313147).
Thomas teaches:
receiving, by the client device and from the first server, a manifest patch in response to the first request for the manifest ([0087], “For example, the MPEG DASH specification describes a patch mechanism that allows a media server to provide an update of an MPD that is used by a DASH client apparatus by including an MPD patch 1161,2 in a segment box of a media segment transmitted to the client apparatus.” [0088], “MPD stored in the memory of a client apparatus needs to be changed to the address…, a patch may be inserted into one of the segments that is transmitted by the media server to the clients. An MPD that may be updated (either by replacing the full MPD or by replacing one or more parts of an MPD using a patch) may be referred to as a dynamic MPD.” [0129], “these functions enable the patch client module to select one or more manifest file parts 3071-n, i.e. one or more metadata elements, in the manifest file 308 for which the client apparatus would like to request an update (e.g. replacement of the one or more selected metadata elements by a new version of these metadata elements, addition of one or more metadata elements or removal thereof); and, to construct a request message for a network node, e.g. a server, which is configured to receive and process the request and to send information a response message back to the client apparatus.”),
wherein the manifest patch comprises information indicative of a storage location for one or more segments and playback information associated with the one or more segments ([0126], “One or more instruction messages in a patch may instruct the patch integrator 304 to identify information parts (metadata elements) in the stored manifest file and to replace the identified information parts with new information parts in the patch information. … The patch process allows for example insertion of a new URL (e.g. a BaseURL attribute) or replacement of old URL with a new URL that points to a location of a new network node that is capable of transmitting certain (media) segments to the client apparatus.”).
While Thomas provides a teaching for a manifest, a manifest patch, and one or more segments, Thomas does not expressly teach an ad manifest, an ad manifest patch, and one or more ad segments. Thomas also does not expressly teach sending, by the client device and to a second server, a second request for the ad manifest according to the ad manifest patch. While Thomas teaches receiving, by the client device and from the first server, the ad manifest corresponding to the content, Thomas does not expressly teach receiving, by the client device and from the second server, the ad manifest corresponding to the content.
Cava teaches:
advertisement content ([0047], “An in-band stream event may contain information about an advertisement that is inserted into the stream or may be other insertion content.”)
sending, by a client device and to a second server, a second request for an ad manifest ([0109], “A supplemental content manifest may identify supplemental content that can be dynamically inserted into the live stream to replace default content (e.g., default ads) in the live stream.” [0129], “Client 104 uses the status information to send a request for dynamic content replacement. Referring back to FIG. 19, at 1910, client 104 uses the status information, which may be a link or URL to send a supplemental content request to proxy 1902. Accordingly, instead of sending requests to manifest presentation description server 1302, client 104 is re-directed by the status information to send a supplemental content request to proxy 1902.” [0130], “At 1912, proxy 1902 sends the supplemental content request for a manifest to supplemental content manifest server 1304.” Fig. 19), and
receiving, by the client device and from the second server, the ad manifest corresponding to content ([0132], “At 1922, supplemental content manifest server 1304 generates a supplemental content manifest.” [0133], “Proxy 1902 then sends the supplemental content manifest to client 104 at 1924.” Fig. 19).
Taking the teachings of Thomas and Cava together, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Thomas to include an ad manifest, an ad manifest patch, and one or more ad segments, sending, by the client device and to a second server, a second request for the ad manifest according to the ad manifest patch, and receiving, by the client device and from the second server, the ad manifest corresponding to the content. The modification would serve to facilitate management of requests and distribution of advertising content to client devices.
Regarding claims 1-20, Applicant is directed to the following claim rejections for analysis as to how previously-cited prior art teaches the amended claims.
Claim Rejections - 35 USC § 103
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.
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.
Claim(s) 1-4, 7-9, 11-14, and 16-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over a combination of Thomas et al. (US 2019/0342356) and Cava et al. (US 2019/0313147).
Regarding claim 1, Thomas teaches a method comprising:
sending, by a client device and to a first server, a first request for a manifest corresponding to a content ([0084], “At the start of a live-streaming session, a client apparatus may be provided with an address or a URL of a network node 110, e.g. a manifest file (MF) server, which is configured to generate dynamic manifest files. The client apparatus may use the address or URL in order to request a manifest file 112 from the network node.” [0129], “these functions enable the patch client module to select one or more manifest file parts 3071-n, i.e. one or more metadata elements, in the manifest file 308 for which the client apparatus would like to request an update (e.g. replacement of the one or more selected metadata elements by a new version of these metadata elements, addition of one or more metadata elements or removal thereof); and, to construct a request message for a network node, e.g. a server, which is configured to receive and process the request and to send information a response message back to the client apparatus.”);
receiving, by the client device and from the first server, a manifest patch in response to the first request for the manifest ([0087], “For example, the MPEG DASH specification describes a patch mechanism that allows a media server to provide an update of an MPD that is used by a DASH client apparatus by including an MPD patch 1161,2 in a segment box of a media segment transmitted to the client apparatus.” [0088], “MPD stored in the memory of a client apparatus needs to be changed to the address…, a patch may be inserted into one of the segments that is transmitted by the media server to the clients. An MPD that may be updated (either by replacing the full MPD or by replacing one or more parts of an MPD using a patch) may be referred to as a dynamic MPD.” [0129], “these functions enable the patch client module to select one or more manifest file parts 3071-n, i.e. one or more metadata elements, in the manifest file 308 for which the client apparatus would like to request an update (e.g. replacement of the one or more selected metadata elements by a new version of these metadata elements, addition of one or more metadata elements or removal thereof); and, to construct a request message for a network node, e.g. a server, which is configured to receive and process the request and to send information a response message back to the client apparatus.”),
wherein the manifest patch comprises information indicative of a storage location for one or more segments and playback information associated with the one or more segments ([0126], “One or more instruction messages in a patch may instruct the patch integrator 304 to identify information parts (metadata elements) in the stored manifest file and to replace the identified information parts with new information parts in the patch information. … The patch process allows for example insertion of a new URL (e.g. a BaseURL attribute) or replacement of old URL with a new URL that points to a location of a new network node that is capable of transmitting certain (media) segments to the client apparatus.”);
receiving, by the client device and from the first server, the manifest corresponding to the content ([0084], “At the start of a live-streaming session, a client apparatus may be provided with an address or a URL of a network node 110, e.g. a manifest file (MF) server, which is configured to generate dynamic manifest files. The client apparatus may use the address or URL in order to request a manifest file 112 from the network node.”); and
causing playback of one or more segments according to the manifest and the manifest patch ([0084], “The manifest file may comprise a set of chunk or segment identifiers (or information to determine such identifiers) and different (quality) representations of the chunks or segments associated with a media stream. The client apparatus may use chunk or segment identifiers to start requesting chunks by transmitting chunk request messages (e.g. HTTP request messages) to a media server 1021,2 and receive response messages (e.g. in the forms of HTTP response messages) comprising the requested chunks or segments as payload from a media server.” [0094], “Hence, from the above it follows that the patch mechanism may be used in order to instruct a client apparatus to update an MPD by including patch information (i.e. metadata) in a segment box which is sent to the client apparatus wherein the patch information comprises a difference (‘diff’) between the current MPD and the next version of the MPD and instructions to modify the current manifest file on the basis of the difference.”).
While Thomas provides a teaching for a manifest, a manifest patch, and one or more segments, Thomas does not expressly teach an ad manifest, an ad manifest patch, and one or more ad segments. Thomas also does not expressly teach sending, by the client device and to a second server, a second request for the ad manifest according to the ad manifest patch. While Thomas teaches receiving, by the client device and from the first server, the ad manifest corresponding to the content, Thomas does not expressly teach receiving, by the client device and from the second server, the ad manifest corresponding to the content.
Cava teaches:
advertisement content ([0047], “An in-band stream event may contain information about an advertisement that is inserted into the stream or may be other insertion content.”)
sending, by a client device and to a second server, a second request for an ad manifest ([0109], “A supplemental content manifest may identify supplemental content that can be dynamically inserted into the live stream to replace default content (e.g., default ads) in the live stream.” [0129], “Client 104 uses the status information to send a request for dynamic content replacement. Referring back to FIG. 19, at 1910, client 104 uses the status information, which may be a link or URL to send a supplemental content request to proxy 1902. Accordingly, instead of sending requests to manifest presentation description server 1302, client 104 is re-directed by the status information to send a supplemental content request to proxy 1902.” [0130], “At 1912, proxy 1902 sends the supplemental content request for a manifest to supplemental content manifest server 1304.” Fig. 19), and
receiving, by the client device and from the second server, the ad manifest corresponding to content ([0132], “At 1922, supplemental content manifest server 1304 generates a supplemental content manifest.” [0133], “Proxy 1902 then sends the supplemental content manifest to client 104 at 1924.” Fig. 19).
In view of Cava’s teaching, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Thomas to include an ad manifest, an ad manifest patch, and one or more ad segments, sending, by the client device and to a second server, a second request for the ad manifest according to the ad manifest patch, and receiving, by the client device and from the second server, the ad manifest corresponding to the content. The modification would serve to facilitate management of requests and distribution of advertising content to client devices.
Regarding claim 11, Thomas teaches a computing device, comprising: one or more processors; memory; and a set of instructions stored in the memory that, when executed by the one or more processors ([0009]-[0010]), cause the method of claim 1. The grounds of rejection under 35 USC §103 presented with respect to claim 1 are similarly applied to the remaining limitations of claim 11.
Regarding claim 16, Thomas teaches a non-transitory, computer-readable medium comprising a set of computer-executable instructions that, when executed by one or more processors, cause the method of claim 1. The grounds of rejection under 35 USC §103 presented with respect to claim 1 are similarly applied to the remaining limitations of claim 16.
Regarding claims 2, 12, and 17, the combination further teaches further comprising: applying the ad manifest patch to the ad manifest (Thomas: [0087], “The patch may contain metadata, e.g. instructions for the client apparatus and information that needs to be inserted in the manifest file, which—once applied to a certain MPD version i of the MPD - permits to obtain a further MPD version j.”).
Regarding claims 3, 13, and 18, the combination further teaches wherein the applying the ad manifest patch further comprises: determining, from the ad manifest patch, information indicative of the playback information; and inserting the information indicative of the playback information into the ad manifest (Thomas: [0126], “One or more instruction messages in a patch may instruct the patch integrator 304 to identify information parts (metadata elements) in the stored manifest file and to replace the identified information parts with new information parts in the patch information. … The patch process allows for example insertion of a new URL (e.g. a BaseURL attribute) or replacement of old URL with a new URL that points to a location of a new network node that is capable of transmitting certain (media) segments to the client apparatus.”).
Regarding claims 4, 14, and 19, the combination further teaches wherein the information indicative of the playback information is inserted into one or more supplemental property fields of the ad manifest (Thomas: [0126], “One or more instruction messages in a patch may instruct the patch integrator 304 to identify information parts (metadata elements) in the stored manifest file and to replace the identified information parts with new information parts in the patch information. … The patch process allows for example insertion of a new URL (e.g. a BaseURL attribute) or replacement of old URL with a new URL that points to a location of a new network node that is capable of transmitting certain (media) segments to the client apparatus.”).
Regarding claim 7, the combination teaches the limitations specified above; however, the combination as presently combined does not expressly teach further teaches wherein the first server comprises an HTTP server, the second server comprises an ad content delivery network (CDN) server, or both.
Cava teaches an HTTP server, and an ad content delivery network (CDN) server ([0141], “The video streaming system 2500 may include one or more computer servers or modules 2502, 2504, and/or 2507 distributed over one or more computers.” [0150], “Streaming component 2507 may use TCP-based protocols, such as HTTP and Real Time Messaging Protocol (RTMP). … Other protocols used for streaming are Hypertext Transfer Protocol (HTTP) live streaming (HLS) or Dynamic Adaptive Streaming over HTTP (DASH). The HLS and DASH protocols deliver video over HTTP via a playlist of small segments that are made available in a variety of bitrates typically from one or more content delivery networks (CDNs).”).
In view of Cava’s teaching, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination wherein the first server comprises an HTTP server, the second server comprises an ad content delivery network (CDN) server, or both. The modification would serve to facilitate of transmission of content and data throughout the network.
Regarding claim 8, the combination further teaches
wherein sending the second request comprises redirecting the first request, according to the ad manifest patch and to the second server (Cava: [0109], “A supplemental content manifest may identify supplemental content that can be dynamically inserted into the live stream to replace default content (e.g., default ads) in the live stream.” [0129], “Client 104 uses the status information to send a request for dynamic content replacement. Referring back to FIG. 19, at 1910, client 104 uses the status information, which may be a link or URL to send a supplemental content request to proxy 1902. Accordingly, instead of sending requests to manifest presentation description server 1302, client 104 is re-directed by the status information to send a supplemental content request to proxy 1902.” [0130], “At 1912, proxy 1902 sends the supplemental content request for a manifest to supplemental content manifest server 1304.” Fig. 19; Thomas: [0126]).
Regarding claim 9, the combination further teaches wherein the ad manifest patch is received in a redirect response from the first server (Cava: [0128], “Referring back to FIG. 19, at 1906, client 104 sends a patch request for the media presentation.” [0129], “Referring back to FIG. 19, at 1910, client 104 uses the status information, which may be a link or URL to send a supplemental content request to proxy 1902. Accordingly, instead of sending requests to manifest presentation description server 1302, client 104 is re-directed by the status information to send a supplemental content request to proxy 1902.” [0134], “Referring back to FIG. 19, client 104 may then request supplemental content using the link to the supplemental content in the supplemental content manifest. Once the break ends, client 104 may use the status information to revert back to the live stream. For example, client 104 sends a patch request using the status information to manifest presentation description server 1302 at 1926. Then, manifest presentation description server 1302 may generate a differential manifest presentation description for the live stream at 1928. FIG. 23 depicts a patch that is returned to client 104 after the break according to some embodiments.” Fig. 19).
Regarding claim 10, the combination further teaches wherein the redirect response comprises a HTTP 302 redirect response (Cava: [0121], “FIG. 16 depicts another table 1600 for a client query pattern in which different endpoints for the manifest presentation description and the supplemental content manifest are used according to some embodiments. At times t=12 and t=15, manifests for segments a, b, c, d, and e are requested as described above. At time t=18, client 104 sends a request for a supplemental content manifest and is returned a response that causes re-direction, such as a 302 re-direct, that re-directs client 104 to supplemental content manifest server 1304.”).
Claim(s) 5-6, 15, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over a combination of Thomas, Cava, and Tarbox et al. (US 2013/0311670).
Regarding claim 5, 15, and 20, the combination teaches the limitations specified above; however, the combination does not expressly teach wherein the playback information comprises beaconing instructions associated with the one or more ad segments, playback restrictions for the one or more ad segments, or both.
Tarbox teaches wherein the playback information comprises beaconing instructions associated with the one or more ad segments, playback restrictions for one or more segments, or both ([0023], “In a first aspect of the present disclosure, a method comprises generating a top level manifest file for a media asset or stream that includes program event information, providing the top level manifest file and corresponding element manifest files to a real-time adaptive bitrate packager, and receiving a request for a media-segment file from a client, wherein the ABR packager is configured to interpret the program event information, and wherein the ABR packager is configured to restrict trick-play operations if a program event is detected in a requested media-segment file and restriction criteria are met.”).
In view of Tarbox’s teaching, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination wherein the playback information comprises beaconing instructions associated with the one or more ad segments, playback restrictions for the one or more ad segments, or both. The modification would provide a means for enabling advertisers to ensure content is presented on user devices. The modification would thereby enhance the effectiveness of advertising campaigns.
Regarding claim 6, the combination further teaches wherein the playback restrictions comprise a restriction of fast forwarding during playback of the one or more ad segments (Tarbox: [0023], “In a first aspect of the present disclosure, a method comprises generating a top level manifest file for a media asset or stream that includes program event information, providing the top level manifest file and corresponding element manifest files to a real-time adaptive bitrate packager, and receiving a request for a media-segment file from a client, wherein the ABR packager is configured to interpret the program event information, and wherein the ABR packager is configured to restrict trick-play operations if a program event is detected in a requested media-segment file and restriction criteria are met.” [0067], “Using this ad information, ABR Packager 470 knows which particular ABR segments it delivers correspond to advertisement events and can take action to prevent or allow client fast-forwarding or skipping of said segments.”).
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 MICHAEL R TELAN whose telephone number is (571)270-5940. The examiner can normally be reached 9:30AM-6:00PM.
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, Nasser Goodarzi can be reached at (571) 272-4195. 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.
/MICHAEL R TELAN/ Primary Examiner, Art Unit 2426
Prosecution Insights