DETAILED ACTION
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 .
This office Action is in response to Application 19002230 filed on 12/26/2024. Claims 1, 6, 10, 15, 19, 24, 28, and 33 are independent claims. Claims 1-36 have been examined and are pending in this application. This Office Action is made Non-Final.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on12/26/2024 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the claims at issue are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO internet Web site contains terminal disclaimer forms which may be used. Please visit http://www.uspto.gov/forms/. The filing date of the application will determine what form should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1-36 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-4, 6, 8, 11, 13-19, 21-24, 26, 28-33, 35-37, 40-42, 46-48, and 51 of U.S. Patent No. 12,225,009. Although the claims at issue are not identical, they are not patentably distinct from each other because:
The examiner notes that Claims 1-4, 6, 8, 11, 13-19, 21-24, 26, 28-33, 35-37, 40-42, 46-48, and 51 of U.S. patent No. 12,225,009 anticipates, more specifically:
Instant Application 19/002,230
US patent No. 12,225,009
Claim 1 (method) = claim 10 (device) = claim 19 (non-transitory computer readable media) = claim 28 (system).
Claim 1. A method comprising:
sending, by a user device to a computing device, a manifest file request comprising a uniform resource signing package as a query parameter to allow the uniform resource signing package to remain unaltered as the manifest file request is routed to the computing device,
wherein the uniform resource signing package comprises information indicating a requested content item;
receiving, by the user device, a response comprising a manifest file for the requested content item, wherein the manifest file comprises the uniform resource signing package and a listing of fragments of the requested content item; and
sending, by the user device, a plurality of fragment requests for the fragments of the requested content item, wherein each of the fragment requests comprises a copy of the uniform resource signing package as a query parameter.
Claim 1. A method comprising:
receiving, by a computing device and from a user device, a manifest file request comprising a uniform resource signing package as a query parameter to allow it to remain unaltered as the manifest file request is routed to the computing device,
wherein the uniform resource signing package comprises information indicating a requested content item;
verifying, based on the uniform resource signing package
and the manifest file request, that the user device is to be permitted access to the requested content item;
sending, by the computing device, based on the verifying, and to the user device, a response comprising a manifest file for the requested content item, wherein the manifest file comprises the uniform resource signing package and a listing of fragments of the requested content item; and
receiving, from the user device, a plurality of fragment requests for the fragments of the requested content
item, wherein each of the fragment requests comprises a copy of the uniform resource signing package as a query parameter.
Claim 6 (method) = claim 15 (device) = claim 24 (non-transitory computer-readable media) = claim 33 (system)
Claim 6. A method comprising:
sending, by a user device, a request for a manifest file for a requested content item,
wherein the request comprises path information for the requested content item, and
wherein, appended to the path information, is a query string comprising signed information indicating access parameters for the user device and the requested content item;
receiving, by the user device, the manifest file, wherein the manifest file comprises a copy of the signed information indicating the access parameters for the user device and the requested content item; and
sending a plurality of fragment requests for fragments of the requested content item, wherein each of the fragment requests comprises a copy of the signed information.
Claim 8. A method comprising:
receiving, by a computing device and from a user device, a request for a manifest file for a requested content item,
wherein the request comprises path information for the requested content item, and
wherein, appended to the path information, is a query string comprising:
signed information indicating access parameters for the user device and the requested content item;
verifying, based on the request, that the user device has access to the requested content item;
sending, by the computing device and to the user device, the manifest file, wherein the manifest file comprises a copy of the signed information indicating the access parameters for the user device and the requested content item; and
receiving a plurality of fragment requests for fragments of the requested content item, wherein each of the fragment requests comprises a copy of the signed information
Claim 28. A system comprising:
a user device and a computing device, wherein the user device is configured to:
send, to the computing device, a manifest file request comprising a uniform resource signing package as a query parameter to allow the uniform resource signing package to remain unaltered as the manifest file request is routed to the computing device,
wherein the uniform resource signing package comprises information indicating a requested content item;
receive a response comprising a manifest file for the requested content item, wherein the manifest file comprises the uniform resource signing package and a listing of fragments of the requested content item; and
send a plurality of fragment requests for the fragments of the requested content item, wherein each of the fragment requests comprises a copy of the uniform resource signing package as a query parameter, and
wherein the computing device is configured to receive the manifest file request.
Claim 1. A method comprising:
receiving, by a computing device and from a user device, a manifest file request comprising a uniform resource signing package as a query parameter to allow it to remain unaltered as the manifest file request is routed to the computing device,
wherein the uniform resource signing package comprises information indicating a requested content item;
verifying, based on the uniform resource signing package
and the manifest file request, that the user device is to be permitted access to the requested content item;
sending, by the computing device, based on the verifying, and to the user device, a response comprising a manifest file for the requested content item, wherein the manifest file comprises the uniform resource signing package and a listing of fragments of the requested content item; and
receiving, from the user device, a plurality of fragment requests for the fragments of the requested content
item, wherein each of the fragment requests comprises a copy of the uniform resource signing package as a query parameter.
Claim 33. A system comprising:
a user device and a computing device, wherein the user device is configured to:
send a request for a manifest file for a requested content item,
wherein the request comprises path information for the requested content item, and
wherein, appended to the path information, is a query string comprising signed information indicating access parameters for the user device and the requested content item;
receive the manifest file, wherein the manifest file comprises a copy of the signed information indicating the access parameters for the user device and the requested content item; and
send a plurality of fragment requests for fragments of the requested content item, wherein each of the fragment requests comprises a copy of the signed information, and
wherein the computing device is configured to receive the request for the manifest file.
Claim 8. A method comprising:
receiving, by a computing device and from a user device, a request for a manifest file for a requested content item,
wherein the request comprises path information for the requested content item, and
wherein, appended to the path information, is a query string comprising:
signed information indicating access parameters for the user device and the requested content item;
verifying, based on the request, that the user device has access to the requested content item;
sending, by the computing device and to the user device, the manifest file, wherein the manifest file comprises a copy of the signed information indicating the access parameters for the user device and the requested content item; and
receiving a plurality of fragment requests for fragments of the requested content item, wherein each of the fragment requests comprises a copy of the signed information
The examiner notes that the features emphasized above anticipate what is claimed in the limitations of Claims 1-36 of the Instant Application.
Therefore, the claims are rejected under nonstatutory double patenting.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitations are: “the user device is configured [] send/receive/denial/redirects …” recited in claims 18-30 and 33-36.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 103
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
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-2, 4-8, 10-11, 13-17, 19-20, 22-26, 28-29, and 31-35 are rejected under 35 U.S.C. 103 as being unpatentable over Siddiqi et al. (“Siddiqi,” US 10,182,096, filed on 03/28/2014) in view of Gordon et al. (“Gordon,” US 20170353516, published on 12/07/2017).
Regarding Claim 1;
Siddiqi discloses a method comprising:
sending, by a user device to a computing device, a manifest file request comprising a uniform resource signing package as a query parameter to allow the uniform resource signing package to remain unaltered as the manifest file request is routed to the computing device, wherein the uniform resource signing package comprises information indicating a requested content item (Col 7, lines 4-7; fig. 8; when a viewer clicks "Play" for a video, the video player makes an HTTP request to a headend for the video. The headend/CMS responds with a video URL on a CDN; Col 7, lines 54-52; CMS provides metadata associated with a video stream, including the information required to deliver the content, e.g., the URL of a manifest file. In particular, the manifest file contains the URL names of the chunks encoding the content, and can also include the URL/names of other manifest files. Each chunk is encoded at a particular bitrate, and it is stored on a particular CDN or server; Col 34, line 62 – Col 35, line 2; the values of the query parameters should be URL Safe or properly URL encoded. A list of example query parameters/keys for Full VRLs is described below, including both optional and required parameters. In some embodiments, required parameters that will be described below such as original primary CDN URL, original secondary CDN URL, etc. are required ( e.g., by a CDC) to be passed for successful service delivery);
receiving, by the user device, a response comprising a manifest file for the requested content item, wherein the manifest file comprises the uniform resource signing package and a listing of fragments of the requested content item (Col 7, lines 54-52;fig. 8; CMS provides metadata associated with a video stream, including the information required to deliver the content, e.g., the URL of a manifest file. In particular, the manifest file contains the URL names of the chunks encoding the content, and can also include the URL/names of other manifest files. Each chunk is encoded at a particular bitrate, and it is stored on a particular CDN or server. Manifest files can be themselves distributed through CDNs; Col 9, lines 18-26; once the client receives the manifest file, the client uses the information in this file to download and start playing the video chunks); and
sending, by the user device, a plurality of fragment requests for the fragments of the requested content item, wherein each of the fragment requests comprises a uniform resource signing package as a query parameter (Col 7, lines 4-7; when a viewer clicks "Play" for a video, the video player makes an HTTP request to a headend for the video. The headend/CMS responds with a video URL on a CDN; Col 7, lines 54-52; CMS provides metadata associated with a video stream, including the information required to deliver the content, e.g., the URL of a manifest file. In particular, the manifest file contains the URL names of the chunks encoding the content, and can also include the URL/names of other manifest files. Each chunk is encoded at a particular bitrate, and it is stored on a particular CDN or server; Col 34, line 62 – Col 35, line 2; the values of the query parameters should be URL Safe or properly URL encoded. A list of example query parameters/keys for Full VRLs is described below, including both optional and required parameters. In some embodiments, required parameters that will be described below such as original primary CDN URL, original secondary CDN URL, etc. are required to be passed for successful service delivery).
Siddiqi discloses wherein each of the fragment requests comprises a copy of the uniform resource signing package as a query parameter as recited above, but do not explicitly disclose a copy of the uniform resource signing package.
However, in an analogous art, Gordon discloses video delivery system/method that includes:
a copy of the uniform resource signing package (Gordon: par 0542; when the segment file server responds to the video segment file URL request by serving the video segment file, it determines whether it has in storage an unexpired copy of the source video segment file corresponding to the video segment delivery URL. If it has an unexpired copy of the source video segment file in storage, it serves it to the requesting device).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Gordon with the method/system of Siddiqi to include a copy of the uniform resource signing package. One would have been motivated to receive a request for the manifest file from a user device. The video is encoded at different reference bitrates and each encoded reference bitrate is divided into segments to generate video segment files. The manifest file includes an ordered list of universal resource locators (URLs) that reference a set of video segment files encoded at a particular reference bitrate (Gordon: abstract).
Regarding Claim 2;
The combination of Siddiqi and Gordon disclose the method of claim 1,
Gordon discloses receiving a plurality of responses, wherein each of the plurality of responses comprises an instruction to store a same copy of the uniform resource signing package as a cookie (Gordon: par 0263; when the manifest file handler receives a subsequent request for any Variant HLS manifest file (e.g., when a Variant HLS manifest file URL is subsequently requested by a requesting device after it receives an issued Master HLS manifest file), the manifest file handler may determine the source Variant HLS manifest file corresponding to the requested URL and, based on the source Variant HLS manifest file; par 0542; when the segment file server responds to the video segment file URL request by serving the video segment file, it determines whether it has in storage an unexpired copy of the source video segment file corresponding to the video segment delivery URL. If it has an unexpired copy of the source video segment file in storage, it serves it to the requesting device).
The motivation is the same that of claim 1 above.
Regarding Claim 4;
The combination of Siddiqi and Gordon disclose the method of claim 1,
Gordon discloses wherein the query parameter is a uniform resource locator (URL) query string (Gordon par 0298-0311; the manifest file handler has a number of options in configuring the URLs in the issued Variant HLS manifest file; http: [] seg,emt-2.ts .. ; par 0840; inferences on the URL text string may be made in some cases to determine the video segment sequences (e.g., based on file numbering) or other data properties. Also, although the data in this example is parsed from the URL text string, any query parameters that be attached to the URL also may be analyzed to detect a parameter/attribute name or other pattern that may allow the CDN to determine certain manifest file data).
The motivation is the same that of claim 1 above.
Regarding Claim 5;
The combination of Siddiqi and Gordon disclose the method of claim 1,
Siddiqi discloses wherein the manifest file comprises a uniform resource locator (URL) for the requested content item, and the uniform resource signing package is included in the URL as a query parameter (Siddiqi: Col 7, lines 4-7; fig. 8; when a viewer clicks "Play" for a video, the video player makes an HTTP request to a headend for the video. The headend/CMS responds with a video URL on a CDN; Col 7, lines 54-52; CMS provides metadata associated with a video stream, including the information required to deliver the content, e.g., the URL of a manifest file. In particular, the manifest file contains the URL names of the chunks encoding the content, and can also include the URL/names of other manifest files. Each chunk is encoded at a particular bitrate, and it is stored on a particular CDN or server; Col 34, line 62 – Col 35, line 2; the values of the query parameters should be URL Safe or properly URL encoded. A list of example query parameters/keys for Full VRLs is described below, including both optional and required parameters. In some embodiments, required parameters that will be described below such as original primary CDN URL, original secondary CDN URL, etc. are required ( e.g., by a CDC) to be passed for successful service delivery);
Regarding Claim 6;
Siddiqi discloses a method comprising:
sending, by a user device, a request for a manifest file for a requested content item, wherein the request comprises path information for the requested content item (Col 7, lines 4-7; fig. 8; when a viewer clicks "Play" for a video, the video player makes an HTTP request to a headend for the video. The headend/CMS responds with a video URL on a CDN; Col 7, lines 54-52; CMS provides metadata associated with a video stream, including the information required to deliver the content, e.g., the URL of a manifest file. In particular, the manifest file contains the URL names of the chunks encoding the content, and can also include the URL/names of other manifest files. Each chunk is encoded at a particular bitrate, and it is stored on a particular CDN or server; Col 34, line 62 – Col 35, line 2; the values of the query parameters should be URL Safe or properly URL encoded. A list of example query parameters/keys for Full VRLs is described below, including both optional and required parameters. In some embodiments, required parameters that will be described below such as original primary CDN URL, original secondary CDN URL, etc. are required ( e.g., by a CDC) to be passed for successful service delivery), and
wherein, appended to the path information, is a query string comprising signed information indicating access parameters for the user device and the requested content item (Col 7, lines 4-24; fig. 14; when a viewer clicks "Play" for a video, the video player makes an HTTP request to a headend for the video. The headend/CMS responds with a video URL on a CDN [] the VRL includes the URLs of CDNs (or paths to assets, which may be identical or different for the various CDNs on which an asset may be replicated) on which a requested asset is stored (knowledge of which is maintained by the CMS and included in the VRL by the CMS), and the CDC can evaluate the provided set of resources to determine an optimal CDN (or a ranked list of CDN s) for the requesting client; Col 7, lines 54-52; CMS provides metadata associated with a video stream, including the information required to deliver the content, e.g., the URL of a manifest file. In particular, the manifest file contains the URL names of the chunks encoding the content, and can also include the URL/names of other manifest files. Each chunk is encoded at a particular bitrate, and it is stored on a particular CDN or server);
receiving, by the user device, the manifest file, wherein the manifest file comprises the signed information indicating the access parameters for the user device and the requested content item (Col 7, lines 54-52;fig. 8; CMS provides metadata associated with a video stream, including the information required to deliver the content, e.g., the URL of a manifest file. In particular, the manifest file contains the URL names of the chunks encoding the content, and can also include the URL/names of other manifest files. Each chunk is encoded at a particular bitrate, and it is stored on a particular CDN or server. Manifest files can be themselves distributed through CDNs; Col 9, lines 18-26; once the client receives the manifest file, the client uses the information in this file to download and start playing the video chunks).
Siddiqi discloses receiving, by the user device, the manifest file, wherein the manifest file comprises the signed information indicating the access parameters for the user device and the requested content item as recited above, but do not explicitly disclose a copy of the signed information; sending a plurality of fragment requests for fragments of the requested content item, wherein each of the fragment requests comprises a copy of the signed information.
However, in an analogous art, Gordon discloses video delivery system/method that includes:
a copy of the signed information (Gordon: par 0542; when the segment file server responds to the video segment file URL request by serving the video segment file, it determines whether it has in storage an unexpired copy of the source video segment file corresponding to the video segment delivery URL. If it has an unexpired copy of the source video segment file in storage, it serves it to the requesting device);
sending a plurality of fragment requests for fragments of the requested content item, wherein each of the fragment requests comprises a copy of the signed information (par 0263; when the manifest file handler receives a subsequent request for any Variant HLS manifest file (e.g., when a Variant HLS manifest file URL is subsequently requested by a requesting device after it receives an issued Master HLS manifest file), the manifest file handler may determine the source Variant HLS manifest file corresponding to the requested URL and, based on the source Variant HLS manifest file; par 0542; when the segment file server responds to the video segment file URL request by serving the video segment file, it determines whether it has in storage an unexpired copy of the source video segment file corresponding to the video segment delivery URL. If it has an unexpired copy of the source video segment file in storage, it serves it to the requesting device).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Gordon with the method/system of Siddiqi to include a copy of the signed information; sending a plurality of fragment requests for fragments of the requested content item, wherein each of the fragment requests comprises a copy of the signed information. One would have been motivated to receive a request for the manifest file from a user device. The video is encoded at different reference bitrates and each encoded reference bitrate is divided into segments to generate video segment files. The manifest file includes an ordered list of universal resource locators (URLs) that reference a set of video segment files encoded at a particular reference bitrate (Gordon: abstract).
Regarding Claim 7;
The combination of Siddiqi and Gordon disclose the method of claim 6, further comprising:
Siddiqi discloses receiving a message indicating that a change to the access parameters is needed (Siddiqi: Col 12, lines 44-53; the instructions are included in a message that will result in the client sending a second manifest request to the CDN selected by the CDC. For example, the CDC provides a URL to the client for the selected CDN, which redirects the client to request a manifest file from the selected CDN. In other embodiments, the CDC, based upon the determination made, retrieves a manifest file from a CDN and rewrites the retrieved manifest file (e.g., rewrites bitrate field), an sends the updated file to the client).
Regarding Claim 8;
The combination of Siddiqi and Gordon disclose the method of claim 6, further comprising:
Gordon discloses receiving a message indicating a change to a validity period that is indicated in the query string (Gordon” par 0225; a decision is made based on whether the URL received with the request includes a session identifier (ID). If this is an initial request for the master manifest file of the video content that is made using a URL published on a content provider website, then the URL does not include a session ID. In this case, wherein a globally unique identifier (GUID) is generated and assigned as the session ID for the current video streaming session. If it is not an initial request for the video content (i.e., if the request is for a variant manifest file), the URL includes a session ID because, in this embodiment, the session ID is inserted into variant manifest URLs contained within issued master manifest files. For example, the session ID can be included in the host field of the URL, in the path portion of the URL, or appended at the end of the URL as a query string. If the URL includes the session ID, the session ID is parsed from the UR).
The motivation is the same that of claim 6 above.
Regarding Claim 10;
This claim recites a device that perform the same steps as method of claim 1, and has limitations that are similar to claim 1, thus are rejected with the same rationale applied against claim 1.
Regarding Claim 11;
This claim recites a device that perform the same steps as method of claim 2, and has limitations that are similar to claim 2, thus are rejected with the same rationale applied against claim 2.
Regarding Claim 13;
This claim recites a device that perform the same steps as method of claim 4, and has limitations that are similar to claim 4, thus are rejected with the same rationale applied against claim 4.
Regarding Claim 14;
This claim recites a device that perform the same steps as method of claim 5, and has limitations that are similar to claim 5, thus are rejected with the same rationale applied against claim 5.
Regarding Claim 15;
This claim recites a device that perform the same steps as method of claim 6, and has limitations that are similar to claim 6, thus are rejected with the same rationale applied against claim 6.
Regarding Claim 16;
This claim recites a device that perform the same steps as method of claim 7, and has limitations that are similar to claim 7, thus are rejected with the same rationale applied against claim 7.
Regarding Claim 17;
This claim recites a device that perform the same steps as method of claim 8, and has limitations that are similar to claim 8, thus are rejected with the same rationale applied against claim 8.
Regarding Claim 19;
This claim recites a non-transitory computer-readable media that perform the same steps as method of claim 1, and has limitations that are similar to claim 1, thus are rejected with the same rationale applied against claim 1.
Regarding Claim 20;
This claim recites a non-transitory computer-readable media that perform the same steps as method of claim 2, and has limitations that are similar to claim 2, thus are rejected with the same rationale applied against claim 2.
Regarding Claim 22;
This claim recites a non-transitory computer-readable media that perform the same steps as method of claim 4, and has limitations that are similar to claim 4, thus are rejected with the same rationale applied against claim 4.
Regarding Claim 23;
This claim recites a non-transitory computer-readable media that perform the same steps as method of claim 5, and has limitations that are similar to claim 5, thus are rejected with the same rationale applied against claim 5.
Regarding Claim 24;
This claim recites a non-transitory computer-readable media that perform the same steps as method of claim 6, and has limitations that are similar to claim 6, thus are rejected with the same rationale applied against claim 6.
Regarding Claim 25;
This claim recites a non-transitory computer-readable media that perform the same steps as method of claim 7, and has limitations that are similar to claim 7, thus are rejected with the same rationale applied against claim 7.
Regarding Claim 26;
This claim recites a non-transitory computer-readable media that perform the same steps as method of claim 8, and has limitations that are similar to claim 8, thus are rejected with the same rationale applied against claim 8.
Regarding claim 28;
Siddiqi discloses a system comprising: a user device and a computing device, wherein the user device is configured to (Col 2, lines 19-21; a processor configured to execute instructions stored on and/or provided by a memory coupled to the processor):
send, to the computing device, a manifest file request comprising a uniform resource signing package as a query parameter to allow the uniform resource signing package to remain unaltered as the manifest file request is routed to the computing device, wherein the uniform resource signing package comprises information indicating a requested content item (Col 7, lines 4-7; fig. 8; when a viewer clicks "Play" for a video, the video player makes an HTTP request to a headend for the video. The headend/CMS responds with a video URL on a CDN; Col 7, lines 54-52; CMS provides metadata associated with a video stream, including the information required to deliver the content, e.g., the URL of a manifest file. In particular, the manifest file contains the URL names of the chunks encoding the content, and can also include the URL/names of other manifest files. Each chunk is encoded at a particular bitrate, and it is stored on a particular CDN or server; Col 34, line 62 – Col 35, line 2; the values of the query parameters should be URL Safe or properly URL encoded. A list of example query parameters/keys for Full VRLs is described below, including both optional and required parameters. In some embodiments, required parameters that will be described below such as original primary CDN URL, original secondary CDN URL, etc. are required ( e.g., by a CDC) to be passed for successful service delivery);
receive a response comprising a manifest file for the requested content item, wherein the manifest file comprises the uniform resource signing package and a listing of fragments of the requested content item (Col 7, lines 54-52;fig. 8; CMS provides metadata associated with a video stream, including the information required to deliver the content, e.g., the URL of a manifest file. In particular, the manifest file contains the URL names of the chunks encoding the content, and can also include the URL/names of other manifest files. Each chunk is encoded at a particular bitrate, and it is stored on a particular CDN or server. Manifest files can be themselves distributed through CDNs; Col 9, lines 18-26; once the client receives the manifest file, the client uses the information in this file to download and start playing the video chunks); and
send a plurality of fragment requests for the fragments of the requested content item, wherein each of the fragment requests comprises the uniform resource signing package as a query parameter (Col 7, lines 4-7; when a viewer clicks "Play" for a video, the video player makes an HTTP request to a headend for the video. The headend/CMS responds with a video URL on a CDN; Col 7, lines 54-52; CMS provides metadata associated with a video stream, including the information required to deliver the content, e.g., the URL of a manifest file. In particular, the manifest file contains the URL names of the chunks encoding the content, and can also include the URL/names of other manifest files. Each chunk is encoded at a particular bitrate, and it is stored on a particular CDN or server; Col 34, line 62 – Col 35, line 2; the values of the query parameters should be URL Safe or properly URL encoded. A list of example query parameters/keys for Full VRLs is described below, including both optional and required parameters. In some embodiments, required parameters that will be described below such as original primary CDN URL, original secondary CDN URL, etc. are required to be passed for successful service delivery), and wherein the computing device is configured to receive the manifest file request (Col 7, lines 4-7; fig. 8; when a viewer clicks "Play" for a video, the video player makes an HTTP request to a headend for the video. The headend/CMS responds with a video URL on a CDN; Col 7, lines 54-52; CMS provides metadata associated with a video stream, including the information required to deliver the content, e.g., the URL of a manifest file. In particular, the manifest file contains the URL names of the chunks encoding the content, and can also include the URL/names of other manifest files. Each chunk is encoded at a particular bitrate, and it is stored on a particular CDN or server; Col 34, line 62 – Col 35, line 2; the values of the query parameters should be URL Safe or properly URL encoded. A list of example query parameters/keys for Full VRLs is described below, including both optional and required parameters. In some embodiments, required parameters that will be described below such as original primary CDN URL, original secondary CDN URL, etc. are required ( e.g., by a CDC) to be passed for successful service delivery).
Siddiqi discloses wherein each of the fragment requests comprises a copy of the uniform resource signing package as a query parameter as recited above, but do not explicitly disclose a copy of the uniform resource signing package.
However, in an analogous art, Gordon discloses video delivery system/method that includes:
a copy of the uniform resource signing package (Gordon: par 0542; when the segment file server responds to the video segment file URL request by serving the video segment file, it determines whether it has in storage an unexpired copy of the source video segment file corresponding to the video segment delivery URL. If it has an unexpired copy of the source video segment file in storage, it serves it to the requesting device).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Gordon with the method/system of Siddiqi to include a copy of the uniform resource signing package. One would have been motivated to receive a request for the manifest file from a user device. The video is encoded at different reference bitrates and each encoded reference bitrate is divided into segments to generate video segment files. The manifest file includes an ordered list of universal resource locators (URLs) that reference a set of video segment files encoded at a particular reference bitrate (Gordon: abstract).
Regarding Claim 29;
This claim recites a system that perform the same steps as method of claim 2, and has limitations that are similar to claim 2, thus are rejected with the same rationale applied against claim 2.
Regarding Claim 31;
This claim recites a system that perform the same steps as method of claim 4, and has limitations that are similar to claim 4, thus are rejected with the same rationale applied against claim 4.
Regarding Claim 32;
This claim recites a system that perform the same steps as method of claim 5, and has limitations that are similar to claim 5, thus are rejected with the same rationale applied against claim 5.
Regarding Claim 33;
Siddiqi discloses a system comprising: a user device and a computing device, wherein the user device is configured to (Col 2, lines 19-21; a processor configured to execute instructions stored on and/or provided by a memory coupled to the processor):
send a request for a manifest file for a requested content item, wherein the request comprises path information for the requested content item (Col 7, lines 4-7; fig. 8; when a viewer clicks "Play" for a video, the video player makes an HTTP request to a headend for the video. The headend/CMS responds with a video URL on a CDN; Col 7, lines 54-52; CMS provides metadata associated with a video stream, including the information required to deliver the content, e.g., the URL of a manifest file. In particular, the manifest file contains the URL names of the chunks encoding the content, and can also include the URL/names of other manifest files. Each chunk is encoded at a particular bitrate, and it is stored on a particular CDN or server; Col 34, line 62 – Col 35, line 2; the values of the query parameters should be URL Safe or properly URL encoded. A list of example query parameters/keys for Full VRLs is described below, including both optional and required parameters. In some embodiments, required parameters that will be described below such as original primary CDN URL, original secondary CDN URL, etc. are required ( e.g., by a CDC) to be passed for successful service delivery), and
wherein, appended to the path information, is a query string comprising signed information indicating access parameters for the user device and the requested content item (Col 7, lines 4-24; fig. 14; when a viewer clicks "Play" for a video, the video player makes an HTTP request to a headend for the video. The headend/CMS responds with a video URL on a CDN [] the VRL includes the URLs of CDNs (or paths to assets, which may be identical or different for the various CDNs on which an asset may be replicated) on which a requested asset is stored (knowledge of which is maintained by the CMS and included in the VRL by the CMS), and the CDC can evaluate the provided set of resources to determine an optimal CDN (or a ranked list of CDN s) for the requesting client; Col 7, lines 54-52; CMS provides metadata associated with a video stream, including the information required to deliver the content, e.g., the URL of a manifest file. In particular, the manifest file contains the URL names of the chunks encoding the content, and can also include the URL/names of other manifest files. Each chunk is encoded at a particular bitrate, and it is stored on a particular CDN or server);
receive the manifest file, wherein the manifest file comprises a copy of the signed information indicating the access parameters for the user device and the requested content item (Col 7, lines 54-52;fig. 8; CMS provides metadata associated with a video stream, including the information required to deliver the content, e.g., the URL of a manifest file. In particular, the manifest file contains the URL names of the chunks encoding the content, and can also include the URL/names of other manifest files. Each chunk is encoded at a particular bitrate, and it is stored on a particular CDN or server. Manifest files can be themselves distributed through CDNs; Col 9, lines 18-26; once the client receives the manifest file, the client uses the information in this file to download and start playing the video chunks).
wherein the computing device is configured to receive the request for the manifest file (Col 7, lines 4-7; fig. 8; when a viewer clicks "Play" for a video, the video player makes an HTTP request to a headend for the video. The headend/CMS responds with a video URL on a CDN; Col 7, lines 54-52; CMS provides metadata associated with a video stream, including the information required to deliver the content, e.g., the URL of a manifest file. In particular, the manifest file contains the URL names of the chunks encoding the content, and can also include the URL/names of other manifest files. Each chunk is encoded at a particular bitrate, and it is stored on a particular CDN or server; Col 34, line 62 – Col 35, line 2; the values of the query parameters should be URL Safe or properly URL encoded. A list of example query parameters/keys for Full VRLs is described below, including both optional and required parameters. In some embodiments, required parameters that will be described below such as original primary CDN URL, original secondary CDN URL, etc. are required ( e.g., by a CDC) to be passed for successful service delivery).
Siddiqi discloses receive the manifest file, wherein the manifest file comprises the signed information indicating the access parameters for the user device and the requested content item as recited above, but do not explicitly disclose a copy of the signed information; send a plurality of fragment requests for fragments of the requested content item, wherein each of the fragment requests comprises a copy of the signed information.
However, in an analogous art, Gordon discloses video delivery system/method that includes:
a copy of the signed information (Gordon: par 0542; when the segment file server responds to the video segment file URL request by serving the video segment file, it determines whether it has in storage an unexpired copy of the source video segment file corresponding to the video segment delivery URL. If it has an unexpired copy of the source video segment file in storage, it serves it to the requesting device);
send a plurality of fragment requests for fragments of the requested content item, wherein each of the fragment requests comprises a copy of the signed information (par 0263; when the manifest file handler receives a subsequent request for any Variant HLS manifest file (e.g., when a Variant HLS manifest file URL is subsequently requested by a requesting device after it receives an issued Master HLS manifest file), the manifest file handler may determine the source Variant HLS manifest file corresponding to the requested URL and, based on the source Variant HLS manifest file; par 0542; when the segment file server responds to the video segment file URL request by serving the video segment file, it determines whether it has in storage an unexpired copy of the source video segment file corresponding to the video segment delivery URL. If it has an unexpired copy of the source video segment file in storage, it serves it to the requesting device).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Gordon with the method/system of Siddiqi to include a copy of the signed information; send a plurality of fragment requests for fragments of the requested content item, wherein each of the fragment requests comprises a copy of the signed information. One would have been motivated to receive a request for the manifest file from a user device. The video is encoded at different reference bitrates and each encoded reference bitrate is divided into segments to generate video segment files. The manifest file includes an ordered list of universal resource locators (URLs) that reference a set of video segment files encoded at a particular reference bitrate (Gordon: abstract).
Regarding Claim 34;
This claim recites a system that perform the same steps as method of claim 7, and has limitations that are similar to claim 7, thus are rejected with the same rationale applied against claim 7.
Regarding Claim 35;
This claim recites a system that perform the same steps as method of claim 8, and has limitations that are similar to claim 8, thus are rejected with the same rationale applied against claim 8.
Claims 3, 9, 12, 18, 21, 27, 30, and 36 are rejected under 35 U.S.C. 103 as being unpatentable over Siddiqi et al. (US 10,182,096) in view of Gordon et al. (US 20170353516), and further in view of Moore et al. (“Moore,” US 20110126296, published on 05/26/2011).
Regarding Claim 3;
The combination of Siddiqi and Gordon disclose the method of claim 1,
Gordon discloses sending a subsequent request for the requested content item (Gordon: par 0263; when the manifest file handler receives a subsequent request for any Variant HLS manifest file (e.g., when a Variant HLS manifest file URL is subsequently requested by a requesting device after it receives an issued Master HLS manifest file)); and receiving a response, to the subsequent request, that: denies the subsequent request (Gordon: par 0263; when the manifest file handler receives a subsequent request for any Variant HLS manifest file (e.g., when a Variant HLS manifest file URL is subsequently requested by a requesting device after it receives an issued Master HLS manifest file), the manifest file handler may determine the source Variant HLS manifest file corresponding to the requested URL and, based on the source Variant HLS manifest file; par 0740; if the requested video segment file corresponds to one of the failover URLs, then the segment file servers determine that a server failure has occurred at some point during the process of the user device requesting/receiving video segment files for the adaptive streaming video. the system determine the cause of the server failure, and specifically may attribute the server failure either to one or more of the infrastructure service providers that are providing some of the video segment files to the user device, or to one or more of the segment file servers providing other video segment files to the user device); and redirects the user device to an access server that provided the user device with the uniform resource signing package (Gordon: par 0298; the manifest file handler has a number of options in configuring the URLs in the issued Variant HLS manifest file. Each URL can be configured as a URL identifying a video segment file for delivery by the network of segment file servers [] as a segment redirect URL; par 0362; these segment redirect URLs include the hostname redirect21.indexhandler.net, which identifies a segment redirect processor; include the Session ID XYZ789; include the path portion of the URL by which the given video segment file can be requested from the digital service; include the optional character string digserv designating the digital service associated with the requested video).
The motivation is the same that of claim 1 above.
The combination of Siddiqi and Gordon disclose receiving a response, to the subsequent request, that: determining the subsequent request as recited above, but do not explicitly disclose denies the subsequent request.
However, in an analogous art, Moore discloses access control system/method that includes:
denies the subsequent request (Moore: a determination may be made as to whether the client is entitled to view the content. For example, if provider parameter corresponds to "HBO," a client system determine whether the user has subscribed to HBO using the entitlement data. If not, the request for the HBO content denied or the content may not be offered to the client system).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Moore with the method/system of Siddiqi and Gordon to include denies the subsequent request. One would have been motivated to provide and process by assigning responsibility for obtaining entitlement data to the client's browser (Moore: abstract).
Regarding Claim 9;
The combination of Siddiqi and Gordon disclose the method of claim 6, further comprising receiving:
Gordon discloses a redirect to obtain a new signing package that is based on a changed access parameter (Gordon: par 0298; the manifest file handler has a number of options in configuring the URLs in the issued Variant HLS manifest file. Each URL can be configured as a URL identifying a video segment file for delivery by the network of segment file servers [] as a segment redirect URL; par 0362; these segment redirect URLs include the hostname redirect21.indexhandler.net, which identifies a segment redirect processor; include the Session ID XYZ789; include the path portion of the URL by which the given video segment file can be requested from the digital service; include the optional character string digserv designating the digital service associated with the requested video).
The motivation is the same that of claim 1 above.
The combination of Siddiqi and Gordon disclose all the limitations as recited above, but do not explicitly disclose a denial of a subsequent request from the user device
However, in an analogous art, Moore discloses access control system/method that includes:
a denial of a subsequent request from the user device (Moore: a determination may be made as to whether the client is entitled to view the content. For example, if provider parameter corresponds to "HBO," a client system determine whether the user has subscribed to HBO using the entitlement data. If not, the request for the HBO content denied or the content may not be offered to the client system).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Moore with the method/system of Siddiqi and Gordon to include a denial of a subsequent request from the user device. One would have been motivated to provide and process by assigning responsibility for obtaining entitlement data to the client's browser (Moore: abstract).
Regarding Claim 12;
This claim recites a device that perform the same steps as method of claim 3, and has limitations that are similar to claim 3, thus are rejected with the same rationale applied against claim 3.
Regarding Claim 18;
This claim recites a device that perform the same steps as method of claim 9, and has limitations that are similar to claim 9, thus are rejected with the same rationale applied against claim 9.
Regarding Claim 21;
This claim recites a non-transitory computer-readable media that perform the same steps as method of claim 3, and has limitations that are similar to claim 3, thus are rejected with the same rationale applied against claim 3.
Regarding Claim 27;
This claim recites a non-transitory computer-readable media that perform the same steps as method of claim 9, and has limitations that are similar to claim 9, thus are rejected with the same rationale applied against claim 9.
Regarding Claim 30;
This claim recites a system that perform the same steps as method of claim 3, and has limitations that are similar to claim 3, thus are rejected with the same rationale applied against claim 3.
Regarding Claim 36;
This claim recites a system that perform the same steps as method of claim 9, and has limitations that are similar to claim 9, thus are rejected with the same rationale applied against claim 9.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHAO WANG whose telephone number is (313)446-6644. The examiner can normally be reached on Monday-Friday 7:30-4:30PM EST.
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, Luu Pham can be reached on (571)270-5002. 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 https://ppair-my.uspto.gov/pair/PrivatePair. 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.
/C.W./Examiner, Art Unit 2439
/LUU T PHAM/Supervisory Patent Examiner, Art Unit 2439
Prosecution Insights