DETAILED ACTION
Examiner's Note: The Examiner has pointed out particular references contained in the prior art of record within the body of this action for the convenience of the Applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply. Applicant, in preparing the response, should consider fully the entire reference as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
Notice of Pre-AIA or AIA Status
The present application is being examined under the pre-AIA first to invent provisions.
Response to Arguments
Applicant’s remarks filed on 08/07/2026 have been fully considered.
Regarding claim[s] 1 – 20 under the various anticipatory and obviousness rejections, applicant’s remarks are not persuasive, and are addressed by the examiner in the office action below.
The office will respond to all other remarks that do not concern the prior art rejections, if any, in the office action below.
Applicant states on page[s] 1 of the remarks as filed: “
REJECTION OF THE CLAIMS UNDER 35 U.S.C. §102
Claims 1-14 and 16 are rejected as being anticipated by Lewis. Applicant respectfully traverses. Anticipation under 35 U.S.C. § 102 requires that a single prior art reference disclose each and every element of a claim, arranged as recited in the claim. As explained below, Lewis does not disclose at least the "maintaining" and "retrieving" limitations recited by claim 1, and therefore cannot anticipate claim 1.
Claim 1 recites, "maintaining, by the playback server system, a database containing the asset locations within the content delivery network of the plurality of assets associated with the piece of content." Claim 1 further recites, in response to receiving the play request, "retrieving, by the playback server system from the database, a set of asset locations within the content delivery network for assets from the plurality of assets associated with the piece of content that can be utilized by the playback device to play back the piece of content."”
In response the examiner isn’t persuaded, the examiner points out that applicant's arguments fail to comply with 37 CFR 1.111(b) because they amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references.
Applicant states on page[s] 2 of the remarks as filed: “For the "maintaining" limitation, the Office action asserts that this feature is taught by Lewis at paragraphs [0019] and [0032]. In particular, the Office action asserts that this feature is taught by Lewis paragraph [0019], which states "dynamic manifest file server 110 and rule resolution server 120 may be combined into a single server, multiple servers may be utilized for load balancing to multiple client devices, multiple content delivery networks may be utilized for higher quality of service, and several different video streams may be offered for streaming.", and by Lewis paragraph [0032], which states "one rule may rewrite the URLs within a manifest file to point to the content delivery network in closest proximity to the client device, providing improved network performance and responsiveness." For the "retrieving" limitation, the Office action asserts that this feature is taught by Lewis paragraph [0032].
The portions of Lewis cited by the Office action describes that "one rule may rewrite the URLs within a manifest file to point to the content delivery network in closest proximity to the client device." A rule that rewrites the URLs within a manifest file is not a "database containing the asset locations within the content delivery network of the plurality of assets," and the rewriting of such URLs is not "retrieving, by the playback server system from the database, a set of asset locations within the content delivery network," as recited by claim 1.
In response the examiner isn’t persuaded, the examiner points out that applicant’s recited “asset location,” is intentionally broad in scope. Such claim limitation to one of ordinary skilled in the art could be an “IP address,” “memory pointer” or “universal resource indicator/universal resource locator [i.e. domain name: www.weatherchannel.com].” Applicant’s alleged remarks that the prior art of Lewis does not teach the recited “asset location,” is argued in a specific manner, but is claiming in a broad manner that does have a one-to-one relationship.
What is further, the prior art of Lewis, disclosed the manifest file is created by a database that inputs all the URI’s or URL’s [i.e. applicant’s asset locations] from itself that keeps track of all the locations of content and where the content is stored…[emphasis added].
What is further of Lewis, if a URL or URI is re-written based on a rule, then the database or collection point that stores the URI’s and URL’s is also updated. Once the URI’s or URLs are re-written to the manifest filed.
**The examiner makes clear that a person of ordinary skilled in the art would know that the operation of Lewis, the inputting of URL’s and URI’s into a manifest file based on the geo location of the requesting client, must rely on a database or collection point that stores such URLs and URI’s and location of the content in a manner to effect such operation of assigning the closest URLs and URIs to better serve the requested content to the requesting client in an efficient data retrieval manner. This is an inherent feature of the prior art of Lewis, and a typical media content industry standard. Applicant will have to prove that this articulated operation of Lewis can occur in some other form that doesn’t meet the 35 USC 102 prior art doctrine “proof of burden.”
Applicant states on page[s] 2 of the remarks as filed: “Likewise, the disclosure of Lewis paragraph [0019] that servers "may be” combined into a single server," that "multiple servers may be utilized for load balancing," and that "multiple content delivery networks may be utilized for higher quality of service" does not disclose maintaining a database that contains the asset locations, or retrieving a set of asset locations from any such database. Applicant respectfully submits that a rule that may "rewrite the URLs within a manifest file" cannot disclose "maintaining, by the playback server system, a database containing the asset locations within the content delivery network," or "retrieving, by the playback server system from the database, a set of asset locations within the content delivery network," as recited by claim 1.”
In response the examiner isn’t persuaded, the examiner points out that applicant’s recited “asset location,” is intentionally broad in scope. Such claim limitation to one of ordinary skilled in the art could be an “IP address,” “memory pointer” or “universal resource indicator/universal resource locator [i.e. domain name: www.weatherchannel.com].” Applicant’s alleged remarks that the prior art of Lewis does not teach the recited “asset location,” is argued in a specific manner, but is claiming in a broad manner that does have a one-to-one relationship.
What is further, the prior art of Lewis, disclosed the manifest file is created by a database that inputs all the URI’s or URL’s [i.e. applicant’s asset locations] from itself that keeps track of all the locations of content and where the content is stored…[emphasis added].
What is further of Lewis, if a URL or URI is re-written based on a rule, then the database or collection point that stores the URI’s and URL’s is also updated. Once the URI’s or URLs are re-written to the manifest filed.
Applicant states on page[s] 3 of the remarks as filed: “Claim 1 further requires that it is "the playback server system" that performs both "maintaining, by the playback server system, a database containing the asset locations within the content delivery network" and "retrieving, by the playback server system from the database, a set of asset locations within the content delivery network." By contrast, the rule described in Lewis paragraph [0032] operates only to "rewrite the URLs within a manifest file to point to the content delivery network in closest proximity to the client device." Lewis thus describes a rule that points a playback device to "the content delivery network in closest proximity to the client device," and does not disclose "maintaining, by the playback server system, a database containing the asset locations within the content delivery network," or "retrieving, by the playback server system from the database, a set of asset locations within the content delivery network," as recited by claim 1.”
In response the examiner isn’t persuaded, the examiner points out that applicant’s recited “asset location,” is intentionally broad in scope. Such claim limitation to one of ordinary skilled in the art could be an “IP address,” “memory pointer” or “universal resource indicator/universal resource locator [i.e. domain name: www.weatherchannel.com].” Applicant’s alleged remarks that the prior art of Lewis does not teach the recited “asset location,” is argued in a specific manner, but is claiming in a broad manner that does have a one-to-one relationship.
What is further, the prior art of Lewis, disclosed the manifest file is created by a database that inputs all the URI’s or URL’s [i.e. applicant’s asset locations] from itself that keeps track of all the locations of content and where the content is stored…[emphasis added].
What is further of Lewis, if a URL or URI is re-written based on a rule, then the database or collection point that stores the URI’s and URL’s is also updated. Once the URI’s or URLs are re-written to the manifest filed.
Applicant states on page[s] 3 of the remarks as filed: “Applicant further submits that claim 1 recites asset locations "within the content delivery network." The portions cited in Lewis paragraph [0032], however, describes rewriting URLs "to point to the content delivery network in closest proximity to the client device." Directing a playback device to "the content delivery network in closest proximity" does not disclose "maintaining, by the playback server system, a database containing the asset locations within the content delivery network of the plurality of assets," nor "retrieving, by the playback server system from the database, a set of asset locations within the content delivery network," as recited by claim 1.
Because Lewis does not disclose each and every limitation of claim 1, Applicant respectfully submits that claim 1 is patentable over Lewis. Claims 2-14 and 16 depend from claim 1 and are patentable over Lewis at least by virtue of their dependency from claim 1, and for the additional features each recites. Applicant respectfully requests withdrawal of the rejection of claims 1-14 and 16.”
In response the examiner isn’t persuaded, the examiner points out that applicant’s recited “asset location,” is intentionally broad in scope. Such claim limitation to one of ordinary skilled in the art could be an “IP address,” “memory pointer” or “universal resource indicator/universal resource locator [i.e. domain name: www.weatherchannel.com].” Applicant’s alleged remarks that the prior art of Lewis does not teach the recited “asset location,” is argued in a specific manner, but is claiming in a broad manner that does have a one-to-one relationship.
What is further, the prior art of Lewis, disclosed the manifest file is created by a database that inputs all the URI’s or URL’s [i.e. applicant’s asset locations] from itself that keeps track of all the locations of content and where the content is stored…[emphasis added].
What is further of Lewis, if a URL or URI is re-written based on a rule, then the database or collection point that stores the URI’s and URL’s is also updated. Once the URI’s or URLs are re-written to the manifest filed.
Applicant states on page[s] 4 of the remarks as filed: “
REJECTION OF THE CLAIMS UNDER 35 U.S.C. 103
Claims 15 and 17-20 are rejected as being unpatentable over Lewis in view of
Thorwirth. Applicant respectfully traverses. An obviousness rejection under 35 U.S.C. §
103 requires that the cited combination of references teach or suggest each and every
limitation of the claim, and a limitation absent from both references cannot render the
claim obvious. Applicant respectfully submits that the combination of references do not
teach at least the "maintaining" and "querying" limitations recited by claims 17 and 19,
and thus does not render claims 17 and 19 obvious.”
In response the examiner isn’t persuaded, the examiner points out that applicant's arguments fail to comply with 37 CFR 1.111(b) because they amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references.
Applicant states on page[s] 4 of the remarks as filed: “Independent claim 17 recites, inter alia, "maintaining, by the playback server system, a database containing the asset locations within the content delivery network of the plurality of assets associated with the piece of content," and "querying, by the playback server, the database to retrieve a set of asset locations within the content delivery network based upon the filtered listing of the plurality of assets associated with the piece of content, wherein each asset location in the set of asset locations identifies a server within the content delivery network." Independent claim 19 recites corresponding "maintaining" and "querying" limitations.
As set forth above with respect to claim 1, a rule that operates to "rewrite the URLs within a manifest file to point to the content delivery network in closest proximity to the client device" is not a "database containing the asset locations within the content delivery network of the plurality of assets," and does not disclose "querying, by the playback server, the database to retrieve a set of asset locations within the content delivery network," as recited by claims 17 and 19. Thorwirth is cited by the Office action only for "the plurality of assets associated with the piece of content comprises at least a plurality of video streams, a plurality of audio streams, and a plurality of subtitle streams," and does not cure this deficiency of Lewis with respect to the "maintaining" and "querying" limitations of claims 17 and 19. Accordingly, the cited combination of Lewis and Thorwirth does not teach or suggest each and every limitation of claims 17 and 19.”
In response the examiner isn’t persuaded, the examiner points out that applicant’s recited “asset location,” is intentionally broad in scope. Such claim limitation to one of ordinary skilled in the art could be an “IP address,” “memory pointer” or “universal resource indicator/universal resource locator [i.e. domain name: www.weatherchannel.com].” Applicant’s alleged remarks that the prior art of Lewis does not teach the recited “asset location,” is argued in a specific manner, but is claiming in a broad manner that does have a one-to-one relationship.
What is further, the prior art of Lewis, disclosed the manifest file is created by a database that inputs all the URI’s or URL’s [i.e. applicant’s asset locations] from itself that keeps track of all the locations of content and where the content is stored…[emphasis added].
What is further of Lewis, if a URL or URI is re-written based on a rule, then the database or collection point that stores the URI’s and URL’s is also updated. Once the URI’s or URLs are re-written to the manifest filed.
Applicant states on page[s] 5 of the remarks as filed: “Claim 15 depends from claim 1 and is patentable over the cited combination at least for the reasons set forth above with respect to claim 1. Claim 18 depends from claim 17, and claim 20 depends from claim 19, and each is patentable over the cited combination at least by virtue of its dependency.
For at least these reasons, Applicant respectfully submits that claims 15 and 17- 20 are patentable over Lewis in view of Thorwirth, and respectfully requests withdrawal of the rejection of claims 15 and 17-20 under pre-AIA 35 U.S.C. § 103(a).”
In response the examiner isn’t persuaded, the examiner points out that applicant's arguments fail to comply with 37 CFR 1.111(b) because they amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references.
Applicant states on page[s] 5 of the remarks as filed: “
INFORMATION DISCLOSURE STATEMENT
Applicant notes that the present application is a continuation of U.S. Patent No. 11,716,371 and claims benefit of priority in a lineage of applications back to U.S. Patent No. 8,787,570 and U.S. Provisional App. No. 61/529,403. Applicant respectfully requests that the Examiner in the present application, in compliance with MPEP 609.02.II.A.2, acknowledge that information which has been considered by the Office in a parent application has been considered in this application.”
In response the examiner notes that the information disclosure statements filed in parent applications: 17/467,027; 13/341789, have been previously considered on their merits during prosecution of those respective filed patent application by the office.
Response to Amendment
Status of the instant application:
Claim[s] 1 – 20 are pending in the instant application.
Regarding claim[s] 1 – 20 under the various anticipatory and obviousness rejections, no claim amendments have been filed in response here to, thus the rejections are maintained at this time.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 05/05/2026, 08/07/2026, the submissions are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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 pre-AIA 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 –
(e) the invention was described in a patent granted on an application for patent by another filed in the United States before the invention thereof by the applicant for patent, or on an international application by another who has fulfilled the requirements of paragraphs (1), (2), and (4) of section 371(c) of this title before the invention thereof by the applicant for patent.
The changes made to 35 U.S.C. 102(e) by the American Inventors Protection Act of 1999 (AIPA) and the Intellectual Property and High Technology Technical Amendments Act of 2002 do not apply when the reference is a U.S. patent resulting directly or indirectly from an international application filed before November 29, 2000. Therefore, the prior art date of the reference is determined under 35 U.S.C. 102(e) prior to the amendment by the AIPA (pre-AIPA 35 U.S.C. 102(e)).
Claim(s) 1 – 14, 16 is/are rejected under pre-AIA 35 U.S.C. 102(e) as being taught by Lewis et al. [US PGPUB # 2012/0047542].
As per claim 1. Lewis does teach a method of automatically generating a top level index for a piece of content using a playback server system in response to receipt of a play request from a playback device [Lewis, paragraph: 0016, As shown in diagram 100 of FIG. 1, producer 180 may direct camera rig 185 to record live footage, such as a live event, to be streamed to users such as user 185……As new live footage is captured and approved, new video segments may be encoded and stored within live video segments 175, which may then be distributed over content delivery network 135. Content delivery network 135 may, for example, comprise a network of servers for storage and distribution of media content. Live video encoder 170 may also provide rule resolution server 120 with an updated list of references for accessing live video segments 175 through content delivery network 135, which may then be passed to dynamic manifest file server 110 for generating manifest file 157. Producer 180 may provide specific rules to rule resolution server 120 to customize the generation of manifest file 157, such a rule to insert advertising segments to overwrite a particular time block in the live stream.], the method comprising:
distributing, by a playback server system, a plurality of assets associated with a piece of content to a content delivery network, wherein each of the plurality of assets is stored in at least one asset location within the content delivery network [Lewis, paragraph: 0019, lines 20 – 22, For example, dynamic manifest file server 110 and rule resolution server 120 may be combined into a single server, multiple servers may be utilized for load balancing to multiple client devices, multiple content delivery networks may be utilized for higher quality of service, and several different video streams may be offered for streaming. Further of Lewis, at paragraph: 0032, lines 1 – 8, Besides advertisement insertion and user or client device targeting, rule resolution server 320 may also implement a wide variety of other rules to enhance, target, and customize the video streaming experience for the end user. For example, one rule may rewrite the URLs within a manifest file to point to the content delivery network in closest proximity to the client device, providing improved network performance and responsiveness];
maintaining, by the playback server system, a database containing the asset locations within the content delivery network of the plurality of assets associated with the piece of content [Lewis, paragraph: 0019, lines 20 – 22, For example, dynamic manifest file server 110 and rule resolution server 120 may be combined into a single server, multiple servers may be utilized for load balancing to multiple client devices, multiple content delivery networks may be utilized for higher quality of service, and several different video streams may be offered for streaming. Further of Lewis, at paragraph: 0032, lines 1 – 8, Besides advertisement insertion and user or client device targeting, rule resolution server 320 may also implement a wide variety of other rules to enhance, target, and customize the video streaming experience for the end user. For example, one rule may rewrite the URLs within a manifest file to point to the content delivery network in closest proximity to the client device, providing improved network performance and responsiveness];
receiving, at the playback server system, a request to play the piece of content from a playback device [Lewis, paragraph: 0017, lines 1 – 3, As shown in diagram 100, a client device 150 may send a request to dynamic manifest file server 110 for live video content.];
in response to receiving the play request:
retrieving, by the playback server system from the database, a set of asset locations within the content delivery network for assets from the plurality of assets associated with the piece of content that can be utilized by the playback device to play back the piece of content [Lewis, paragraph: 0032, lines 1 – 8, Besides advertisement insertion and user or client device targeting, rule resolution server 320 may also implement a wide variety of other rules to enhance, target, and customize the video streaming experience for the end user. For example, one rule may rewrite the URLs within a manifest file to point to the content delivery network in closest proximity to the client device, providing improved network performance and responsiveness.];
automatically generating, using the playback server system, a top level index, wherein the top level index includes the retrieved set of asset locations [Lewis, paragraph: 0032, lines 1 – 8, For example, one rule may rewrite the URLs within a manifest file to point to the content delivery network in closest proximity to the client device]; and
sending, by the playback server system, the generated top level index to the playback device [Lewis, paragraph: 0017, lines 21 – 26, Dynamic manifest file server 110 may then utilize rule resolution server 120 to evaluate various business rules and create a dynamically tailored manifest file accordingly, which may then be passed back to client device 150 over network 130 and placed into memory 155 as manifest file 157, as shown in FIG. 1.].
As per claim 2. Lewis does teach the method of claim 1, wherein each asset location in the set of asset locations identifies a server within the content delivery network [Lewis, paragraph: 0032, lines 1 – 8, Besides advertisement insertion and user or client device targeting, rule resolution server 320 may also implement a wide variety of other rules to enhance, target, and customize the video streaming experience for the end user. For example, one rule may rewrite the URLs within a manifest file to point to the content delivery network in closest proximity to the client device, providing improved network performance and responsiveness.].
As per claim 3. Lewis does teach the method of claim 1, wherein each asset location in the set of asset locations identifies a server within the content delivery network using a path [Lewis, paragraph: 0032, lines 1 – 8, Besides advertisement insertion and user or client device targeting, rule resolution server 320 may also implement a wide variety of other rules to enhance, target, and customize the video streaming experience for the end user. For example, one rule may rewrite the URLs within a manifest file to point to the content delivery network in closest proximity to the client device, providing improved network performance and responsiveness.].
As per claim 4. Lewis does teach the method of claim 1, further comprising:
in response to receiving the play request, determining by the playback server system a location of the playback device [Lewis, paragraph: 0031, In addition to preparing video content for optimal presentation quality, substantive content such as advertising content may also be targeted and prepared based on various parameterized rules evaluated by rule resolution server 320. Thus, for example, a user tracking profile associated with client device 350a may be analyzed to formulate a targeted advertising campaign for manifest file 357a, adding appropriate pre-roll, post-roll, and mid-roll advertising content estimated to be most relevant and interesting for the user of client device 350a. The geographic location or region of client device 350a may also be detected, for example through GPS tracking or geo-IP address look-up, and advertising may be adjusted accordingly for the detected region, for example by selecting from a regional advertising campaign. The detected region may also affect the requested substantive content, for example by configuring processed video segments 315a to include subtitles or a dubbed language track based on the detected region.];
wherein the set of asset locations is determined at least in part based upon the location of the playback device [Lewis, paragraph: 0031, In addition to preparing video content for optimal presentation quality, substantive content such as advertising content may also be targeted and prepared based on various parameterized rules evaluated by rule resolution server 320. Thus, for example, a user tracking profile associated with client device 350a may be analyzed to formulate a targeted advertising campaign for manifest file 357a, adding appropriate pre-roll, post-roll, and mid-roll advertising content estimated to be most relevant and interesting for the user of client device 350a. The geographic location or region of client device 350a may also be detected, for example through GPS tracking or geo-IP address look-up, and advertising may be adjusted accordingly for the detected region, for example by selecting from a regional advertising campaign. The detected region may also affect the requested substantive content, for example by configuring processed video segments 315a to include subtitles or a dubbed language track based on the detected region.].
As per method claim 5, that includes the same or similar claim limitations as method claim 2, and is similarly rejected.
As per method claim 6, that includes the same or similar claim limitations as method claim 3, and is similarly rejected.
As per claim 7. Lewis does teach the method of claim 4, further comprising:
in response to receiving the play request [Lewis, Figure # 4, and paragraph: 0036, Referring to step 410 of flowchart 400 in FIG. 4 and diagram 100 of FIG. 1, step 410 of flowchart 400 comprises processor 111 of dynamic manifest file server 110 receiving, from media player application 156 executing on processor 151 of client device 150, a request to provide a first video content for playback. For example, media player application 156 may comprise a HLS enabled web browser. User 185 may then use media player application 156 to navigate to a website presenting a list of available live video streams. After user 185 selects a live stream corresponding to a live event being captured by camera rig 185, a request for the live stream, such as a HTTP GET request, may be sent over network 130 to dynamic manifest file server 110.]:
retrieving, by the playback server system from the database, a listing of the plurality of assets associated with the piece of content [Lewis, paragraph: 0039, lines 23 – 29, Thus, for example, if the request received from step 410 identifies client device 150 as a HLS enabled web browser and display 160 as a screen with a 960 by 640 pixel resolution, then live video segments 175 and ad video segments 145 may be correspondingly resized to optimally fit within the target 960 by 640 pixel resolution];
filtering, by the playback server system, the listing of the plurality of assets associated with the piece of content based upon at least one playback capability of the playback device [Lewis, paragraph: 0039, lines 23 – 29, Thus, for example, if the request received from step 410 identifies client device 150 as a HLS enabled web browser and display 160 as a screen with a 960 by 640 pixel resolution, then live video segments 175 and ad video segments 145 may be correspondingly resized to optimally fit within the target 960 by 640 pixel resolution, manifest file 157 may be provided as a M3U8 file, and each of the referenced video segments may comprise a MPEG-2 transport stream (.TS) file, in accordance with HLS platform requirements.]; and
querying, by the playback server, the database to retrieve asset locations based upon the filtered listing of the plurality of assets associated with the piece of content [Lewis, paragraph: 0039, lines 23 – 29, Thus, for example, if the request received from step 410 identifies client device 150 as a HLS enabled web browser and display 160 as a screen with a 960 by 640 pixel resolution, then live video segments 175 and ad video segments 145 may be correspondingly resized to optimally fit within the target 960 by 640 pixel resolution, manifest file 157 may be provided as a M3U8 file, and each of the referenced video segments may comprise a MPEG-2 transport stream (.TS) file, in accordance with HLS platform requirements.].
As per claim 8. Lewis does teach the method of claim 7, wherein the play request comprises a product identifier that describes the playback device [Lewis, paragraph: 0027, lines 1 – 5, For example, for client device 350a, platform rule set 322a may dictate that if a request originates from a client device indicating Flash Player plug-in support, then dynamic manifest file server 310 should preferably generate a F4M Flash Zeri manifest file, or manifest file 357a, referencing F4F Flash video files, or processed video segments 315a].
As per claim 9. Lewis does teach the method of claim 8, further comprising:
maintaining, by the playback server system, a database of product identifiers and associated playback capabilities [Lewis, paragraph: 0039, lines 16 – 23, To provide another example, the evaluation of rules such as platform rule set 322a and resolution rule set 322b shown in diagram 300 of FIG. 3 may further direct processor 111 to process live video segments 175 for optimal video quality depending on the requesting client device.]; and
retrieving, by the playback server system from the database of product identifiers, the at least one playback capability of the playback device using the product identifier [Lewis, paragraph: 0039, lines 23 – 29, Thus, for example, if the request received from step 410 identifies client device 150 as a HLS enabled web browser and display 160 as a screen with a 960 by 640 pixel resolution, then live video segments 175 and ad video segments 145 may be correspondingly resized to optimally fit within the target 960 by 640 pixel resolution, manifest file 157 may be provided as a M3U8 file, and each of the referenced video segments may comprise a MPEG-2 transport stream (.TS) file, in accordance with HLS platform requirements. ].
As per method claim 10, that includes the same or similar claim limitations as method claim 7, and is similarly rejected.
As per method claim 11, that includes the same or similar claim limitations as method claim 2, and is similarly rejected.
As per method claim 12, that includes the same or similar claim limitations as method claim 3, and is similarly rejected.
As per claim 13. Lewis does teach the method of claim 10, wherein the play request comprises a product identifier that describes the playback device [Lewis, paragraph: 0027, lines 1 – 5, For example, for client device 350a, platform rule set 322a may dictate that if a request originates from a client device indicating Flash Player plug-in support, then dynamic manifest file server 310 should preferably generate a F4M Flash Zeri manifest file, or manifest file 357a, referencing F4F Flash video files, or processed video segments 315a].
As per claim 14. Lewis does teach the method of claim 13, further comprising:
maintaining, by the playback server system, a database of product identifiers and associated playback capabilities [Lewis, Figure # 1, 2, paragraph: 0026, While FIGS. 1 and 2 illustrate an advertisement insertion embodiment, FIG. 3 illustrates client or device targeting, wherein video content is processed and customized according to particular client device parameters. As shown in FIG. 3, dynamic manifest file server 310 provides manifest files for a diverse range of client device platforms, including Flash Player plugin 356a at client device 350a, HTTP Live Streaming client 356b at client device 350b, and native binary application 356c at client device 356c. Platform rule set 322a may include various rules as how to customize video content based on the target device platform to be supported. Additionally, displays 360a, 360b, and 360c each utilize different screen resolutions to display video content, and resolution rule set 322b may include various rules as how to resize video content based on the target display resolution.]; and
retrieving, by the playback server system from the database of product identifiers, the at least one playback capability of the playback device using the product identifier [Lewis, paragraph: 0028, lines 1 – 5, Moving to client device 350b, platform rule set 322a may dictate that if a request originates from a client device indicating HLS or HTTP Live Streaming support, then dynamic manifest file server 310 should preferably generate a M3U8 manifest file, or manifest file 357b, referencing MPEG transport stream video files, or processed video segments 315b.].
As per claim 16. Lewis does teach the method of claim 1, wherein each asset in the plurality of assets is stored in a separate container file [Lewis, Figure # 1, component # 175 – live video segments, component # 145 – Ad video segments, and paragraph: 0015, lines 8 – 12, FIG. 1 presents a diagram of a system for providing rule-based dynamic server-side streaming manifest files, according to one embodiment of the present invention. Diagram 100 of FIG. 1 includes producer 180, camera rig 185, live video encoder 170, rule resolution server 120, dynamic manifest file server 110, content delivery network 135, display 160, network 130, advertisement video storage 140, client device 150, and user 185. Live video encoder 170 includes live video segments 175. Rule resolution server 120 includes processor 121. Dynamic manifest file server 110 includes processor 111. Advertisement video storage 140 includes ad video segments 145. Client device 150 includes processor 151 and memory 155. Memory 155 includes media player application 156 and manifest file 157.].
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 (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 pre-AIA 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under pre-AIA 35 U.S.C. 103(a) 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 non-obviousness.
Claim[s] 15, 17 - 20 is/are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Lewis et al. [US PGPUB # 2012/0047542] in view of Thorwirth et al. [US PGPUB # 2013/0054972]
As per claim 15. Lewis as modified does teach the method of claim 1, wherein at least one of the plurality of assets associated with the piece of content is selected from the group consisting of: a video stream, an audio stream[Thorwirth, paragraph: 0009, lines 1-4, In adaptive streaming systems, the source media is often organized on a media server with the help of a top level index file pointing to a number of alternate streams that contain the actual video and audio data.], and a subtitle stream [Thorwirth, paragraph: 0002, The term "content" can be used to describe digital media such as audio, video, an image, a collection of images or a combination thereof. A digital content file can include several streams of audio, video and text in different tracks. Different tracks may contain different video programs, alternative audio tracks for different languages, and/or text for subtitles].
As per method claim 17, that includes the same or similar claim limitations as method claim 19, and is similarly rejected.
As per method claim 18, that includes the same or similar claim limitations as method claim 6, and is similarly rejected.
As per claim 19. Lewis does teach a method of automatically generating a top level index for a piece of content using a playback server system in response to receipt of a play request from a playback device [Lewis, paragraph: 0016, As shown in diagram 100 of FIG. 1, producer 180 may direct camera rig 185 to record live footage, such as a live event, to be streamed to users such as user 185……As new live footage is captured and approved, new video segments may be encoded and stored within live video segments 175, which may then be distributed over content delivery network 135. Content delivery network 135 may, for example, comprise a network of servers for storage and distribution of media content. Live video encoder 170 may also provide rule resolution server 120 with an updated list of references for accessing live video segments 175 through content delivery network 135, which may then be passed to dynamic manifest file server 110 for generating manifest file 157. Producer 180 may provide specific rules to rule resolution server 120 to customize the generation of manifest file 157, such a rule to insert advertising segments to overwrite a particular time block in the live stream], the method comprising:
distributing, by a playback server system, a plurality of assets associated with a piece of content to a content delivery network [Lewis, paragraph: 0019, lines 20 – 22, For example, dynamic manifest file server 110 and rule resolution server 120 may be combined into a single server, multiple servers may be utilized for load balancing to multiple client devices, multiple content delivery networks may be utilized for higher quality of service, and several different video streams may be offered for streaming. Further of Lewis, at paragraph: 0032, lines 1 – 8, Besides advertisement insertion and user or client device targeting, rule resolution server 320 may also implement a wide variety of other rules to enhance, target, and customize the video streaming experience for the end user. For example, one rule may rewrite the URLs within a manifest file to point to the content delivery network in closest proximity to the client device, providing improved network performance and responsiveness], wherein:
each of the plurality of assets is stored in at least one asset location within the content delivery network [Lewis, at paragraph: 0032, lines 1 – 8, Besides advertisement insertion and user or client device targeting, rule resolution server 320 may also implement a wide variety of other rules to enhance, target, and customize the video streaming experience for the end user. For example, one rule may rewrite the URLs within a manifest file to point to the content delivery network in closest proximity to the client device];
maintaining, by the playback server system, a database containing the asset locations within the content delivery network of the plurality of assets associated with the piece of content [Lewis, at paragraph: 0032, lines 1 – 8, Besides advertisement insertion and user or client device targeting, rule resolution server 320 may also implement a wide variety of other rules to enhance, target, and customize the video streaming experience for the end user. For example, one rule may rewrite the URLs within a manifest file to point to the content delivery network in closest proximity to the client device];
maintaining, by the playback server system, a database of product identifiers and associated playback capabilities [Lewis, paragraph: 0039, lines 16 – 23, To provide another example, the evaluation of rules such as platform rule set 322a and resolution rule set 322b shown in diagram 300 of FIG. 3 may further direct processor 111 to process live video segments 175 for optimal video quality depending on the requesting client device.];
receiving, at the playback server system, a request to play the piece of content from a playback device, where the play request comprises a product identifier that describes the playback device [Lewis, paragraph: 0039, lines 23 – 29, Thus, for example, if the request received from step 410 identifies client device 150 as a HLS enabled web browser and display 160 as a screen with a 960 by 640 pixel resolution, then live video segments 175 and ad video segments 145 may be correspondingly resized to optimally fit within the target 960 by 640 pixel resolution, manifest file 157 may be provided as a M3U8 file, and each of the referenced video segments may comprise a MPEG-2 transport stream (.TS) file, in accordance with HLS platform requirements.];
in response to receiving the play request:
retrieving, by the playback server from the database of asset locations, a listing of the plurality of assets associated with the piece of content [Lewis, at paragraph: 0032, lines 1 – 8, Besides advertisement insertion and user or client device targeting, rule resolution server 320 may also implement a wide variety of other rules to enhance, target, and customize the video streaming experience for the end user. For example, one rule may rewrite the URLs within a manifest file to point to the content delivery network in closest proximity to the client device];
retrieving, by the playback server system from the database of product identifiers, at least one playback capability of the playback device using the product identifier [Lewis, paragraph: 0028, lines 1 – 5, Moving to client device 350b, platform rule set 322a may dictate that if a request originates from a client device indicating HLS or HTTP Live Streaming support, then dynamic manifest file server 310 should preferably generate a M3U8 manifest file, or manifest file 357b, referencing MPEG transport stream video files, or processed video segments 315b.];
filtering, by the playback server, the listing of the plurality of assets associated with the piece of content based upon the at least one playback capability of the playback device retrieved using the product identifier [Lewis, paragraph: 0028, lines 1 – 5, Moving to client device 350b, platform rule set 322a may dictate that if a request originates from a client device indicating HLS or HTTP Live Streaming support, then dynamic manifest file server 310 should preferably generate a M3U8 manifest file, or manifest file 357b, referencing MPEG transport stream video files, or processed video segments 315b.];
querying, by the playback server, the database to retrieve a set of asset locations within the content delivery network based upon the filtered listing of the plurality of assets associated with the piece of content, wherein each asset location in the set of asset locations identifies a server within the content delivery network [Lewis, paragraph: 0019, lines 20 – 22, For example, dynamic manifest file server 110 and rule resolution server 120 may be combined into a single server, multiple servers may be utilized for load balancing to multiple client devices, multiple content delivery networks may be utilized for higher quality of service, and several different video streams may be offered for streaming. Further of Lewis, at paragraph: 0032, lines 1 – 8, Besides advertisement insertion and user or client device targeting, rule resolution server 320 may also implement a wide variety of other rules to enhance, target, and customize the video streaming experience for the end user. For example, one rule may rewrite the URLs within a manifest file to point to the content delivery network in closest proximity to the client device, providing improved network performance and responsiveness];
automatically generating, using the playback server system, a top level index, wherein the top level index includes the retrieved set of asset locations [Lewis, paragraph: 0032, lines 1 – 8, For example, one rule may rewrite the URLs within a manifest file to point to the content delivery network in closest proximity to the client device]; and
sending, by the playback server system, the generated top level index to the playback device [Lewis, paragraph: 0017, lines 21 – 26, Dynamic manifest file server 110 may then utilize rule resolution server 120 to evaluate various business rules and create a dynamically tailored manifest file accordingly, which may then be passed back to client device 150 over network 130 and placed into memory 155 as manifest file 157, as shown in FIG. 1.].
While Lewis does not clearly teach the claim limitation of: “…the plurality of assets associated with the piece of content comprises at least a plurality of video streams, a plurality of audio streams, and a plurality of subtitle streams…”
However, Thorwirth does teach the claim limitation of: “…the plurality of assets associated with the piece of content comprises at least a plurality of video streams, a plurality of audio streams, and a plurality of subtitle streams… [paragraph: 0009, lines 1-4, In adaptive streaming systems, the source media is often organized on a media server with the help of a top level index file pointing to a number of alternate streams that contain the actual video and audio data
Then further of Thorwirth, at paragraph: 0002, The term "content" can be used to describe digital media such as audio, video, an image, a collection of images or a combination thereof. A digital content file can include several streams of audio, video and text in different tracks. Different tracks may contain different video programs, alternative audio tracks for different languages, and/or text for subtitles. Content is typically encoded or compressed for efficient transmission and storage. Common encoding formats include MPEG-2, VC-1 and H.264 for video and mp3 (i.e. MPEG-1 Audio Layer 3), AAC and Ogg Vorbis for audio.].”
It would have been obvious to one of ordinary skilled in the art at time of the claimed invention to combine the teachings of Lewis and Thorwirth in order for the generation of manifest file and content by receiving a request for playback of content from a client thru a playback server of Lewis, to include encrypting the manifest file and content of Thorwirth. This would allow for the manifest file and playback content to be secured while in transit based on the unique parameters of the requesting client device. See paragraph: 0033 - 0035 of Thorwirth.
As per method claim 20 that includes the same or similar claim limitations as method claim 18, and is similarly rejected.
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 DANT SHAIFER - HARRIMAN whose telephone number is (571)272-7910. The examiner can normally be reached M - F: 9am to 5pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Ali Shayanfar can be reached at 570 – 270 - 1050. 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.
/DANT B SHAIFER HARRIMAN/ Primary Examiner, Art Unit 2434
Prosecution Insights