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 Arguments
The double patenting rejections are withdrawn in view of the terminal disclaimer.
Regarding Kilar, Applicant first argues that Kilar fails to teach “associating the first manifest file with an identifier.” Examiner respectfully disagrees. The term associate is the broadest possible formulation of a relation between data elements in a computing system such as a server/client system as taught in Kilar. It merely requires some recognizable connection between elements. For example, if a first piece of data is transmitted in response to a second piece of data, to a destination specified by the second piece of data, they can be reasonably understood as associated.
In Kilar, a request is made to a server, the request including a user ID that identifies where the response (including a manifest) should be sent. The manifest sent in response to such a request is associated with the ID in the request because the ID controls where the response (manifest) is sent. One of ordinary skill would understand that there is a recognizable relationship (association) between the manifest/playlist and the client ID which requested it and to which the response is sent.
As examiner suggested in the interview of 2/9/2026, if the claim language required the user ID to be stored in a certain location (e.g. the server), that would be a narrower concept than mere “association.” As is, Examiner maintains that correspondence between the manifest and the client ID meets a reasonably broad construction of the recited association.
Second, Applicant asserts that Kilar does not teach “receiving, from the device, a second request for the first content item, wherein the second request comprises the identifier [and] causing, based on the identifier, a second manifest file for the first content item to be generated.”
However, Kilar does teach a second request. For example, para. 101 teaches a first request, while para. 106 teaches a different, later, and second request for media at a different bit rate. Para. 121 also discusses multiple requests for different bit rate content. These requests are sent in the same manner as the requests discussed above, but are separate and therefore meet “the second request” as recited.
For these reasons, the rejections are maintained.
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-24 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Kilar, US 2012/0072286.
Claims 1, 7, 13. Kilar teaches a method comprising:
a processor and memory [paras. 78-81];
receiving, from a device, a first request for a first content item [media player/user device 102 selects and requests appropriate bit rate, paras. 106, 111, 117, 120, 121, 125, 127, 137, 140-153; Figs. 3A, 3B];
causing, based on the first content item, a first manifest file for the first content item to be generated [playlist for each bit rate, segment playlists, paras. 111, 127 et seq., paras. 142-153, Figs. 3F, 3G, 3H];
associating the first manifest file with an identifier [manifest is sent based on request including identifier i.e. manifest is “associated” with the identifier, paras. 93, 98, 125, 127];
sending, to the device, the first manifest file [playlist is transmitted by server, paras. 111, 128, 130, 131, 147-153];
receiving, from the device, a second request for the first content item, wherein the second request comprises the identifier [user device determines and requests if a second (higher or lower) bit rate is necessary, paras. 106, 117, 120, 121; requests for content include user device identifier, paras. 93, 98, 127]; and
causing, based on the identifier, a second manifest file for the first content item to be generated [a second playlist is created for different bit rates; “versions" are related ads having different bit rate; paras. 106, 111, 117, 120, 121, 136, 137, 142-153 Figs. 1, 2, 3A-H].
2, 8, 14, 20. Kilar teaches the method of claim 1, further comprising sending, to the device, the second manifest file [second playlist provided, Fig. 3C, paras. 106, 111, 117, 120, 121, 136, 137, 142-153 Figs. 1, 2, 3A-H].
3, 9, 15, 21. Kilar teaches the method of claim 1, wherein the identifier comprises a device identifier for the device [device/computer identifier, paras. 93, 98, 125, 127].
4, 10, 16, 22. Kilar teaches the method of claim 1, wherein the first request is for the first content item at a first bitrate [media player/user device 102 selects and requests appropriate bit rate, paras. 106, 111, 117,120,121,125,127,137,140-153; Figs. 3A, 3B]; and the second request is for the first content item at a second bitrate different from the first bitrate [a second playlist is created for different bit rates; “versions" are related ads having different bit rate; paras. 106, 111, 117, 120, 121, 136, 137, 142-153 Figs. 1, 2, 3A-H].
5, 11, 17, 23. Kilar teaches the method of claim 1, wherein the second request is received based on a change in a network condition [e.g. requests based on bandwidth, buffer speed, etc., paras. 104, 111, 112, 117, 135, 197].
6, 12, 18, 24. Kilar teaches the method of claim 1, wherein the first manifest file comprises one or more segments of the first content item at a first bitrate and one or more segments of a second content item at the first bitrate [playlist for each bit rate, segment playlists, paras. 111, 127 et seq., paras. 142-153, Figs. 3F, 3G, 3H] and wherein the second manifest file comprises one or more segments of the first content item at a second bitrate and one or more segments of the second content item at the second bitrate [a second playlist is created for different bit rates; “versions" are related ads having different bit rate; paras. 106, 111, 117, 120, 121, 136, 137, 142-153 Figs. 1, 2, 3A-H].
19. Kilar teaches a system comprising: a computing device configured to:
receive, from a device, a first request for a first content item [media player/user device 102 selects and requests appropriate bit rate, paras. 106, 111, 117, 120, 121, 125, 127, 137, 140-153; Figs. 3A, 3B];
cause, based on the first content item, a first manifest file for the first content item to be generated [playlist for each bit rate, segment playlists, paras. 111, 127 et seq., paras. 142-153, Figs. 3F, 3G, 3H];
associate the first manifest file with an identifier [manifest is sent based on request including identifier i.e. manifest is “associated” with the identifier, paras. 93, 98, 125, 127];
send, to the device, the first manifest file [playlist is transmitted by server, paras. 111, 128, 130, 131, 147-153];
receive, from the device, a second request for the first content item, wherein the second request comprises the identifier [user device determines and requests if a second (higher or lower) bit rate is necessary, paras. 106, 117, 120, 121; requests for content include user device identifier, paras. 93, 98, 127]; and
cause, based on the identifier, a second manifest file for the first content item to be generated [a second playlist is created for different bit rates; “versions" are related ads having different bit rate; paras. 106, 111, 117, 120, 121, 136, 137, 142-153 Figs. 1, 2, 3A-H]; and
the device configured to:
send the first request for the first content item [paras. 106, 111, 117, 120, 121, 125, 127, 137, 140-153; Figs. 3A, 3B];
receive the first manifest file [playlist is received, paras. 111, 128, 130, 131, 147-153]; and
send the second request for the first content item [user device determines and requests if a second (higher or lower) bit rate is necessary, paras. 106, 117, 120, 121; requests for content include user device identifier, paras. 93, 98, 127].
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 Timothy R Newlin whose telephone number is (571)270-3015. The examiner can normally be reached M-F 8-5 Mountain Time.
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, Benjamin Bruckart can be reached at 571-272-3982. 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.
/TIMOTHY R NEWLIN/Examiner, Art Unit 2424
Prosecution Insights