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 have been fully considered.
Regarding claim[s] 1 – 23 under the various obviousness rejections, applicant’s remarks are not persuasive, therefore, see the examiner’s response to such remarks in the office action below.
The examiner will respond to all other remarks that do to concern the prior art rejections, if any, in the office action below.
Applicant states on page[s] 1 - 3 of the remark as filed: “Claims 1-5, 10-21, and 23 are rejected under 35 U.S.C. § 103 as being unpatentable over Lewis in view of Tinsman, and further in view of various secondary references. Office action, page 22. Applicant respectfully traverses this rejection and submits that a person of ordinary skill in the art would not have been motivated to combine the references as proposed by the Examiner. The Office action has alleged that Lewis and Tinsman are combinable because both utilize multicast streaming platforms. See Office action, pages 13 and 18. Applicant respectfully submits that even accepting the Office action's premise that Lewis is capable of operating in a multicast environment, a person of ordinary skill in the art (POSITA) would not be motivated to combine the functionality of Tinsman's router filtering into the dynamic manifest file server of Lewis. Multicast systems are capable of achieving efficiency gains within the backbone of a communication network, because a single stream can be transmitted through the backbone to the edge of the network and then distributed to multiple playback devices. By comparison, a unicast system would require a separate stream to be transmitted through the backbone of the network to each of the playback devices. Applicant respectfully submits that Lewis provides minimal disclosure regarding multicast content distribution, simply reciting IP multicast as a distribution option when discussing Fig. 1 in paragraph [0016]. ("For example, the live video footage may be encoded into MPEG transport stream (TS) fragment files of a fixed length, such as 10 seconds, for ease of distribution using streaming protocols such as HTTP streaming, IP multicast, P2P streaming."). Fig. 1 of Lewis is reproduced below.
----Diagram Omitted----
As can readily be appreciated from the above diagram, the dynamic manifest file 110 server of Lewis communicates with the client device 150 via a separate communication path to the communication path that it used to distribute the live video segments 175, irrespective of whether an HTTP streaming or IP multicast protocol is utilized.”
In response, the examiner isn’t persuaded, the examiner points out that applicant is claiming a unicast system for use with a single communication path to a single device and not multicast system thru multiple communication paths to multiple devices as argued by applicant. While applicant in their latest claim amendments recites that the playback server system is capable receiving requests from different types of playback devices with different playback capabilities. However, one of ordinary skill in the art would know that each of the recited playback devices could submit requests to the playback server independently of the other devices at different times regardless of when the other devices submit their requests. Further, one of ordinary skilled in the art would know that the recited phrase “playback server system is capable,” does not mean the server is actually receiving multiple requests from a plurality of different playback devices [emphasis added…]. It is further noted that one of ordinary skilled in the art would know that the recited phrase “playback server system is capable,” is an intended use or field of use claim limitation. Such claim limitation does not further limit the claim.
What is further since the claim language as recited does not intentionally recite a multicast playback server system and multiple playback devices making requests to the playback server system in a further limiting manner, thus the application of prior art combination of Lewis in view of Tinsman is fair and reasonable making applicants argued/claim invention an obvious variation over the prior art combination.
Applicant states on page[s] 4 and 5 of the remark as filed: “Tinsman's router filtering addresses a problem that exists specifically at the edge of multicast networks, that is, the bandwidth bottleneck between the router and its connected devices on the "last mile." As Tinsman explains, "in cases mentioned above in which the router 2400 may not have access to enough communication bandwidth to transmit the video data for each requested video stream, the router 2400 may preemptively remove any video streams with higher data rates from the manifest that would oversubscribe the capacity of the communication link between the router 2400 and its devices." Tinsman, paragraph [0207]. In effect, the router of Tinsman is removing from a manifest file information concerning a video stream that a device has the capability to playback based upon a decision to prevent the forwarding of the video stream based upon the limited capacity of link between the router and the device.
Applicant respectfully submits that Lewis does not disclose that the dynamic manifest file server 110 has access to information concerning available capacity on links between routers and devices at the edge of network 130. Neither, Tinsman nor the statement of the rejection provides any explanation as to how this information could be provided to the dynamic manifest server of Lewis by routers within network 130. MPEP § 2143.02 provides that "[w]here there is a reason to modify or combine the prior art to achieve the claimed invention, the claims may be rejected as prima facie obvious provided there is also a reasonable expectation of success." MPEP § 2143.02 further provides that "[e]vidence showing there was no reasonable expectation of success may support a conclusion of non-obviousness." Additionally, MPEP § 2143.01(V) provides that "[i]f a proposed modification would render the prior art invention being modified unsatisfactory for its intended purpose, then there is no suggestion or motivation to make the proposed modification."
MPEP § 2143.01(VI) further provides that "[i]f the proposed modification or combination of the prior art would change the principle of operation of the prior art invention being modified, then the teachings of the references are not sufficient to render the claims prima facie obvious."
In view of the above, Applicant respectfully submits that the statement of the rejection fails to establish a prima facie case of obviousness, because a POSITA would not have had any reasonable expectation of success in modifying the dynamic manifest file server 110 of Lewis in a multicast system to incorporate the filtering process of Tinsman, because the dynamic manifest file server 110 would not have had access to the link capacity information necessary to perform the filtering process of Tinsman. Applicant further submits that a POSITA seeking to add the filtering process of Tinsman to the multicast system described in Lewis would have implemented the filtering processes in the edge routers of network 130 in the manner described in Tinsman and not at the dynamic manifest file server 110.”
In response, the examiner isn’t persuaded, the examiner points out that applicant’s remarks that the prior art of Lewis is not combinable with the prior art of Tinsman based on that Lewis doesn’t solve or even describe the solving of the limited capacity of link of Tinsman. The prior art of Lewis is analogous to Tinsman based on both prior arts teach multicasting environments. Further, while Lewis solves a different type of problem than Tinsman, but that does not mean Lewis is can’t be combinable with Tinsman as articulated by examiner. The examiner point’s applicant to the following MPEP citation:
-----[Wingdings font/0xE0]MPEP 2141.01(a) Analogous and Nonanalogous Art [R-01.2024]
I. TO RELY ON A REFERENCE UNDER 35 U.S.C. 103, IT MUST BE ANALOGOUS ART TO THE CLAIMED INVENTION
In order for a reference to be proper for use in an obviousness rejection under 35 USC 103, the reference must be analogous art to the claimed invention. In re Bigio, 381 F.3d 1320, 1325, 72 USPQ2d 1209, 1212 (Fed. Cir. 2004). A reference is analogous art to the claimed invention if: (1) the reference is from the same field of endeavor as the claimed invention (even if it addresses a different problem); or (2) the reference is reasonably pertinent to the problem faced by the inventor (even if it is not in the same field of endeavor as the claimed invention). Note that "same field of endeavor" and "reasonably pertinent" are two separate tests for establishing analogous art; it is not necessary for a reference to fulfill both tests in order to qualify as analogous art. See Bigio, 381 F.3d at 1325, 72 USPQ2d at 1212. The examiner must determine whether a reference is analogous art to the claimed invention when analyzing the obviousness of the subject matter under examination. When more than one prior art reference is used as the basis of an obviousness rejection, it is not required that the references be analogous art to each other. See Sanofi-Aventis Deutschland GMbH v. Mylan Pharms. Inc., 66 F.4th 1373, 1380, 2023 USPQ2d 552 (Fed. Cir. 2023) and Corephotonics, Ltd. v. Apple Inc., 84 F.4th 990, 1007, 2023 USPQ2d 1202 (Fed. Cir. 2023). If a reference is not analogous art to the claimed invention, it may not be used in an obviousness rejection under 35 USC 103. However, there is no analogous art requirement for a reference being applied in an anticipation rejection under 35 USC 102 In re Schreiber, 128 F.3d 1473, 1478, 44 USPQ2d 1429, 1432 (Fed. Cir. 1997).
When determining whether the "relevant field of endeavor" test is met, the examiner should consider "explanations of the invention’s subject matter in the patent application, including the embodiments, function, and structure of the claimed invention." Airbus S.A.S. v. Firepass Corp., 941 F.3d 1374, 1380, 2019 USPQ2d 430083 (Fed. Cir. 2019) (quoting Bigio, 381 F.3d at 1325, 72 USPQ2d at 1212). When determining whether a prior art reference meets the "same field of endeavor" test for the analogous art, the primary focus is on what the reference discloses. Airbus, 41 F.3d at 1380. The examiner must consider the disclosure of each reference "in view of the ‘the reality of the circumstances.’" Airbus, 41 F.3d at 1380 (quoting Bigio, 381 F.3d at 1326, 72 USPQ2d at 1212). These circumstances are to be weighed "from the vantage point of the common sense likely to be exerted by one of ordinary skill in the art in assessing the scope of the endeavor." Airbus, 41 F.3d at 1380. See also Donner Technology, LLC v. Pro Stage Gear, LLC, 979 F.3d 1353, 2020 USPQ2d 11335 (Fed. Cir. 2020); Sanofi-Aventis, 66 F.4th at 1378; and Netflix, Inc. v. DivX, LLC, 80 F.4th 1352, 1358-59, 2023 USPQ2d 1057 (Fed. Cir. 2023) ("The field of endeavor is ‘not limited to the specific point of novelty, the narrowest possible conception of the field, or the particular focus within a given field.’") (quoting Unwired Planet, LLC v. Google Inc., 841 F.3d 995, 1001, 120 USPQ2d 1593, 1597 (Fed. Cir. 2016)).
As for the "reasonably pertinent" test, the examiner should consider the problem faced by the inventor, as reflected - either explicitly or implicitly - in the specification. In order for a reference to be "reasonably pertinent" to the problem, it must "logically [] have commended itself to an inventor's attention in considering his problem." In re ICON Health and Fitness, Inc., 496 F.3d 1374, 1379-80 (Fed. Cir. 2007) (quoting In re Clay, 966 F.2d 656,658, 23 USPQ2d 1058, 1061 (Fed. Cir. 1992)). See also In re Klein, 647 F.3d 1343, 1348, 98 USPQ2d 1991, 1993 (Fed. Cir. 2011) An inventor is not expected to have been aware of all prior art outside of the field of endeavor. Airbus, 41 F.3d at 1380-82. A reference outside of the field of endeavor is reasonably pertinent if a person of ordinary skill would have consulted it and applied its teachings when faced with the problem that the inventor was trying to solve. Airbus, 41 F.3d at 1380-82. In order to support a determination that a reference is reasonably pertinent, it may be appropriate to include a statement of the examiner's understanding of the problem. The question of whether a reference is reasonably pertinent often turns on how the problem to be solved is perceived. If the problem to be solved is viewed in a narrow or constrained way, and such a view is not consistent with the specification, the scope of available prior art may be inappropriately limited. It may be necessary for the examiner to explain why an inventor seeking to solve the identified problem would have looked to the reference in an attempt to find a solution to the problem, i.e., factual reasons why the prior art is pertinent to the identified problem. See Donner Tech., LLC v. Pro Stage Gear, LLC, 979 F.3d 1353, 1359, 2020 USPQ2d 11335 (Fed. Cir. 2020) ("Thus, when addressing whether a reference is analogous art with respect to the claimed invention under a reasonable-pertinence theory, the problems to which both relate must be identified and compared.").
The Supreme Court’s decision in KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007), did not change the test for analogous art as stated in Bigio. Under Bigio, a reference need not be from the same field of endeavor as the claimed invention in order to be analogous art. Bigio, 381 F.3d at 1325, 72 USPQ2d at 1212. This is consistent with the Supreme Court's instruction in KSR that "[w]hen a work is available in one field of endeavor, design incentives and other market forces can prompt variations of it, either in the same field or a different one." KSR, 550 U.S. at 417, 82 USPQ2d at 1396. The Federal Circuit reads KSR as "direct[ing] us to construe the scope of analogous art broadly" because "familiar items may have obvious uses beyond their primary purposes, and a person of ordinary skill often will be able to fit the teachings of multiple patents together like pieces of a puzzle." Wyers v. Master Lock Co., 616 F.3d 1231, 1238, 95 USPQ2d 1525, 1530 (Fed. Cir. 2010) (quoting KSR, 550 U.S. at 402, 127 S. Ct. at 1727).
Applicant states on page[s] 5 - 6 of the remark as filed: “Moreover, the proposed combination would render Lewis unsuitable for its intended purpose. Lewis explains that streaming platforms allow "users [to] enjoy live or recorded video content streamed conveniently to their favorite media consumption devices, whether it be a laptop or desktop computer, a mobile phone, a video game console, a digital video recorder, a set top box, or another network enabled media device."
Lewis, paragraph [0004]. Lewis further teaches that "multiple bit-rate streams may be
encoded and referenced in the generated manifest files to allow graceful degradation to lower bit-rate video in response to adverse network conditions." Lewis, paragraph [0030]. The purpose of having multiple encodings at different bitrates is to allow each playback device to receive the highest quality video its network connection can support. The proposed combination would defeat this purpose-instead of the playback device having the capacity to request the highest quality video its connection could support at each instant in time, a playback device would receive a manifest that only contained information concerning streams that could be supported on the link between the playback device and an edge router in network 130 at the time the manifest was generated and/or forwarded to the playback device by the edge router. In the event that the capacity of the link increased, the playback device would not have information concerning the streams that could then be supported because that information would have been removed from the manifest file that the playback device received This undermines the fundamental principle of operation of Lewis's adaptive bitrate streaming system.
Because a POSITA would have no reasonable expectation of success and
because the proposed combination would render Lewis unsuitable for its intended purpose, the only reason for proposing this combination is impermissible hindsight based on Applicant's own disclosure.
In summary, a POSITA would not be motivated to combine the references in the manner proposed, and Applicant submits that independent claims 1 and 20 are patentable over the cited references. The dependent claims are patentable for at least the same reasons as the claims from which they depend. Applicant respectfully requests withdrawal of the § 103 rejections.”
In response, the examiner isn’t persuaded, the examiner points out that applicant is claiming a unicast system for use with a single communication path to a single device and not multicast system thru multiple communication paths to multiple devices as argued by applicant. While applicant in their latest claim amendments recites that the playback server system is capable receiving requests from different types of playback devices with different playback capabilities. However, one of ordinary skill in the art would know that each of the recited playback devices could submit requests to the playback server independently of the other devices at different times regardless of when the other devices submit their requests. Further, one of ordinary skilled in the art would know that the recited phrase “playback server system is capable,” does not mean the server is actually receiving multiple requests from a plurality of different playback devices [emphasis added…]. It is further noted that one of ordinary skilled in the art would know that the recited phrase “playback server system is capable,” is an intended use or field of use claim limitation. Such claim limitation does not further limit the claim.
Response to Amendment
Status of the instant application:
Claim[s] 1 – 5, 10 – 21, 24 are pending in the instant application.
Claim[s] 6 – 9, 22, 23 have been cancelled by applicant in response to the latest office action or in previous prosecution, therefore, the rejections are withdrawn based on the cancellation of the claims.
Regarding claim[s] 1 – 5, 10 – 21, 24 under the various obviousness rejections, applicant’s claim amendments have been considered, but are not persuasive. And are addressed in the office action below.
Claim[s] 24, is a newly added claim and is addressed in the office action below.
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] 1 - 4, 10, 12, 13, 14, 17, 18, 21, 24 is/are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Lewis et al. [US PGPUB # 2021/0047542] in view of Tinsman [US PGPUB # 2011/0255535]
As per claim 1. Lewis does teach the method of generating a top-level index file customized to capabilities of a particular type of device [Lewis, paragraph: 0014, lines 1 – 3, The present application is directed to a system and method for rule-based dynamic server-side streaming manifest files.
Further of Lewis, at Figure # 3, and paragraph: 0026, lines 5 – 9, 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], comprising:
receiving, at a playback server system, a request for a top level index describing a piece of content from a playback device [Lewis, Figure # 1, and 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], where the request identifies specific capabilities of the playback device [Lewis, Figure # 4, and paragraph: 0037, lines 1 – 16, Referring to step 420 of flowchart 400 in FIG. 4 and diagram 100 of FIG. 1, step 420 of flowchart 400 comprises processor 111 of dynamic manifest file server 110 passing parameters from the request received in step 410 to rule resolution server 120, which may then evaluate a plurality of rules for the live event requested in step 410. Thus, parameter data from the HTTP GET request and other platform parameters of client device 150 that may be retrieved automatically, such as by scripting, or voluntarily, such as from user form data, may all be passed to rule resolution server 120 for further evaluation. These parameters may include details such as the client IP address, browser or operating platform, device identifiers, browser cookies or login details, screen resolution of display 160, and other device, display, or user parameters, which may then be evaluated against a plurality of rules as applied to live video segments 175.];
the playback server system is capable of receiving requests from a plurality of different types of playback devices that each have different playback capabilities [Lewis, Figures 1, 2, and paragraph: 0026, lines 1 – 4, 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.
Where further of Lewis, at Figure # 3, and paragraph: 0026, lines 5 – 9, 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];
the playback device is a specific type of playback device and the plurality of different types of playback devices includes the specific type of the playback device [Lewis, at paragraph: 0030, lines 19 – 22, Additionally, multiple bit-rate streams may be encoded and referenced in the generated manifest files to allow graceful degradation to lower bit-rate video in response to adverse network conditions];
in response to the received request, automatically generating at the playback server system, a top-level index customized for the specific capabilities of the playback device [Figure # 1, and paragraph: 0017, lines 15 – 18, Dynamic manifest file server 110 may then forward various parameters received from the request originating from client device 150 to rule resolution server 120. Client device 150 may also explicitly send parameter data to dynamic manifest file server 110 voluntarily or in response to a request for client parameters.] by:
retrieving, by the playback server system, information concerning a set of alternative streams [Lewis, Figure # 1, and paragraph: 0018, lines 1 – 5, Media player application 156 may then interpret manifest file 157 to playback video content on display 160. For example, manifest file 157 may reference live video segments 175 and ad video segments 145 on servers hosted in content delivery network 135, accessible over network 130] that can be utilized to perform adaptive bitrate streaming [Lewis, paragraph: 0030, lines 18 – 22, To provide faster response time for client devices, video for the most common client configurations may be pre-processed and cached in advance. Additionally, multiple bit-rate streams may be encoded and referenced in the generated manifest files to allow graceful degradation to lower bit-rate video in response to adverse network conditions.], where each stream in the set of alternative streams encodes a piece of content at a different bitrate [Lewis, paragraph: 0021, As previously discussed, media files may be encoded and segmented into fragment files of a fixed length to facilitate integration with streaming platforms. Thus, as shown in FIG. 2, live video segments 275 may be prepared as successive ten second segments, shown as segments 276a through 276e. Similarly, ad video segments 245 are also prepared as three ten second segments, or segments 246a through 246c, which may comprise one complete thirty second commercial. As additional live footage is recorded and encoded into new segments, the new segments may be appended within live video segments 275.
Where further of Lewis at paragraph: 0030, lines 19 – 22, Additionally, multiple bit-rate streams may be encoded and referenced in the generated manifest files to allow graceful degradation to lower bit-rate video in response to adverse network conditions] and having particular characteristics [Lewis, paragraph: 0030, lines 1 – 18, Thus, dynamic manifest file 310 and rule resolution server 320 may target specific client platforms to provide the optimal format for the manifest files and the processed video segments, and may also resize and process video for the best appearance on the specific display for each client device. While display resolution is shown as one example display parameter, other display parameters may also be considered such as color space or gamut, color bit-depth, refresh rate, and other parameters];
filtering, by the playback server system, the information concerning the set of alternative streams….. based on [Figure # 4, paragraph: 0037, lines 1 – 14, Referring to step 420 of flowchart 400 in FIG. 4 and diagram 100 of FIG. 1, step 420 of flowchart 400 comprises processor 111 of dynamic manifest file server 110 passing parameters from the request received in step 410 to rule resolution server 120, which may then evaluate a plurality of rules for the live event requested in step 410. Thus, parameter data from the HTTP GET request and other platform parameters of client device 150 that may be retrieved automatically, such as by scripting, or voluntarily, such as from user form data, may all be passed to rule resolution server 120 for further evaluation] the request, wherein the filtering comprise [paragraph: 0030, lines 1 – 18, Thus, dynamic manifest file 310 and rule resolution server 320 may target specific client platforms to provide the optimal format for the manifest files and the processed video segments [i.e. applicant’s filtering], and may also resize and process video for the best appearance on the specific display for each client device. While display resolution is shown as one example display parameter, other display parameters may also be considered such as color space or gamut, color bit-depth, refresh rate, and other parameters] comparing the particular characteristics of the at least one stream from the set of alternative streams and the specific capabilities of the playback device identified in the request [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.
Then further of paragraph: 0037, lines 1 – 14, Referring to step 420 of flowchart 400 in FIG. 4 and diagram 100 of FIG. 1, step 420 of flowchart 400 comprises processor 111 of dynamic manifest file server 110 passing parameters from the request received in step 410 to rule resolution server 120, which may then evaluate a plurality of rules for the live event requested in step 410. Thus, parameter data from the HTTP GET request and other platform parameters of client device 150 that may be retrieved automatically, such as by scripting, or voluntarily, such as from user form data, may all be passed to rule resolution server 120 for further evaluation. These parameters may include details such as the client IP address, browser or operating platform, device identifiers, browser cookies or login details, screen resolution of display 160, and other device, display, or user parameters, which may then be evaluated against a plurality of rules as applied to live video segments 175.], wherein the filtered information describes a plurality of alternative streams from the set of alternative streams…. [Figure # 1, and paragraph: 0018, lines 1 – 5, Media player application 156 may then interpret manifest file 157 to playback video content on display 160. For example, manifest file 157 may reference live video segments 175 and ad video segments 145 on servers hosted in content delivery network 135, accessible over network 130]……..and that are permitted to be played back by the playback device [Lewis, paragraph: 0030, Thus, dynamic manifest file 310 and rule resolution server 320 may target specific client platforms to provide the optimal format for the manifest files and the processed video segments, and may also resize and process video for the best appearance on the specific display for each client device. While display resolution is shown as one example display parameter, other display parameters may also be considered such as color space or gamut, color bit-depth, refresh rate, and other parameters. Thus, as one example, rule resolution server 320 may include a color space conversion rule to adjust video colors to the color space of a targeted display. Another example rule may comprise a framerate conversion rule converting video framerates to adjust to specific refresh rates of a targeted display, or down sampling three-dimensional stereoscopic video intended for three-dimensional displays into two-dimensional video for standard two-dimensional displays. To provide faster response time for client devices, video for the most common client configurations may be pre-processed and cached in advance. Additionally, multiple bit-rate streams may be encoded and referenced in the generated manifest files to allow graceful degradation to lower bit-rate video in response to adverse network conditions]; and
dynamically generating, by the playback server system, a top-level index customized to the specific capabilities of the playback device [Figure # 3, and paragraph: 0026, lines 5 – 9, 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.], where the customized top-level index describes a plurality of characteristics of each stream in the set plurality of alternative streams [Lewis, Figure # 1, and paragraph: 0022, lines 1 - 3]; and
sending the dynamically generated customized top level index to the playback device using the playback server system [Lewis, Figure # 1, and 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.].
Lewis does not clearly teach the claim limitation of: “…...to remove information concerning at least one stream from the set of alternative streams that the playback device is not permitted to playback…..…..that can be utilized to perform adaptive bitrate streaming.”
However, Tinsman does teach the claim limitation of: “…...to remove information concerning at least one stream from the set of alternative streams that the playback device is not permitted to playback…..…..that can be utilized to perform adaptive bitrate streaming.” [paragraph: 0207, In any of the examples regarding the router 2400 described above, some of the hierarchical data, such as either the video streams themselves, or any associated adaptive streaming manifests or similar information, may be reduced or limited before being presented to the devices. In one example, in cases mentioned above in which the router 2400 may not have access to enough communication bandwidth to transmit the video data for each requested video stream, the router 2400 may pre-emptively remove any video streams [i.e. applicant’s….to remove information….not permitted to playback] with higher data rates from the manifest that would oversubscribe the capacity of the communication link between the router 2400 and its devices. At a later time in which more bandwidth is available in the link, the router 2400 may then reintroduce the information for the higher-data-rate stream back into the manifest to make the associated video data streams available to the devices].”
It would have been obvious to one of ordinary skilled in the art at the time of the claimed invention to combine the teachings of Lewis as modified and Tinsman in order for the generating of the dynamic manifest file in response to a request by the user-client to access video content of a provider of Lewis as modified to multi-cast network operations of Tinsman. This would allow for the requested content to be routed to the appropriate intermediary with the most efficient distance to the requestor. See paragraph: 0003, lines 1 – 6 of Tinsman.
As per claim 2. Lewis does teach the method of claim 1, wherein the top level index comprises location information enabling retrieval of each of the plurality of streams [Lewis, Figure # 1, and paragraph: 0018, lines 1 – 5, Media player application 156 may then interpret manifest file 157 to playback video content on display 160. For example, manifest file 157 may reference live video segments 175 and ad video segments 145 on servers hosted in content delivery network 135, accessible over network 130].
As per claim 3. Lewis does teach the method of claim 1, wherein each stream in the plurality of alternative streams is stored in a separate container file [Lewis, Figure # 1, and paragraph: 0018, lines 1 – 5, Media player application 156 may then interpret manifest file 157 to playback video content on display 160. For example, manifest file 157 may reference live video segments 175 and ad video segments 145 on servers hosted in content delivery network 135, accessible over network 130].
As per claim 4. Lewis does teach the method of claim 1 further comprising, in response to the received request, providing the playback device with a playback location in the piece of content from a previous play event [Lewis, paragraph: 0018, lines 10 -14, As camera rig 185 captures new live footage and live video encoder 170 adds new segments to live video segments 175, media player application 156 can periodically request an updated manifest file 157 from dynamic manifest file server 110.].
As per claim 10. Lewis does teach the method of claim 1, wherein the request comprises a product identifier that describes the specific playback device [Lewis, paragraph: 0037, lines 1 – 16, Referring to step 420 of flowchart 400 in FIG. 4 and diagram 100 of FIG. 1, step 420 of flowchart 400 comprises processor 111 of dynamic manifest file server 110 passing parameters from the request received in step 410 to rule resolution server 120, which may then evaluate a plurality of rules for the live event requested in step 410. Thus, parameter data from the HTTP GET request and other platform parameters of client device 150 that may be retrieved automatically, such as by scripting, or voluntarily, such as from user form data, may all be passed to rule resolution server 120 for further evaluation. These parameters may include details such as the client IP address, browser or operating platform, device identifiers, browser cookies or login details, screen resolution of display 160, and other device, display, or user parameters, which may then be evaluated against a plurality of rules as applied to live video segments 175].
As per claim 12. Lewis does teach the method of claim 1, wherein the plurality of content characteristics of each stream further comprises a name of a file containing at least one of the plurality of alternative streams [Lewis, paragraph: 0018, lines 6 – 7, manifest file 157 may comprise a playlist file such as a M3U8 playlist file.].
As per claim 13. Lewis does teach the method of claim 1, wherein the top level index further comprises information identifying at least one content delivery network [Lewis, Figure # 1, and paragraph: 0018, lines 1 – 5, Media player application 156 may then interpret manifest file 157 to playback video content on display 160. For example, manifest file 157 may reference live video segments 175 and ad video segments 145 on servers hosted in content delivery network 135, accessible over network 130].
As per claim 14. Lewis does teach the method of claim 1, wherein the plurality of alternative streams are video streams and the plurality of characteristics of the video streams described by the top level index comprises characteristics selected from the group consisting of a maximum bitrate, a frame rate, a resolution [Lewis, Figure # 4, and paragraph: 0037, lines 1 – 16, Referring to step 420 of flowchart 400 in FIG. 4 and diagram 100 of FIG. 1, step 420 of flowchart 400 comprises processor 111 of dynamic manifest file server 110 passing parameters from the request received in step 410 to rule resolution server 120, which may then evaluate a plurality of rules for the live event requested in step 410. Thus, parameter data from the HTTP GET request and other platform parameters of client device 150 that may be retrieved automatically, such as by scripting, or voluntarily, such as from user form data, may all be passed to rule resolution server 120 for further evaluation. These parameters may include details such as the client IP address, browser or operating platform, device identifiers, browser cookies or login details, screen resolution of display 160, and other device, display, or user parameters, which may then be evaluated against a plurality of rules as applied to live video segments 175.], and a sample aspect ratio.
As per claim 17. Lewis does teach the method of claim 1, wherein the request comprises at least one information selected from the group consisting of: a playback capability of the playback device, a user account to which the playback device is registered, and geographic location information associated with the playback device [Lewis, paragraph: 0037, lines 1 – 16, Referring to step 420 of flowchart 400 in FIG. 4 and diagram 100 of FIG. 1, step 420 of flowchart 400 comprises processor 111 of dynamic manifest file server 110 passing parameters from the request received in step 410 to rule resolution server 120, which may then evaluate a plurality of rules for the live event requested in step 410. Thus, parameter data from the HTTP GET request and other platform parameters of client device 150 that may be retrieved automatically, such as by scripting, or voluntarily, such as from user form data, may all be passed to rule resolution server 120 for further evaluation. These parameters may include details such as the client IP address,].
As per claim 18. Lewis does teach the method of claim 17, wherein the geographic location information comprises at least one Internet Protocol (IP) address of the playback device [Lewis, paragraph: 0037, lines 1 – 16, Referring to step 420 of flowchart 400 in FIG. 4 and diagram 100 of FIG. 1, step 420 of flowchart 400 comprises processor 111 of dynamic manifest file server 110 passing parameters from the request received in step 410 to rule resolution server 120, which may then evaluate a plurality of rules for the live event requested in step 410. Thus, parameter data from the HTTP GET request and other platform parameters of client device 150 that may be retrieved automatically, such as by scripting, or voluntarily, such as from user form data, may all be passed to rule resolution server 120 for further evaluation. These parameters may include details such as the client IP address, browser or operating platform, device identifiers, browser cookies or login details, screen resolution of display 160, and other device, display, or user parameters, which may then be evaluated against a plurality of rules as applied to live video segments 175].
As per claim 21. Lewis does teach the method of claim 1, wherein the plurality of characteristics includes at least one characteristic selected from the group consisting of a language, a maximum bitrate, a frame rate, a resolution [Lewis, paragraph: 0037, lines 1 – 16, Referring to step 420 of flowchart 400 in FIG. 4 and diagram 100 of FIG. 1, step 420 of flowchart 400 comprises processor 111 of dynamic manifest file server 110 passing parameters from the request received in step 410 to rule resolution server 120, which may then evaluate a plurality of rules for the live event requested in step 410. Thus, parameter data from the HTTP GET request and other platform parameters of client device 150 that may be retrieved automatically, such as by scripting, or voluntarily, such as from user form data, may all be passed to rule resolution server 120 for further evaluation. These parameters may include details such as the client IP address, browser or operating platform, device identifiers, browser cookies or login details, screen resolution of display 160, and other device, display, or user parameters, which may then be evaluated against a plurality of rules as applied to live video segments 175], a format and a sample aspect ratio.
As per claim 24. Lewis does teach the method of claim 1, wherein the playback device is permitted to playback the alternative stream when the specific capabilities of the playback device satisfy at least one predetermined criterion related to the particular characteristics of the set of alternative streams [paragraph: 0027, 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. Processed video segments 315a may be encoded from stored video segments 375, and may be resized and cropped according to resolution rule set 322b to optimally fit the 800 by 480 resolution provided by display 360a. Thus, when client device 350a requests video content represented by stored video segments 375, dynamic manifest file server 310 may provide manifest file 357a in the Flash Zeri HTTP streaming format for facilitated playback by Flash Player plugin 356a. Flash Player plugin 356a may then access the referenced video content in processed video segments 315a over network 330 via content delivery network 335.
Then further of Lewis at paragraph: 0028, 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. Processed video segments 315b may be encoded from stored video segments 375, and may be resized and cropped according to resolution rule set 322b to optimally fit the 960 by 640 resolution provided by display 360b. Thus, when client device 350b requests video content represented by stored video segments 375, dynamic manifest file server 310 may provide manifest file 357b in the HTTP Live Streaming format for facilitated playback by HLS client 356b. HLS client 356b may then access the referenced video content in processed video segments 315b over network 330 via content delivery network 335.
Then further of Lewis at paragraph: 0029, Moving to client device 350c, platform rule set 322a may dictate that if a request originates from a set top box running a native binary application, then dynamic manifest file server 310 should preferably generate a M3U8 manifest file, or manifest file 357c, referencing MPEG transport stream video files, or processed video segments 315c. Processed video segments 315c may be encoded from stored video segments 375, and may be resized and cropped to optimally fit the 1280 by 720 resolution provided by display 360c. Thus, when client device 350c requests video content represented by stored video segments 375, dynamic manifest file server 310 may provide manifest file 357c as a standard M3U8 playlist for facilitated playback by native binary application 356c. Native binary application 356c may then access the referenced video content in processed video segments 315c over network 330 via content delivery network 335.
Then further of Lewis at paragraph: 0030, Thus, dynamic manifest file 310 and rule resolution server 320 may target specific client platforms to provide the optimal format for the manifest files and the processed video segments, and may also resize and process video for the best appearance on the specific display for each client device. While display resolution is shown as one example display parameter, other display parameters may also be considered such as color space or gamut, color bit-depth, refresh rate, and other parameters. Thus, as one example, rule resolution server 320 may include a color space conversion rule to adjust video colors to the color space of a targeted display. Another example rule may comprise a framerate conversion rule converting video framerates to adjust to specific refresh rates of a targeted display, or down sampling three-dimensional stereoscopic video intended for three-dimensional displays into two-dimensional video for standard two-dimensional displays. To provide faster response time for client devices, video for the most common client configurations may be pre-processed and cached in advance. Additionally, multiple bit-rate streams may be encoded and referenced in the generated manifest files to allow graceful degradation to lower bit-rate video in response to adverse network conditions].
Claim[s] 5 is/are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Lewis et al. [US PGPUB # 2021/0047542] in view of Tinsman [US PGPUB # 2011/0255535] as applied in the rejection of claim 4 above, further in view of Kobayashi [US PGPUB # 2013/0007072]
As per claim 5. Lewis and Tinsman do teach what is taught in the rejection of claim 4 above.
Lewis and Tinsman do not clearly teach the method of claim 4 further comprising receiving an event report from a different playback device, wherein the event report comprises the playback location.
However, Kobayashi does teach the method of claim 4 further comprising receiving an event report from a different playback device, wherein the event report comprises the playback location [paragraph: 0011, lines 5 – 9].
It would have been obvious to one of ordinary skilled in the art at the time of the claimed invention to combine the teachings of Lewis and Kobayashi in order for the generating of the dynamic manifest file in response to a request by the user-client to access video content of a provider of Lewis to include the provider being able to assess the capabilities of the user-client device of Kobayashi. This would allow for the content provider to distribute content to the playback devices capabilities of the user – client device even when provider doesn’t have the necessary formatting for the specific user – client device, so the provider can provide such content to the user – client device. See paragraph: 0016 of Kobayashi.
Claim[s] 11 is/are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Lewis et al. [US PGPUB # 2021/0047542] in view of Tinsman [US PGPUB # 2011/0255535] as applied in the rejection of claim 10, further in view of Avkarogullari et al. [US PGPUB # 2009/01877957], hereinafter Avk.
As per claim 11. Lewis and Tinsman do teach what is taught in the rejection of claim 10 above.
Lewis and Tinsman do not clearly teach the method of claim 10 further comprising:
maintaining a database of product identifiers and associated device capabilities; and
utilizing the product identifier of the request from the playback device to retrieve at least one device capability.
However, Avk does teach the method of claim 10 further comprising:
maintaining a database of product identifiers and associated device capabilities [Avk, paragraph: 0033, lines 1 — 7, When a user of the host device 106 visits the online media store 102 to browse or search and then purchase a media item, the online media store 102 can process a purchase (or rental) for the media item [i.e. applicant's product identifier]. Then, the associated electronic file for the purchased media item can be downloaded from a media repository 108 to the host computer 106 via the network 104. For example, the media repository can store a plurality of media items that are available on the online media store 102. In one embodiment, one or more of the media items can be stored in the media repository 108 using a multi-part media item file 110. In such case, the multi-part media item file 110 can be downloaded to the host device 106 via the network 104. Thereafter, at the host device 106, the multi-part media item file 110 can be stored and utilized for presentation (e.g., playback) of the associated media item at the host device 106. Additionally, if the host device 106 is also configured to manage media items for one or more of the media presentation devices 112, 114 or 116, the host device 106 can also download the multi- part media item file (MPMIF) 110 to one or more of the media presentation devices 112, 114 or 116. However, as discussed in more detail below, given the media playback capabilities at the particular media presentation devices 112, 114 and 116, the host device 106 may download only a subset of the multi-part media item file 110 to a particular media presentation device]; and
utilizing the product identifier of the request from the playback device to retrieve at least one device capability [Avk, paragraph: 0010, lines 1 — 4, As a method of distributing media item data to a media playback device, one embodiment of the invention can, for example, include at least: determining capabilities of the media playback device; determining a set of parts of a media item having a multi-part format based on the capabilities of the media playback device].
It would have been obvious to one of ordinary skilled in the art at the time of the claimed invention to combine the teachings of Lewis as modified and Avk in order for the generating of the dynamic manifest file in response to a request by the user-client to access video content of a provider of Lewis as modified to include assessing by the provider server - the capabilities of the user – client’s before distributing video assets to the user – client’s of Avk. This would allow for the efficient use of the bandwidth that is needed to stream the video asset to the specific type of user – client device. See paragraph: 0037, lines 15 — 19 of Avk.
Claim[s] 15, 16 is/are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Lewis et al. [US PGPUB # 2021/0047542] in view of Tinsman [US PGPUB # 2011/0255535] as applied in the rejection of claim 1 above, further in view of Sloo et al. [US PGPUB # 2007/0074254]
As per claim 15. Lewis and Tinsman do teach what is taught in the rejection of claim 1 above.
Lewis and Tinsman do not clearly teach the method of claim 1, wherein the filtered information further comprises a set of one or more audio streams and the top-level index describes a plurality of characteristics of each of the set of one or more audio streams, where the plurality of characteristics comprises at least one characteristic from the group consisting of a language, an encoding, and a bandwidth requirements.
However, Sloo does teach the method of claim 1, wherein the filtered information further comprises a set of one or more audio streams and the top level index describes a plurality of characteristics of each of the set of one or more audio streams, where the plurality of characteristics comprises at least one characteristic from the group consisting of a language [Figure # 3, and paragraph: 0027, lines 1 — 6, and lines 8 - 10, the media descriptor 300 is a multi - field database record. When a query is made of one or more categories, all media descriptors matching the query are returned. Then at paragraph: 0026, lines 1 - 9, each media asset that is available from the content provider or other provider has an associated media descriptor. The media descriptor contains various metadata that is able to identify or characterize the media asset], an encoding, and a bandwidth requirements.
It would have been obvious to one of ordinary skilled in the art at the time of the claimed invention to combine the teachings of Lewis as modified and Sloo in order for the generating of the dynamic manifest file in response to a request by the user-client to access video content of a provider of Lewis as modified to include a provider defined filtering instructions transposed into search terms to look for video items stored at the diversified media servers of the content provider of Sloo. This would allow for the provider to locate the desired content in a faster more efficient media environment. See paragraph: 0025, lines 3 - 5 of Sloo.
As per claim 16. Lewis as modified does teach the method of claim 1, wherein the filtered information further comprises a set of one or more subtitle streams and the top level index describes a plurality of characteristics of each of the set of one or more subtitle streams, where the plurality of characteristics comprises at least one characteristic selected from the group consisting of a language [Sloo, Figure # 3, and paragraph: 0027, lines 1 — 6, and lines 8 - 10, the media descriptor 300 is a multi - field database record. When a query is made of one or more categories, all media descriptors matching the query are returned. Then further of Sloo, at paragraph: 0026, lines 1 - 9, each media asset that is available from the content provider or other provider has an associated media descriptor. The media descriptor contains various metadata that is able to identify or characterize the media asset], an encoding, and a bandwidth requirement.
Claim[s] 19 is/are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Lewis et al. [US PGPUB # 2021/0047542] in view of Tinsman [US PGPUB # 2011/0255535] as applied in the rejection claim 1 above, further in view of Nair et al. [US PAT # 7177818]
As per claim 19. Lewis and Tinsman do teach what is taught in the rejection of claim 1 above.
Lewis and Tinsman do not clearly teach the method of claim 1, wherein the top-level index comprises an XML string for each stream in the plurality of alternative streams.
However, Nair does teach the method of claim 1, wherein the top-level index comprises an XML string for each stream in the plurality of alternative streams [Col. 13, lines 8- 11, and lines 17 - 20, once the item information has been arranged, the base server 76 includes the URL or universal resource locator link of the e-commerce website from which the particular item reported from the website. Then the base server 76 reports the requested items or information by creating a webpage in XML to display all the of the item information].
It would have been obvious to one of ordinary skilled in the art at the time of the claimed invention to combine the teachings of Lewis as modified and Nair in order for the generating of the dynamic manifest file in response to a request by the user-client to access video content of a provider of Lewis as modified to include receiving the video - content of the provider to be reported to the user of the user – client device from a provider media server in an display screen format of Nair. This would allow for formatting the video - content information in a suitable application format that is compatible with the user – client display device screen that the user is using to view the video - content information on the user – client device. See Col. 6, lines 15 - 19 Nair.
Claim[s] 20 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable Lewis et al. [US PGPUB # 2021/0047542] in view of Tinsman [US PGPUB # 2011/0255535], further in view of Nair et al. [US PAT # 7177818]
As per claim 20. Lewis does teach a method of dynamically generating a top-level index file customized to capabilities of a particular type of device [Lewis, paragraph: 0014, lines 1 – 3, The present application is directed to a system and method for rule-based dynamic server-side streaming manifest files], comprising:
receiving, at a playback server system, a request for a top-level index from a playback device where the request identifies [Lewis, Figure # 1, and 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] specific capabilities of the playback device [Lewis, Figure # 4, and paragraph: 0037, lines 1 – 16, Referring to step 420 of flowchart 400 in FIG. 4 and diagram 100 of FIG. 1, step 420 of flowchart 400 comprises processor 111 of dynamic manifest file server 110 passing parameters from the request received in step 410 to rule resolution server 120, which may then evaluate a plurality of rules for the live event requested in step 410. Thus, parameter data from the HTTP GET request and other platform parameters of client device 150 that may be retrieved automatically, such as by scripting, or voluntarily, such as from user form data, may all be passed to rule resolution server 120 for further evaluation. These parameters may include details such as the client IP address, browser or operating platform, device identifiers, browser cookies or login details, screen resolution of display 160, and other device, display, or user parameters, which may then be evaluated against a plurality of rules as applied to live video segments 175.];
retrieving, by the playback server system, information concerning a set of alternative streams [Lewis, Figure # 1, and paragraph: 0018, lines 1 – 5, Media player application 156 may then interpret manifest file 157 to playback video content on display 160. For example, manifest file 157 may reference live video segments 175 and ad video segments 145 on servers hosted in content delivery network 135, accessible over network 130] where:
the playback server system is capable of receiving requests from a plurality of different types of playback devices that each have different playback capabilities [Lewis, Figures 1, 2, and paragraph: 0026, lines 1 – 4, 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.
Where further of Lewis, at Figure # 3, and paragraph: 0026, lines 5 – 9, 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];
the playback device is a specific type of playback device and the plurality of different types of playback devices includes the specific type of the playback device [Lewis, Figure # 3, and paragraph: 0026, lines 5 – 9, 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];
the set of alternative streams can be utilized to perform adaptive bitrate streaming [Lewis at paragraph: 0030, lines 19 – 22, Additionally, multiple bit-rate streams may be encoded and referenced in the generated manifest files to allow graceful degradation to lower bit-rate video in response to adverse network conditions]; and
each stream in the set of alternative streams encodes a piece of content at a different bitrate [Lewis, paragraph: 0021, As previously discussed, media files may be encoded and segmented into fragment files of a fixed length to facilitate integration with streaming platforms. Thus, as shown in FIG. 2, live video segments 275 may be prepared as successive ten second segments, shown as segments 276a through 276e. Similarly, ad video segments 245 are also prepared as three ten second segments, or segments 246a through 246c, which may comprise one complete thirty second commercial. As additional live footage is recorded and encoded into new segments, the new segments may be appended within live video segments 275. Further of Lewis, at paragraph: 0030, lines 1 – 18, Thus, dynamic manifest file 310 and rule resolution server 320 may target specific client platforms to provide the optimal format for the manifest files and the processed video segments, and may also resize and process video for the best appearance on the specific display for each client device. While display resolution is shown as one example display parameter, other display parameters may also be considered such as color space or gamut, color bit-depth, refresh rate, and other parameters];
Where further of Lewis at paragraph: 0030, lines 19 – 22, Additionally, multiple bit-rate streams may be encoded and referenced in the generated manifest files to allow graceful degradation to lower bit-rate video in response to adverse network conditions];………..
……in response of the received request, filtering, by the playback server system, the information concerning the set of altemative streams…… based on comparison between the encoding format of the at least one stream from the set of alternative streams and the at least one supported format[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.
Then further of paragraph: 0037, lines 1 – 14, Referring to step 420 of flowchart 400 in FIG. 4 and diagram 100 of FIG. 1, step 420 of flowchart 400 comprises processor 111 of dynamic manifest file server 110 passing parameters from the request received in step 410 to rule resolution server 120, which may then evaluate a plurality of rules for the live event requested in step 410. Thus, parameter data from the HTTP GET request and other platform parameters of client device 150 that may be retrieved automatically, such as by scripting, or voluntarily, such as from user form data, may all be passed to rule resolution server 120 for further evaluation. These parameters may include details such as the client IP address, browser or operating platform, device identifiers, browser cookies or login details, screen resolution of display 160, and other device, display, or user parameters, which may then be evaluated against a plurality of rules as applied to live video segments 175.
Then further or Lewis, at paragraph: 0027, 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. Processed video segments 315a may be encoded from stored video segments 375, and may be resized and cropped according to resolution rule set 322b to optimally fit the 800 by 480 resolution provided by display 360a. Thus, when client device 350a requests video content represented by stored video segments 375, dynamic manifest file server 310 may provide manifest file 357a in the Flash Zeri HTTP streaming format for facilitated playback by Flash Player plugin 356a. Flash Player plugin 356a may then access the referenced video content in processed video segments 315a over network 330 via content delivery network 335.
Then further of Lewis at paragraph: 0028, 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. Processed video segments 315b may be encoded from stored video segments 375, and may be resized and cropped according to resolution rule set 322b to optimally fit the 960 by 640 resolution provided by display 360b. Thus, when client device 350b requests video content represented by stored video segments 375, dynamic manifest file server 310 may provide manifest file 357b in the HTTP Live Streaming format for facilitated playback by HLS client 356b. HLS client 356b may then access the referenced video content in processed video segments 315b over network 330 via content delivery network 335.
Then further of Lewis at paragraph: 0029, Moving to client device 350c, platform rule set 322a may dictate that if a request originates from a set top box running a native binary application, then dynamic manifest file server 310 should preferably generate a M3U8 manifest file, or manifest file 357c, referencing MPEG transport stream video files, or processed video segments 315c. Processed video segments 315c may be encoded from stored video segments 375, and may be resized and cropped to optimally fit the 1280 by 720 resolution provided by display 360c. Thus, when client device 350c requests video content represented by stored video segments 375, dynamic manifest file server 310 may provide manifest file 357c as a standard M3U8 playlist for facilitated playback by native binary application 356c. Native binary application 356c may then access the referenced video content in processed video segments 315c over network 330 via content delivery network 335.
Then further of Lewis at paragraph: 0030, Thus, dynamic manifest file 310 and rule resolution server 320 may target specific client platforms to provide the optimal format for the manifest files and the processed video segments, and may also resize and process video for the best appearance on the specific display for each client device. While display resolution is shown as one example display parameter, other display parameters may also be considered such as color space or gamut, color bit-depth, refresh rate, and other parameters. Thus, as one example, rule resolution server 320 may include a color space conversion rule to adjust video colors to the color space of a targeted display. Another example rule may comprise a framerate conversion rule converting video framerates to adjust to specific refresh rates of a targeted display, or down sampling three-dimensional stereoscopic video intended for three-dimensional displays into two-dimensional video for standard two-dimensional displays. To provide faster response time for client devices, video for the most common client configurations may be pre-processed and cached in advance. Additionally, multiple bit-rate streams may be encoded and referenced in the generated manifest files to allow graceful degradation to lower bit-rate video in response to adverse network conditions.], wherein the filtered information describes a plurality of alternative streams from the set of alternative streams [Figure # 1, and paragraph: 0018, lines 1 – 5, Media player application 156 may then interpret manifest file 157 to playback video content on display 160. For example, manifest file 157 may reference live video segments 175 and ad video segments 145 on servers hosted in content delivery network 135, accessible over network 130] and that are permitted to be played by the playback device [Lewis, paragraph: 0030, Thus, dynamic manifest file 310 and rule resolution server 320 may target specific client platforms to provide the optimal format for the manifest files and the processed video segments, and may also resize and process video for the best appearance on the specific display for each client device. While display resolution is shown as one example display parameter, other display parameters may also be considered such as color space or gamut, color bit-depth, refresh rate, and other parameters. Thus, as one example, rule resolution server 320 may include a color space conversion rule to adjust video colors to the color space of a targeted display. Another example rule may comprise a framerate conversion rule converting video framerates to adjust to specific refresh rates of a targeted display, or down sampling three-dimensional stereoscopic video intended for three-dimensional displays into two-dimensional video for standard two-dimensional displays. To provide faster response time for client devices, video for the most common client configurations may be pre-processed and cached in advance. Additionally, multiple bit-rate streams may be encoded and referenced in the generated manifest files to allow graceful degradation to lower bit-rate video in response to adverse network conditions.];
dynamically generating, at a playback server system, a top-level index customized to the specific capabilities of the playback device [Figure # 3, and paragraph: 0026, lines 5 – 9, 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.], where the customized top-level index comprises:
information describing a plurality of characteristics of each stream in the plurality of alternative streams [Lewis, Figure # 1, and paragraph: 0022, lines 1 - 3];……and
sending the dynamically generated customized top level index of the playback device using the playback server system [Lewis, Figure # 1, and 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.].
Lewis does not clearly teach…. retrieving, by the playback server system, a last playback location for the piece of content, where the last playback location for the piece of content is based upon a received event report.
…and a last playback location for the identified piece of content.
However, Nair does teach…. retrieving, at a playback server system, a last playback location for the piece of content, where the last playback location for the piece of content is based upon a received event report [Col. 13, lines 8- 11, and lines 17 - 20, once the item information has been arranged, the base server 76 includes the URL or universal resource locator link of the e-commerce website from which the particular item reported from the website. Then the base server 76 reports the requested items or information by creating a webpage in XML to display all the of the item information].
….and a last playback location for the identified piece of content [Col. 13, lines 8- 11, and lines 17 - 20, once the item information has been arranged, the base server 76 includes the URL or universal resource locator link of the e-commerce website from which the particular item reported from the website. Then the base server 76 reports the requested items or information by creating a webpage in XML to display all the of the item information].
It would have been obvious to one of ordinary skilled in the art at the time of the claimed invention to combine the teachings of Lewis as modified and Nair in order for the generating of the dynamic manifest file in response to a request by the user-client to access video content of a provider of Lewis as modified to include receiving the video - content of the provider to be reported to the user of the user – client device from a provider media server in a display screen format of Nair. This would allow for formatting the video - content information in a suitable application format that is compatible with the user – client display device screen that the user is using to view the video - content information on the user – client device. See Col. 6, lines 15 - 19 Nair.
Lewis and Nair do not clearly teach the claim limitation of “…..to remove information concerning at least one stream from the set of alternative streams that the playback device is not permitted to play back…..that can be utilized to perform adaptive bitrate streaming…”
However, Tinsman does teach the claim limitation of “…..to remove information concerning at least one stream from the set of alternative streams that the playback device is not permitted to play back…..that can be utilized to perform adaptive bitrate streaming…” [paragraph: 0207, In any of the examples regarding the router 2400 described above, some of the hierarchical data, such as either the video streams themselves, or any associated adaptive streaming manifests or similar information, may be reduced or limited before being presented to the devices. In one example, in cases mentioned above in which the router 2400 may not have access to enough communication bandwidth to transmit the video data for each requested video stream, the router 2400 may pre-emptively remove any video streams [i.e. applicant’s….to remove information….not permitted to playback] with higher data rates from the manifest that would oversubscribe the capacity of the communication link between the router 2400 and its devices. At a later time in which more bandwidth is available in the link, the router 2400 may then reintroduce the information for the higher-data-rate stream back into the manifest to make the associated video data streams available to the devices].”
It would have been obvious to one of ordinary skilled in the art at the time of the claimed invention to combine the teachings of Lewis as modified and Tinsman in order for the generating of the dynamic manifest file in response to a request by the user-client to access video content of a provider of Lewis as modified to multi-cast network operations of Tinsman. This would allow for the requested content to be routed to the appropriate intermediary with the most efficient distance to the requestor. See paragraph: 0003, lines 1 – 6 of Tinsman.
Conclusion
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, Kambiz Zand can be reached at 571- 272- 3811. 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