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 .
DETAILED ACTION
Claims 1-20 have been examined.
Response to Arguments
Applicant's arguments with respect to the claims have been considered but are moot in view of the new ground(s) of rejection.
On 2/11/26, Applicant amended the independent claims with new features. Applicant’s Remarks address these features. See the new 103 with the addition of Kirby that addresses these new features.
Also, in Applicant’s Remarks dated 2/11/26, Applicant states that the provisional supports the manifest file because the provisional discloses VMAP format. See the detailed discussion of this in the Priority Date section following. Examiner notes that McGowan ‘312 is proper prior art regardless of the Priority Date of the Provisional.
Priority Date
Examiner notes that Applicant original claim 10 has historical and tracked behavior that may Not correspond with the Applicant Spec at [61]. So, the priority date may be the filing date and Not the CON or provisional dates in regards to that feature.
Also, Applicant Provisional 61815111 does Not support independent claim 1 dated 7/1/24. The provisional does Not support manifest or index or behavior as claimed. In Applicant’s Remarks dated 2/11/26, Applicant states that the provisional supports the manifest file because the provisional discloses VMAP format. However, looking at the Provisional, there is disclosure of VMAP and Not manifest file. And, looking at the Spec for the current application, there is disclosure of VMAP. There is also separate disclosure in the current Spec for manifest file. These descriptions occur in separate parts of the Spec for the most part. There is only part of the current Spec where VMAP and manifest are found to be at all compared. Applicant’s Spec states, “[60]… As previously discussed, some embodiments may provide the indication in a VMAP format. Some embodiments may provide the indication in a manifest file.”. Hence, VMAP format and manifest file are found to be separate features. The provisional supports VMAP format. The Spec supports VMAP format and manifest file. Hence, the Provisional is Not found to provide an earlier priority date for the manifest file features.
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-7, 9-17, 19, 20 are rejected under 35 U.S.C. 103 as being unpatentable over McGowan (20120005312) in view of Kirby (20140259044).
Claims 1, 11. Examiner notes Applicant Spec at [61] and behavior. Examiner notes live content at [45] and the variety of streaming receiving devices at [58]. Examiner notes that based on Applicant Spec at [26] the manifest file can also be known as an index file. McGowan ‘312 discloses a method comprising:
receiving, at a content provider server, a request for access to live media content at a client device (Fig. 1, live streaming at [25] and streaming at [3, 4]), wherein:
the live media content comprises a plurality of segments (see segments at [3, 7, 8]), and
the request for access comprises a current time stamp corresponding to a current segment of the plurality of segments (see when and time at [30] and also [49])
McGowan does not explicitly disclose determining, at the content provider server, a session offset representing a difference between a real time of the live media content and the current time stamp. However, McGowan discloses determining starting and ending points for a requested segment based on time of request, “[7]… communicating a media file having a plurality of segments by receiving a request for a first segment of the media file and determining a starting point and an ending point of the requested first segment based, at least in part, on the request.” And, Kirby discloses the time as an offset feature as the delay of the current viewing session from when the broadcast actually started at [78] and claim 20 shows using the beg_offset_sec_from_true_beg feature. And, [78] shows recording the beg_offset_sec_from_true_beg data into the “[78] Linear_viewing _session entity viewing session record” item. This recorded offset info into the Linear_viewing_session functions as the token. This is further shown in Kirby at Fig. 10, [45]. Note that this is fully supported by the Kirby Provisional at page 126 with Table 40. This recorded info is stored and used for coordinating the session play of the particular client. And, Kirby discloses determining, at the content provider server, a session offset representing a difference between a real time of the live media content and the current time stamp (see [78] of Kirby and the beg_offset_sec_from_true_beg feature; note that this is fully supported by the Provisional at page 126 with Table 40; for start time of content see [78] with “same time as program” or see [54] with program aired start time; for embedded timestamps see [15] with real-time and time codes or [86] with timestamps).
Also, Kirby claim 20 is dependent upon claim 16 which shows sessions info at the device including MMDM, MEDM. And, Kirby at [22] shows using for MMDM and MEDM for session coordinating. And, Kirby at [25] shows using Linear_viewing_session info with MMDM and MEDM for coordinating the session viewing. Also, Kiroy Fig. 10 and [45] show storing the linear_viewing_session info so it can be used for controlling viewing session and viewing control and presentation state for that particular client. So, the linear_viewing_session record functions as the token that records the particular client info including offset info for coordinating that particular client playback session. Therefore, it would have been obvious to one having ordinary skill in the art at the time the invention was made to add Kirby’s time offset features for live content to McGowan’s live content and ad insertion. One would have been motivated to do this in order to better provide ads (as seen in McGowan) or better normalize viewings across sessions by numerous device (as stated by Kirby at [78] with the beg_offset_sec_from_true_beg feature).
McGowan further discloses receiving, at the content provider server, at least one predetermined behavior from the client device (behavior at [31, 34, 60]);
identifying, at the content provider server, a subsequent segment of the plurality of segments that follows the current segment ([34, 60, 61]; Figs. 6, 7, 8);
determining, at the content provider server, the subsequent segment corresponds to the at least one predetermined behavior ([34, 60, 61]; Figs. 6, 7, 8);
designating, at the content provider server, the subsequent segment as an advertisement insertion segment ([34, 60, 61] and also [27] with ad insertion; Figs. 6, 7, 8). McGowan does not explicitly disclose based at least in part on the session time offset. However, the prior art of McGowan in view of Kirby renders obvious the offset features above. And, Kirbyfurther discloses the session offset is utilized on subsequent requests of the play session for the client device (see [78] of Kirby and the beg_offset_sec_from_true_beg feature; note that this is fully supported by the Provisional at page 126 with Table 40; also see better “normalize viewings across sessions done by numerous devices” as stated by Kirby at [78] with the beg_offset_sec_from_true_beg feature). Therefore, it would have been obvious to one having ordinary skill in the art at the time the invention was made to add Kirby’s time offset features for subsequent insertion segments for live content to McGowan’s live content and ad insertion. One would have been motivated to do this in order to better provide ads (as seen in McGowan) or better normalize viewings across sessions by numerous device (as stated by Kirby at [78] with the beg_offset_sec_from_true_beg feature).
McGowan further discloses generating, using the content provider server, the live media content for transmission to the client device and a manifest file comprising computer readable instructions for rendering the live media content, wherein the manifest file comprises a request for advertisement content for rendering at the client device during the advertisement insertion segment of the live media content based on the at least one predetermined behavior ([31, 34, 60, 61]; Figs. 6, 7, 8; and Examiner notes that based on Applicant Spec at [26] the manifest file can also be known as an index file, and McGowan ‘312 discloses an index/manifest file for ad insertion [27, 31, 61, 71]).
Claim 2, 12. McGowan does not explicitly disclose the method of claim 1, further comprising: identifying, at the content provider server, an expected time stamp in the live media content when the client device will begin receiving the live media content for rendering at the client device; comparing, at the content provider server, the expected time stamp to a subsequent time stamp corresponding to the subsequent segment; and in response to determining, using the content provider server, the expected time stamp matches the subsequent time stamp, identifying an updated subsequent segment that corresponds to the at least one predetermined behavior for designating as an updated advertisement insertion segment. However, McGowan discloses the time tracking and behavior and ad insertion features above. And, Kirby discloses the time as an offset feature as the delay of the current viewing session from when the broadcast actually started at [78] and claim 20 shows using the beg_offset_sec_from_true_beg feature. And, [78] shows recording the beg_offset_sec_from_true_beg data into the “[78] Linear_viewing _session entity viewing session record” item. This recorded offset info into the Linear_viewing_session functions as the token. This is further shown in Kirby at Fig. 10, [45]. Note that this is fully supported by the Kirby Provisional at page 126 with Table 40. This recorded info is stored and used for coordinating the session play of the particular client.
And, Kirby discloses identifying, at the content provider server, an expected time stamp in the live media content when the client device will begin receiving the live media content for rendering at the client device; comparing, at the content provider server, the expected time stamp to a subsequent time stamp corresponding to the subsequent segment; and in response to determining, using the content provider server, the expected time stamp matches the subsequent time stamp, identifying an updated subsequent segment that corresponds for designating as an updated advertisement insertion segment (see [78] of Kirby and the beg_offset_sec_from_true_beg feature; note that this is fully supported by the Provisional at page 126 with Table 40; for start time of content see [78] with “same time as program” or see [54] with program aired start time; for embedded timestamps see [15] with real-time and time codes or [86] with timestamps), and is utilized on subsequent requests of the play session for the client device (see [78] of Kirby and the beg_offset_sec_from_true_beg feature; note that this is fully supported by the Provisional at page 126 with Table 40; also see better “normalize viewings across sessions done by numerous devices” as stated by Kirby at [78] with the beg_offset_sec_from_true_beg feature).
Also, Kirby claim 20 is dependent upon claim 16 which shows sessions info at the device including MMDM, MEDM. And, Kirby at [22] shows using for MMDM and MEDM for session coordinating. And, Kirby at [25] shows using Linear_viewing_session info with MMDM and MEDM for coordinating the session viewing. Also, Kiroy Fig. 10 and [45] show storing the linear_viewing_session info so it can be used for controlling viewing session and viewing control and presentation state for that particular client. So, the linear_viewing_session record functions as the token that records the particular client info including offset info that | user for coordinating that particular client playback session. Therefore, it would have been obvious to one having ordinary skill in the art at the time the invention was made to add Kirby’s time offset features for live content to McGowan’s live content and ad insertion. One would have been motivated to do this in order to better provide ads (as seen in McGowan) or better normalize viewings across sessions by numerous device (as stated by Kirby at [78] with the beg_offset_sec_from_true_beg feature).
Claim 3, 13. McGowan further discloses the method of claim 1, further comprising: determining, at the content provider server, an amount of time the client device requires to transcode a segment of the plurality of segments; and accounting, at the content provider server, for the amount of time during the identification of the subsequent segment (see provide index to client at [3, 61, 71]).
Claim 4, 14. McGowan further discloses the method of claim 1, further comprising transmitting the manifest file from the content provider server to the client device, wherein the client device is configured to render the live media content based on the manifest file ([27, 31, 61, 71]).
Claim 5, 15. McGowan further discloses the method of claim 1, further comprising receiving, at the content provider server, an indication of a timestamp in the live media content corresponding to commencement of the client device performing one or more of transcoding the live media content for rendering or rendering the live media content for playback (see when and time and start at [30, 49]).
Claim 6, 16. McGowan further discloses the method of claim 1, further comprising retrieving advertisement content based at least in part on the at least one predetermined behavior before commencing playback of portion of live stream content with advertisement break, retrieve ad content based at least in part on predetermined behavior (see behavior at [31, 34, 60, 61]).
Claim 7, 17. McGown further discloses the method of claim 1, further comprising generating, using the content provider server, a token for transmission to the client device, wherein the token comprises computer readable instructions for coordinating advertisement delivery with one or more of transcoding or rendering the advertisement insertion segment (see instance of the index file for a current streaming session that control ad insertion for that session [27], this instance of an index file for the current session to control streaming for that session reads on token in Applicant Spec).
Claim 9, 19. McGowan further discloses the method of claim 7, wherein the token comprises storage instructions for use at one or more of the client device or the content provider server for subsequent playback requests within one or more live media content request and rendering sessions (see index and store at [4] and [25]).
Claim 10, 20. McGowan further discloses the method of claim 1, wherein the at least one predetermined behavior comprises one or more of: tracked requests for displaying an interstitial banner at the client device; client device interaction data corresponding to displays of overlay advertisements; historical playback control patterns executed during preceding live media content rendering sessions at the client device; or client device interactive content settings (see behavior at [31, 34, 60, 61]).
Claims 8, 18 are rejected under 35 U.S.C. 103 as being unpatentable over McGowan (20120005312) in view of Kirby (20140259044) in view of Proffit (20140109103).
Claim 8, 18. McGowan does not explicitly disclose the method of claim 7, wherein the token comprises a computer readable indication of an amount of time the client device requires to transcode a segment of the plurality of segments. However, McGowan discloses measuring time (see when and time and start at [30, 49]) and transcoding ([37, 38, 40]). And, Proffit discloses time for transcoding [53] and also using tokens [100]. Therefore, it would have been obvious to one having ordinary skill in the art at the time the invention was made to add Proffit’s measuring transcoding time to McGowan’s measuring time and transcoding and adding content. One would have been motivated to do this in order to better add content.
Conclusion
The following prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
aa) Note the 3rd Party Submission on 3/24/25 with Patel, Asam, Dhruv (20120116883 20120198492 9380092);
a) Examiner notes ALLOWED parent patent CON applications 14069961 and 18357865, the current application on 2/19/25 did have some transcoding and manifest file but did Not have chunks, delays, index, or API features that were found in the allowed parents;
b) note other PRIOR ART patent by same inventor McGowan patent 8145782 th at has pg_pub 20120005312; and PRIOR ART to McGowan 20120066386 that has ad insertion and manifest files; and McGowan 20120179788 that has a priority art date to 7/12/12 and is prior art depending on the current application provisional;
c) prior art Ma has provisional support for figures 1-7a but Not Fig. 7b; Ma has offset;
d) Majarajh discloses token [615] transcode time [639]; Barnes/Falls/Hamm/Martin/Silverman disclose transcode and amount of time;
e) Barone, Sun, Walker, Chatterje discloses transcoding and ad insertion and relevant features.
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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ARTHUR DURAN whose telephone number is (571)272-6718. The examiner can normally be reached Mon-Thurs, 7-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, Ilana Spar can be reached on (571) 270-7537. 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.
/ARTHUR DURAN/Primary Examiner, Art Unit 3621 3/4/26