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 .
Claim Rejections - 35 USC § 102
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 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.
Claims 1-9 and 11 rejected under 35 U.S.C. 102(a)(1) as being anticipated by US 20140281010 A1 to Panje et al. (hereinafter “Panje”).
Consider claim 1, Panje discloses a management method implemented by a management entity device (Par. [0019]: HTTP server) and comprising:
managing provision of manifests associated with chunks of chunked content, the manifests, referred to as first manifests, comprising addresses of chunks of the content and being successively transmitted one after the other with a view to being played back by a playback device (Par. [0081]: “FIG. 7 is a flowchart showing one example of a method for preparing media content to be streamed to a client … a top-level manifest file is generated. The top-level manifest includes a series of Universal Resource Indicators (URLs). The series of URLs indicate an ordering of the multiple media segments to recreate the stream of media content”), wherein the managing comprises;
during the transmission of the content in real time, receiving a command to perform a time jump in the content in order to play back the content from an earlier instant than the current playback instant (Par. [0006]: “trick-play modes operation (e.g., Pause, Fast Forward, Rewind) may be executed when the manifest file operates in rolling mode and the user attempts to access a portion of the program outside the current window”; Par. [0074]-[0075]: “For example, the REST protocol may be used as follows to acquire a manifest file that satisfies a client request to invoke a seek function to jump forwards or backwards in a program”); and
transmitting a second manifest comprising addresses of chunks to be played back at said earlier instant, which are supplemented by a portion of the addresses of chunks of the content already having been transmitted, the transmitting being triggered by the receiving (Par. [0065]-[0070] describes preparing a modified manifest file in response to a trick play request, e.g., fast forward or rewind; Par. [0066]: “The server 550 will modify the manifest file to include a window of URLs starting from the client device's current position in the program”; Par. [0066]: “when the client device 510 switches from normal play to fast-forward play, the server 510 knows what media segment was last read by the client device and can thus update the modified manifest file TV_FF.sub.--2.times._ClientID.m3u8 beginning with that media segment or the subsequent media segment”; Par. [0070]: “A similar approach can be used when a client device fast rewinds through a program”).
Consider claim 2, Panje discloses the management method as claimed in claim 1, wherein the portion of addresses includes addresses of chunks transmitted in a last manifest, referred to as the first manifest, in connection with the real-time playback (Par. [0065]-[0070] describes preparing a modified manifest file in response to a trick play request, e.g., fast forward or rewind; in the case of a rewind operation, the modified manifest provides some of the addresses of chunks transmitted in a last manifest, i.e., recently watched chunks while the modified manifest skips or excludes certain chunks from the manifest to simulate a fast rewind; Par. [0068]: “In the more general case, if the client device requests a trick play mode of operation that presents the media content at a rate N (N being an integer greater than one) times a normal presentation rate, every (N-1) out of N successive media segments will be excluded or otherwise skipped from the manifest file”).
Consider claim 3, Panje discloses the management method as claimed in claim 1 wherein the portion of addresses of chunks includes chunks chosen from among the first chunks of the content (Par. [0065]-[0070] describes preparing a modified manifest file in response to a trick play request, e.g., fast forward or rewind; in the case of a rewind operation, the modified manifest provides some of the addresses of chunks previously transmitted using a last manifest; Par. [0068]: “In the more general case, if the client device requests a trick play mode of operation that presents the media content at a rate N (N being an integer greater than one) times a normal presentation rate, every (N-1) out of N successive media segments will be excluded or otherwise skipped from the manifest file”. Note, if the current playback position is near the beginning of the content when the user requests a fast rewind then it is possible that the portion of addresses of chunks includes chunks chosen from among the first chunks of the content which meets the broadest reasonable interpretation of the claim. Alternately, Par. [0057]-[0059] describes providing a ‘start-over manifest’ for skipping to the beginning of a live stream).
Consider claim 4, Panje discloses the management method as claimed in claim 1 wherein the second manifest is updated over time, and wherein addresses of chunks associated with the stream transmitted in real time are updated (Par. [0053]: “the media player 430 periodically requests and receives updated manifest files in this manner as they are published by the server 450. The updated manifest files contain a sliding window of 10 one-second media segments”).
Consider claim 5, Panje discloses the management method as claimed in claim 2 comprising receiving a selection, from the second manifest, one of the last addresses of chunks and responsively transmitting the first manifest instead of the second manifest (Par. [0065]-[0070] describes preparing a modified manifest file in response to a trick play request, e.g., fast forward or rewind; Par. [0068]: “In the more general case, if the client device requests a trick play mode of operation that presents the media content at a rate N (N being an integer greater than one) times a normal presentation rate, every (N-1) out of N successive media segments will be excluded or otherwise skipped from the manifest file”. Note, in the example of fast rewind using the second manifest, when normal playback is resumed at the desired position, it is implicit that normal playback would not skip any chunks therefore requiring transitioning from the second manifest back to a first manifest.
Consider claim 6, Panje discloses the management method as claimed in claim 1, wherein the earlier instant is selected in a given time window, and wherein said portion of the other addresses of chunks of the content having been transmitted originates from this time window (Par. [0033]-[0034] and Fig. 2-4 describes a user interface for performing trick play to select an earlier instant in a given time window; Par. [0065]-[0070] describes preparing a modified manifest file in response to a trick play request, e.g., fast forward or rewind; in the case of a rewind operation, the modified manifest provides some of the addresses of chunks transmitted in a last manifest, i.e., recently watched chunks while the modified manifest skips or excludes certain chunks from the manifest to simulate a fast rewind; Par. [0068]: “In the more general case, if the client device requests a trick play mode of operation that presents the media content at a rate N (N being an integer greater than one) times a normal presentation rate, every (N-1) out of N successive media segments will be excluded or otherwise skipped from the manifest file”)
Consider claim 7, Panje discloses the management method as claimed in claim 1, wherein the time window has a fixed duration (Par. [0052]: “In step 445, media player 430 determines that the 2nd level manifest is operating in rolling mode and contains the first 10 second of the program in 10 one-second media segments”).
Consider claim 8, Panje discloses a management entity device for managing the provision of manifests based on the same rationale as the method of claim 1 and because Panje further discloses a device including a microprocessor (Par. [0088] and Fig. 8: “one or more processors 401 which may be microprocessors”) for performing the method.
Consider claim 9, Panje discloses a playback terminal comprising the management entity device as defined in claim 8 based on the same rationale as the device of claim 8 and because Panje further teaches a playback terminal comprising the management entity device (Par. [0023]: “Client devices 150 and 180 may receive the manifest files and media segments from server 120 over network 110. Client devices may be any type of electronic device that are capable of receiving data transmitted over a network and generate output utilizing the data received via the network, for example, wireless mobile devices, smartphones, PDAs, entertainment devices, consumer electronic devices, PCs, etc. The output may be any media type or combination of media types, including, for example, audio, video or any combination thereof.”; also Par. [0088] and Fig. 8: “microprocessor” and Par. [0088]: “FIG. 8 illustrates … embodiments of a server and/or a client”).
Consider claim 11, Panje discloses a non-transitory computer readable data medium on which at least one series of program code instructions for executing a method as claimed in claim 1 has been stored based on the same rationale as the method of claim 1 and because Panje further discloses a memory storing code for performing the method (Par. [0089] and Fig. 8: “computer executable instructions may be provided using any computer-readable media, such as memory 402”).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to STEPHEN R SMITH whose telephone number is (571)270-1318. The examiner can normally be reached M-F 9-5.
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, Thai Q Tran can be reached at (571) 272-7382. 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.
STEPHEN R. SMITH
Examiner
Art Unit 2484
/THAI Q TRAN/Supervisory Patent Examiner, Art Unit 2484
Prosecution Insights