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
This office action is in response to communication filed 11/11/2025. Claims 1-20 are pending for examination, the rejection cited as stated below.
Claim Rejections - 35 USC § 102
2. 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 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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1, 6, 9, 13, 15 and 19 are rejected under 35 U.S.C. 102(a)(1) and (a)(2) as being anticipated by Tarbox et al (US 2013/0311670 hereafter Tarbox).
As to claim 1, Tarbox discloses a method comprising:
receiving, at a server, a request for a media segment of a media stream to be delivered to
a client (Fig. 5, Step 510, “Client Requests Segment”; [0068], “a client 495 initiates a session at block 510 with the ABR Packager 470 to retrieve specific program segments. As long as the client 495 requests non-ad segments that do not span an ad or placement opportunity, as indicated by arrow 545, the
system remains in the Normal Segment Delivery state 520”);
determining, using a server-based timeline of the media stream, whether the requested media segment is to include primary media content (Fig. 5, step 545, “Request segment does not contain Ad” then step 520, “Normal Segment Delivery”) or secondary media content (Fig. 5, step 525, “Requested segment contains Ad” then step 550, “”Ad” Segment Delivery”; see [0066], “When this content is subsequently retrieved from----or streamed by-NDVR 460 to ABR Packager 470, the specific timeframe for each ad insertion event or placement opportunity may be included in messaging to the ABR Packager 470. This information may once again be conveyed in-band using SCTE-35 signaling, or the NDVR 460 may generate a special manifest file denoting the specific content segments containing advertisements or opportunities. This manifest could be a standard HLS m3u8 play list or DASH manifest, for example, including special tags not intended for end-user client device consumption”; [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”), wherein the timeline defines one or more positions in the media stream to include the secondary media content (see citation above);
responsive to determining that the requested media segment corresponds to a position of the one or more positions defined in the timeline, obtaining, by the server, a secondary media content item ([0068], “As long as the client 495 requests non-ad segments that do not span an ad or placement opportunity, as indicated by arrow 545, the system remains in the Normal Segment Delivery state 520. Otherwise, once an ad segment is requested, as indicated by arrow 525, the system transitions to an Ad Segment Delivery state 550”, wherein the “Ad segment Delivery state” indicates that the server obtains the ad and delivers to the client. See also [0064], “The ABR Packager 470 may also communicate with an Ad Decision System ("ADS") 480 to determine which, if any, local advertisements or alternate content to substitute during an ad break (e.g., ad opportunity”); and
adding a media segment of the secondary media content item to the media stream to provide the requested media segment to the client (see citation and explanation above, e.g., [0064], “The ABR Packager 470 may also communicate with an Ad Decision System ("ADS") 480 to determine which, if any, local advertisements or alternate content to substitute during an ad break (e.g., ad opportunity)”).
As to claim 9, see similar rejection to claim 1.
As to claim 15, see similar rejection to claim 1.
As to claim 6, Tarbox discloses the method of claim 1, wherein obtaining the secondary media content item further comprises: requesting, by the server, selection of one of a plurality of secondary media content items by a secondary media content server; and receiving the secondary media content item from the secondary media content server ([0064], “The ABR Packager 470 may also communicate with an Ad Decision System ("ADS") 480 to determine which, if any, local advertisements or alternate content to substitute during an ad break (e.g., ad opportunity)”).
As to claim 13, see similar rejection to claim 6.
As to claim 19, see similar rejection to claim 6.
Claim Rejections - 35 USC § 103
5. 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 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.
6. 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 of this title, 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.
7. The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
8. Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Tarbox, as applied to claim 1 above, and further in view of Aher et al (US 2021/0314672 A1 hereafter Aher).
As to claim 2, Tarbox discloses the claimed invention substantially as discussed in claim 1, but does not expressly disclose sending metadata associated with the secondary media content item to the client, wherein the metadata corresponds to one or more graphical user interface (GUI) elements to be presented at the client with the secondary media content item.
Aher discloses sending metadata associated with secondary media content item to a client, wherein the metadata corresponds to one or more graphical user interface (GUI) elements to be presented at the client with the secondary media content item (abstract, “system retrieve metadata associated with an advertisement video. The method and system also identify an advertisement option based on the metadata and generate for simultaneous display a skip advertisement option and the advertisement option in a single overlay interface while at least a portion of the advertisement video is being displayed”; [0022], “the ad metadata includes one or more ad options as the additional information corresponding to the advertisement. Some examples of the ad options of the ad metadata include ad identification (Id), title, ad duration, brand name, logo name, brand logo, brand tag line, font style, font color, a hyperlink, product name, product logo”. Here, the client’s system’s retrieval of the metadata is equivalent to sending the metadata to a client that uses the metadata to generate for simultaneous display of advertisement options while at least a portion of the advertisement video is being displayed).
Before the effective filing date of the invention, it would have been obvious for an ordinary skilled in the art to combine Tarbox with Aher. The suggestion/motivation would have been to provide advertisement options (Aher, abstract).
9. Claims 3, 5, 10, 12, 16, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Tarbox, as applied to claim 1 above, and further in view of Nugent (US 20180176623 A1).
As to claim 3, Tarbox discloses the method of claim 1, further comprising sending the timeline of the media stream to the ABR packager, wherein the timeline of the media stream indicates one or more permitted seeking actions available to a user of the client (Tarbox, [0023], “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”, wherein the program event information in the timeline/manifest directly controls which seeking (trick-play) actions are permitted. See [0063]-[0068] for the enforcement mechanism), but does not expressly disclose sending the timeline of the media stream to a user of the client to the client.
Nugent discloses sending the timeline of the media stream indicating one or more permitted seeking actions available to a user of the client to the client ([0026], “As will be discussed below, the client device 204 can be instructed by information provided in a manifest 202 or other file to enable or disable any or all types of trick plays”; [0031], “Each playback control tag 304 can have a field that indicates one or more types of trick plays that are to be enabled or disabled by a client device 204. In some embodiments a manifest 202 can have one playback control tag 304 for each type of trick play being enabled or disabled. In alternate embodiments a single playback control tag 304 can have multiple values to enable or disable more than one type of trick play”; [0032], “In some embodiments all type of trick plays can be disabled by a client device 204 by default, and the client device 204 can enable specific types of trick plays identified by playback control tags 304 in a manifest 202. By way of a non-limiting example, the example manifest 202 shown in FIG. 3 includes playback control tags 304 with a “PAUSE” value that enables pausing, a “FORWARD” value that enables fast-forwarding, and a “REWIND” value that enables rewinding”; [0070], “As described herein, information such as playback control tags 304 and/or output control tags 306 inserted into manifests 202 and/or auxiliary control files 400 can be enforced by client devices 204 to enable or disable restrictions on trick plays and/or video output to other devices”).
Before the effective filing date of the invention, it would have been obvious for an ordinary skilled in the art to combine Tarbox with Nugent. The suggestion/motivation would have been to allow the client to enforce enabling or displaying trick plays (Nugent, [0070]).
As to claim 10, see similar rejection to claim 3.
As to claim 16, see similar rejection to claim 3.
As to claim 5, Tarbox in view of Nugent discloses the method of claim 3, further comprising:
receiving, at the server, an indication of a non-permitted seeking action performed by the user of the client (Tarbox, Fig. 6C1, Client sends “645-Get Segment N+6”, ABR Packager “Reject until Ad Timer expiration -635”, indicating a non-permitted seeking action performed by the user of the client);
receiving, at the server, a request for a second media segment of the media stream to be delivered to the client (Tarbox, see citation above, a request for segment N+6 is received and rejected until ad timer expires. Said rejecting only applies to the non-permitted seeking action, without impacting normal subsequent requests such as a request for a second media segment. It is to be noted that the claim does not require a specific relationship between the non-permitted seeking action and the request for a second media segment, therefore Examiner interprets as any relationship. In addition, the claim does not require a specific timing relationship between the non-permitted seeking action and the request for a second media segment, therefore Examiner interprets as any timing relationship); and
determining, using the server-based timeline of the media stream and irrespective of the indication of the non-permitted seeking action performed by the user of the client, whether the requested second media segment is to include primary media content or secondary media content (Tarbox, see citation and explanation in rejection to the preceding limitations, wherein a normal processing for subsequent requests involves determining, using the server-based timeline of the media stream and irrespective of the indication of the non-permitted seeking action performed by the user of the client, whether the requested second media segment is to include primary media content or secondary media content, see citation in rejection to claim 1. See also [0068], “In this state 550, client requests for content segments after the current ad break are denied by the ABR Packager 470. In another embodiment, the ABR Packager 470 may instead reply with the next un-retrieved ad segment, thereby forcing the client device to download, decode, and play the ad. Once the timer expires, as indicated by arrow 535, the system reverts to the Normal Segment Delivery state 520 in which unfettered trick-play operation is supported”. Here, when the client attempts a non-permitted seek (tries to jump past a restricted secondary/program-event segment), the server continues to use its original program-event timeline and either denies the request or forces the client back onto the restricted content, and processes subsequent requests normally according to the timeline. This is effectively determining the next segment irrespective of the non-permitted seeking action, in that the packager continues to serve (or forcing secondary/program0event content) according to the server-based timeline of the media stream, rather than honoring the jump).
As to claim 12, see similar rejection to claim 5.
As to claim 18, see similar rejection to claim 5.
10. Claims 4, 11, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Tarbox in view of Nugent, as applied to claim 3 above, and further in view of Haritaoglu et al (US 10771824 hereafter Haritaoglu).
As to claim 4, Tarbox in view of Nugent discloses the method of claim 3, further comprising:
receiving, at the server, an indication of a permitted seeking action performed by the user of the client (Tarbox, Fig. 6A; and [0070], “In FIG. 6A, a client 630 requests a regular segment (segment 7) from ABR Packager 620. ABR Packager 620 retrieves segment 7 from recorded program 610 and provides it to client 630”);
receiving, at the server, a request for a second media segment of the media stream to be delivered to the client (Fig. 6B, requesting segment 8); and
determining, using the server-based timeline of the media stream, whether the requested second media segment is to include primary media content or secondary media content (see citation in rejection to claim 1), but does not expressly disclose updating the server-based timeline of the media stream based on the indication of the permitted seeking action performed by the user of the client and processing a request for a second media segment using updated timeline.
Haritaoglu discloses updating a server-based timeline of a media stream based on an indication of a permitted seeking action performed by a user of a client and processing a request for a second media segment using the updated timeline (col. 2, last paragraph to col. 3 , paragraph 1, “the second manifest file may include a session identifier for identifying a connection between the manifest server and the video player having the request. The method may include modifying the second manifest file to produce an updated second manifest file unique to the video player having the request, where the updated second manifest file contains information for allowing the video player to play the video stream according to the rule and a second request from the video player. The second request may be to seek forward or backward in the video stream, and the manifest server may compare the second request to a view history of the video player to produce the updated second manifest file”).
Before the effective filing date of the invention, it would have been obvious for an ordinary skilled in the art to combine Tarbox in view of Nugent with Haritaoglu. The suggestion/motivation would have been to allow the client to provide a video player-specific manifest file (Haritaoglu, col. 3, paragraph 1).
As to claim 11, see similar rejection to claim 4.
As to claim 17, see similar rejection to claim 4.
11. Claims 7, 14, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Tarbox, as applied to claim 1 above, and further in view of Mandyam et al (US 2018/0176278A1, hereafter Mandyam).
As to claim 7, Tarbox discloses the method of claim 1, wherein a previous media segment of the media stream is associated with a first format ([0033], “the client (e.g., a media player) may select from a number of different alternate streams containing the same material encoded at a variety of data rates, allowing the streaming session to adapt to the available data rate. At the start of the streaming session, the player receives a manifest containing the metadata for the various sub-streams which are available”; [0042], “In a next step 225, the ABR player 230 looks at the high-level manifest and either starts by requesting the lowest bandwidth manifest file or optionally may do some bandwidth availability estimation and select the corresponding bandwidth manifest file”; [0043], “In a next step 235, ABR player 230 requests a 2nd level manifest for the corresponding bandwidth. In a next step 245, ABR player 230 determines the media-segment file in the 2nd level manifest”; [0044], “In a next step 255, ABR player 230 requests media segment files in succession. In a next step 265, ABR player 230 continuously monitors the media buffer fullness to determine if it is necessary to request lower or higher bandwidth media-segment representations. For example, if the bandwidth conditions change, the player 230 may be configured to select the corresponding bandwidth manifest file and select media segments in succession”), but does not expressly disclose wherein the media segment of the secondary media content item is associated with a second format, wherein adding the media segment of the secondary media content item to the media stream further comprises prepending an initialization segment to the media segment of the secondary media content item, and wherein the initialization segment causes the client to reinitialize a decoder of the client to decode the second format.
Mandyam discloses
wherein a media segment of a secondary media content item is associated with a second format ([0063], “Media playback (particularly using a web browser) typically involves initializing the media rendering process with an IS. In HTML5 rendering engines, the IS would be passed to a <video> tag, that is, a tag having "video" between two angle brackets, '<' and '>'. During a live broadcast stream, an IS would rarely change. However, the initialization information in the IS can change, e.g., at an advertisement (ad) insertion point”; [0191], “the first initialization information generally includes information usable by DASH client 110, media application 112 or a CODEC such as audio decoder 46 or video decoder 48 'for accessing media data of subsequent segments”, wherein the changed initialization information and different coding characteristics indicates a second format),
wherein adding a media segment of a secondary media content item to a media stream further comprises prepending an initialization segment to a media segment of the secondary media content item (see citation above. Also see [0162], “the first data sent by the broadcast receiver over such a connection is an Initialization Segment. If a new Initialization Segment is received after establishment of the media WebSocket connection, then the broadcast receiver will send a text message over the same Web Socket connection (opcode Oxl, as defined in Section 5.2 ofIETF RFC 9455) with the payload "IS". Then the broadcast receiver will send the new Initialization Segment followed by ensuing media segments”; [0195], “OTA middleware unit 100 may then send media data following the second initialization segment to media application 112 (260)”), and
wherein the initialization segment causes the client to reinitialize a decoder of the client to decode the second format (abstract, “receive a second initialization segment of the broadcast stream of media data, and determine whether initialization information of the second initialization segment is different than initialization information of the first initialization segment. When the second initialization segment includes different initialization information, the middleware unit sends an indication to a media application that media playback is to be reinitialized using the initialization information of the second initialization segment”; [0182], “DASH client 208, which may take further actions, such as reinitializing media playback using new initialization information of the newly received IS”; [0125], “OTA middleware unit 100 may send data to media application 112 to cause media application 112 to reinitialize using the new initialization information of the subsequent initialization segment”).
Before the effective filing date of the invention, it would have been obvious for an ordinary skilled in the art to combine Tarbox with Mandyam. The suggestion/motivation would have been to enable handling different encoding characteristics (Mandyam, [0063]; [0071]; [0191]).
As to claim 14, see similar rejection to claim 7.
As to claim 20, see similar rejection to claim 7.
12. Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Tarbox, as applied to claim 1 above, and further in view of Ramos et al (“EpochSegmentSync: Inter-Encoder Synchronization for Adaptive Bit-Rate Streaming Head-ends”, hereafter Ramos).
As to claim 8, Tarbox discloses the claimed invention substantially as discussed in claim 1, but does not expressly disclose wherein the server-based timeline is synchronized to a plurality of timeline servers. Ramos discloses a server-based timeline being synchronized to a plurality of timeline servers (page 41, left col., “For packager synchronization, additional requirements are defined beyond the encoder synchronization requirements. These include generating consistent manifest without retro-active changes to the timeline (13) that can be played consistently and interchangeably… The packager synchronization should also work for different DRM systems and for the case when segments are missing and for the case when packagers can failover and join. Also, packager synchronization shall still work with incoming ad insertion signals, and other timed-metadata present in streams. While this paper proposes a contribution to address the requirements for encoder synchronization, we also show in the prototype that the approach can be extended to support packager synchronization”; page 41, right col., “3.1 Epoch Segment Synch Approach The schematic architecture for EpochSegmentSynch with redundant encoders is shown in Figure 2. Multiple distributed ABR encoders are transmitting their outputs to multiple distributed origin/packager servers. The ABR encoders are expected to use a common input signal or an input with common per frame timing information. If this is not the case, a synchronization timestamp (STS) may be configured that maps the input timestamps to output timestamps (sts is the difference between the epoch anchor relative timing and the timing in the source signal).”).
Before the effective filing date of the invention, it would have been obvious for an ordinary skilled in the art to combine Tarbox with Ramos. The suggestion/motivation would have been to support failover (Ramis, page 41, left col., “for the case when packagers can failover and join”).
Prior Art Cited but not Applied in the Rejection
13. Below is a list of prior art reference(s) cited but not applied in the rejection:
a) EI-Rahmann et al (US 2025/0142140), disclosing identifying in a manifest file at a server used to stream media content item at least one indication that at least one advertising content item is to be play back at a first layback location, determining a retrieval time to retrieve the at least one advertisement content item from an advertising source for an advertisement break, inserting, into the manifest file at the user a retrieval indication, retrieving the advertisement content item from the source for output .
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HUA FAN whose telephone number is (571)270-5311. The examiner can normally be reached on 9-6.
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 an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HUA FAN/Primary Examiner, Art Unit 2426
