DETAILED ACTION
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 Amendment
This office action is in response to applicant’s amendment and RCE filed, 02 March 2026, of application filed, with the above serial number, on 19 October 2022 in which claims 27, 38, 46 have been amended. Claims 27, 31-49 are pending in the application.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 27, 31-49 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the enablement requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to enable one skilled in the art to which it pertains, or with which it is most nearly connected, to make and/or use the invention. The claims are amended to add “sending, by the video server device to the video playback client, multiple frames based on the temporal dependent version of the first video stream, the multiple frames from the temporal dependent version corresponding to a portion of the first video stream following the initial video packet, thereby streaming the first video stream to the video playback client, wherein one or more frames immediately following a temporal independent frame in the initial video packet include only temporal dependent frames that are subsequent to the at least one temporal independent”. As outlined in the Interview Summary of 12/8/25, see first paragraph, it is not clear from the amendment how to make or use the invention. It is not clear how the dependent frames can depend on any frame and not a particular frame. For example, from Fig. 1, If D4 and D5 are sent, D4 is dependent on I3 and D5 is dependent on D4. However, the claim amendment would indicate that if D5 is sent as the frame immediately following an I4 independent frame, D5 would also be stored as dependent on I4. It is not clear how to use the invention as claimed as it is not described how D5 can depend on either D4 or I4.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 27, 38, 46 recites the limitation "the video device" and “the playback client” in line 15 of exemplary claim 27. There is insufficient antecedent basis for this limitation in the claim.
Claim 27, 38, 46 recites the limitation "the at least one temporal independent" in line 23 of exemplary claim 27. There is insufficient antecedent basis for this limitation in the claim.
Claims 27, 31-49 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Claim 27, for example, is amended to ‘the initial video packet…ending with at least one temporal independent frame’. First, it is not clear what exactly is meant by a packet ending with a frame, there is no description of sequences or starting or ending frames in a single packet, rather the description describes the initial video packet containing one or more key frames (par. 70; with optional other data, not relevant to claim language). However, it is not clear of the packet ending with a frame. Second, and related to First, it is not clear how the packet can end with a plurality (‘at least one’) of frames. And related to the Second, it is not clear how ‘one or more frames’ can immediately follow a temporal independent frame, as it would be a single frame that would immediately follow a frame.
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.
Claim(s) 27, 32, 36, 38, 40, 44, 46-47 is/are rejected under 35 U.S.C. 103 as being unpatentable over Good et al (hereinafter “Good ‘169”, 2019/0191169) in view of Knothe (hereinafter “Knothe”, 2017/0310752), further in view of Fite et al (hereinafter “Fite”, 2007/0174880).
As per Claim 27, Good ‘169 discloses a method for controlled video streaming from a remote video server device to a video playback client, the method comprising:
storing, at the video server device, a first video stream for retrieval by the video playback client, wherein storing the first video stream comprises storing (i) at least one temporal independent version of the first video stream that includes only key frames decodable independently of other frames (at least paragraph 17; first encoding 130 may have a first key frame (e.g., intracoded frame (I-frame)) interval. In a particular embodiment, the first key frame interval is equal to one frame, i.e., the first encoding 130 includes a key frame for each frame of the input media stream 101; all I-frames), and (ii) at least one temporal dependent version that includes dependent frames that are decodable based on information of other frames (at least paragraph 18; second encoding 140 may have a second key frame interval that is greater than the first key frame interval. For example, the second encoding 140 may be a “normal” key frame interval encoding that includes P-frames and/or B-frames in addition to I-frames);
receiving, at the video server device, a first request from the video playback client, the first request pertaining to streaming of the first video stream from an arbitrary starting point in the first video stream (at least paragraph 24, 42; the first request 362 is generated in response to a user selecting a link to the media stream 304; the request 103 may identify the start point and the stop point shown in FIG. 1. It is noted that in the example of FIG. 1, the start point does not correspond to a key frame. To generate the media clip 104, the clip generator 160 may retrieve a first sequence of frames of the first encoding 130 and a second sequence of frames of the second encoding 140. The first sequence of frames may begin at a first frame 171. The first frame 171 corresponds to the start point indicated by the request 103);
in response to receiving the first request, sending, by the video server device to the video playback client, an initial video packet based on the temporal independent version of the first video stream, the initial video packet corresponding to the arbitrary starting time in the first video stream, and ending with at least one temporal independent frame (at least paragraph 24; the request 103 may identify the start point and the stop point shown in FIG. 1. It is noted that in the example of FIG. 1, the start point does not correspond to a key frame. To generate the media clip 104, the clip generator 160 may retrieve a first sequence of frames of the first encoding 130 and a second sequence of frames of the second encoding 140. The first sequence of frames may begin at a first frame 171. The first frame 171 corresponds to the start point indicated by the request 103);
receiving, at the video device and from the playback client, a second request for frames in addition to the initial video packet (at least paragraph 42-48; second request from manifest(s) for subsequent portions of the stream, ie. in a different bitrate ABR rendition);
sending, by the video server device to the video playback client, multiple frames based on the temporal dependent version of the first video stream, the multiple frames from the temporal dependent version corresponding to a portion of the first video stream following the initial video packet, thereby streaming the first video stream to the video playback client, wherein one or more frames immediately following a temporal independent frame in the initial video packet include only temporal dependent frames that are subsequent to the at least one temporal independent (at least Fig. 1, paragraph 17, 19, 24-25; “first encoding 130 may have a first key frame (e.g., intracoded frame (I-frame)) interval. In a particular embodiment, the first key frame interval is equal to one frame, i.e., the first encoding 130 includes a key frame for each frame of the input media stream 101”; “second encoding 140 may be a “normal” key frame interval encoding that includes P-frames and/or B-frames in addition to I-frames”; the request 103 may identify the start point and the stop point shown in FIG. 1. It is noted that in the example of FIG. 1, the start point does not correspond to a key frame. To generate the media clip 104, the clip generator 160 may retrieve a first sequence of frames of the first encoding 130 and a second sequence of frames of the second encoding 140. The first sequence of frames may begin at a first frame 171. The first frame 171 corresponds to the start point indicated by the request 103; see also Good ‘169 claim 1: “wherein the first sequence begins at a first i-frame of the first encoded version corresponding to the start point and ends at a second i-frame of the first encoded version corresponding to a particular i-frame of the second encoded version, and wherein the second sequence begins at a third frame of the second encoded version following the particular i-frame of the second encoded version…sending, from the server to the destination device, the media clip or a link to the media clip”);
making an updated manifest file available at the video server device for retrieval by the video playback client (at least paragraph 42, 48; media server 350 may send a manifest 363 to the initiating device (e.g., the computing device 371) in response to the first request 362. The manifest 363 may include information describing each of the plurality of ABR rendition(s) 365 (if any) of the media stream 304 and/or the VOD content 358 items. For example, the transcoding template(s) 356 may define particular available ABR rendition(s) 365 of the media stream 304 and the manifest 363 may be automatically generated based on the transcoding template(s) 356);
receiving, at the video server device from the video playback client in response to notifying the video playback client of the updated manifest file, a request for the updated manifest file (at least paragraph 42, 48; media server 350 may send a manifest 363 to the initiating device (e.g., the computing device 371) in response to the first request 362. The manifest 363 may include information describing each of the plurality of ABR rendition(s) 365 (if any) of the media stream 304 and/or the VOD content 358 items. For example, the transcoding template(s) 356 may define particular available ABR rendition(s) 365 of the media stream 304 and the manifest 363 may be automatically generated based on the transcoding template(s) 356);
in response to receiving the request for the updated manifest file, sending the updated manifest file to the video playback client (at least paragraph 42, 48; media server 350 may send a manifest 363 to the initiating device (e.g., the computing device 371) in response to the first request 362).
Good ‘169 fails to explicitly disclose (retrieving the updated manifest file) after notifying, by the video server device, the video playback client of the updated manifest file. However, the use and advantages for using such a system was well known to one skilled in the art before the effective filing date of the claimed invention as evidenced by the teachings of Knothe (at least paragraph 31-34). Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the use of Knothe’s manifest notification with Good ‘169 as Knothe teaches this would allow the client to be notified by either a push notification, message and be notified rather quickly without the client requesting updated or new manifest when there is none and without receiving another manifest that might be the same and having to compare. Rather, with Knothe, when there is an updated manifest the client quickly is notified and retrieves it and will not have an error of having a bad URI when the content requested is no longer accessible as the manifest is stale.
As per Claim 32. The method according to claim 27, wherein the notifying is performed by a notification message outside the first video stream (at least Good ‘169 paragraph 42, 48; Knothe paragraph 31-34).
As per Claim 36. The method according to claim 27, wherein the updated manifest file comprises an identification of a subsequent portion of the first video stream to be streamed by the video playback client (at least paragraph 42-48; second request from manifest(s) for subsequent portions of the stream, ie. in a different bitrate ABR rendition).
As per Claim 47. The one or more non-transitory machine-readable storage devices of claim 46, wherein the notifying is performed by an in-stream information field contained in the first video stream, or by a notification message outside the first video stream (at least Good ‘169 paragraph 42, 48; Knothe paragraph 31-34).
Claims 38, 40, 44, 46 do not, in substance, add or define any additional limitations over claim 27 and therefore are rejected for similar reasons, supra. Claims 38, 46 recite system and CRM class of method claim 27.
Claim(s) 33-35, 37, 41-43, 45, 48-49 is/are rejected under 35 U.S.C. 103 as being unpatentable over Good ‘169 in view of Knothe, further in view of Bjordammen et al (hereinafter “Bjordammen”, 2015/0067722).
As per Claim 33, 41, 48. Good ‘169/ Knothe fail to explicitly disclose wherein the updated manifest file comprises: an identification of at least a second video stream comprising (i) a temporal independent version of the second video stream that includes only key frames decodable independently of other frames and (ii) a temporal dependent version that includes dependent frames that are decodable based on information of other frames; and an instruction for the playback of the second video stream.
However, the use and advantages for using such a system was well known to one skilled in the art before the effective filing date of the claimed invention as evidenced by the teachings of Bjordammen. Bjordammen discloses, in an analogous art, a manifest being updated with ad content and location in order to insert ads into a stream via the manifest file and that the manifest file further has references to the ad content I-Frames (at least Bjordammen paragraph 87-91). Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the use of Bjordammen’s manifest updating with other streams with Good ‘169 and Knothe, as this is well known in the art as evidenced by Bjordammen in order to insert other video segments such as advertisements when streaming content.
As per Claim 34, 42. …Wherein the manifest file further comprises an instruction for resuming the first video stream after the playback of the second video stream (at least Bjordammen paragraph 87-91; playback video after ad).
As per Claim 35, 43. …Further comprising: making a second updated manifest file available for retrieval by the video playback client, the second updated manifest file comprising an instruction for resuming the first video stream; notifying the video playback client of the second updated manifest file; receiving, from the video playback client in response to notifying the video playback client of the second updated manifest file, a request for the second updated manifest file; and in response to receiving the request for the second updated manifest file, sending the second updated manifest file to the video playback client (at least Bjordammen paragraph 87-91; eg. ad break 2 where each ad break has a new manifest as being streamed and returns to the main original tv stream/first stream; once playback of the ad/other stream expires and the user watches the next chunk of the first stream and the main content…)).
As per Claim 37, 45, 49. Good ‘169 and Knothe fail to explicitly disclose wherein the updated manifest file comprises an identification of a metadata event and information configured to allow the video playback client to fetch the metadata event while continuing to play frames from the temporal dependent version of the first video stream. However, the use and advantages for using such a system was well known to one skilled in the art before the effective filing date of the claimed invention as evidenced by the teachings of Bjordammen. Bjordammen discloses, in an analogous art, a manifest being updated with additional metadata (at least Bjordammen paragraph 98). Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the use of Bjordammen’s manifest updating with metadata with Good ‘169 and Knothe, as Good ‘169 and Knothe simply fail to explain in detail everything being updated in a manifest, as this is well known in the art as evidenced by Bjordammen and when a manifest is updated, additional metadata of the stream location and content, particularly for live and adaptive bit rate content, would update metadata to include information on the new content such as bit rate, resolution, etc., metadata that always accompanies the data.
Claim(s) 31, 39 is/are rejected under 35 U.S.C. 103 as being unpatentable over Good ‘169 in view of Knothe, further in view of Lohmar et al (hereinafter “Lohmar”, 2016/0277466).
Good ‘169 and Knothe disclose the client requesting updates of the manifest (at least paragraph 31-34 of Knothe), but fail to explicitly disclose wherein the notifying is performed by an in-stream information field contained in the first video stream. However, the use and advantages for using such a system was well known to one skilled in the art before the effective filing date of the claimed invention as evidenced by the teachings of Lohmar. Lohmar discloses, in an analogous streaming art, updating the manifest file by providing the update either in the header of a response or directly updating the manifest file (at least paragraph 106-110). Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the use of Lohmar’s manifest updating with Good ‘169 and Knothe as this would be an obvious alternative to either have the client separately request the updated manifest file ie. a pull request, or to push the update to the client within the header of the streamed video, both options being well known in the art and having advantages and disadvantages to both but simply being design preference.
Response to Arguments
Applicant’s arguments with respect to claim(s) 27 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Applicant's arguments filed 02 March 2026 have been fully considered but they are not persuasive.
Applicant argues, in substance, that Good ‘169 fails to describe the amendment to claim 27 of receiving two requests for different media frames and sending multiple packets in response as Good ‘169 describes generation of a media clip.
However, while Good describes generation of a video clip in the first embodiments, Good ‘169 also describes continued playback of a stream where a first request is received to retrieve a manifest and additional requests can be sent by the computing device for subsequent frames based on eg. network conditions (at least paragraph 42-48).
The specification discloses in par. 48 “Then, the client 150 proceeds to step 154 in which it requests the subsequent frames of the dependent version 160 of the video. Alternatively, step 154 may also be done in parallel with the first request 152 to further ensure the timely delivery of the dependent frames. At the server 100, the request is received at step 112 upon which the server proceeds to step 113 to retrieve the requested dependent frames. To this respect, the server retrieves the first dependent frame 164 subsequent to the key frame 173 and, thereafter, sends the dependent frame 164 to the client in response. Steps 113 and 114 are then continuously repeated until the last dependent frame 166 of the request is received by the client 150. If there is no end frame or time specified in the request of the client 150, then the server sends the subsequent depending frames up to the end of the video”
Thus, Good ‘169 clearly teaches at least the requests for the clip having the request be at a starting time with the key-frame at the starting time and the request further requesting the remaining frames after the starting time including the frames from the second encoding until the stop point, just as described in par. 48 of Applicant’s specification, ensuring timely delivery of the key frame and subsequent frames.
See also Bjordammen par. 44 for teachings regarding client requesting next segments.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GREGORY TODD whose telephone number is (303)297-4763. The examiner can normally be reached 8:30-5 MST.
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, Nicholas Taylor can be reached on 571-272-3889. 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.
/GREGORY TODD/Primary Examiner, Art Unit 2443
Prosecution Insights