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 12/15/2025 have been fully considered.
Regarding claim[s] 1 – 5, 10 – 21, 23 under the various obviousness rejection, applicant's remarks are not persuasive. Therefore, the examiner will answer all remarks in the office action below.
The examiner 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] 2 of the remarks as filed: “While not believed to be required, without conceding on the merits of the rejection, and solely for the purpose of expediting prosecution, claims 1 and 20 have been amended to recite "filtering, by the playback server system, the information concerning the set of alternative streams to remove information concerning at least one stream from the set of alternative streams based on the request, wherein the filtering comprise comparing the particular characteristics of the at least one stream from the set of alternative streams and the specific playback device capabilities identified in the request, wherein the filtered information describes a plurality of alternative streams from the set of alternative streams that can be utilized to perform adaptive bitrate streaming." For the reasons set forth below, Applicant respectfully submits that the cited combination fails to teach or suggest the claimed invention and that a person of ordinary skill in the art would not have been motivated to combine the references as proposed by the Examiner.”
In response the examiner isn’t persuaded, the examiner points out that applicant's arguments against the references individually, one cannot show non-obviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
The examiner points to the prior art combination of Lewis and Tinsman (emphasis added…).
Specifically pointing to the prior art of Lewis, at 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 [i.e. applicant’s playback server system] receiving, from media player application 156 executing on processor 151 of client device 150 [i.e. applicant’s playback device], a request [i.e. applicant’s 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 Lewis, specifically, 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 [i.e. applicant’s….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 [i.e. applicant’s….specific playback capabilities identified in request ], or user parameters, which may then be evaluated against a plurality of rules as applied to live video segments 175 [i.e. applicant’s…..comparing the particular characteristics of the at least one stream from the set of alternative streams].
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 [i.e. applicant’s…. wherein the filtered information describes a plurality of alternative streams from the set of alternative streams that can be utilized to perform adaptive bitrate streaming.]
Now turning to the prior art of Tinsman, at 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 with higher data rates from the manifest that would oversubscribe the capacity of the communication link between the router 2400 and its devices [i.e. applicant’s…to remove information concerning at least one stream from the set of alternative streams..etc.]. 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.
****Putting it all together, supplementing the functionality of the router 2400 of Tinsman, the router 2400 receives multiple streams of video data at different bit rates, that can be removed to better address the capacity of the network when sending video to the devices, with the functionality of the dynamic manifest file server system 110 that receives a request from a client device for access to live web video streams thru its media player application 156 – server system 110 assess the client device’s physical parameters [i.e. client capabilities] to determine which parts of the live video segments can be displayed on the client device thru the manifest file, where the chosen live video segments for use with the client device are encode in different bit rates to accommodate various network conditions that the client device may be subject to while displaying the chosen live video segments. Thus, we arrive at applicant’s claimed and argued feature of: "filtering, by the playback server system, the information concerning the set of alternative streams to remove information concerning at least one stream from the set of alternative streams based on the request, wherein the filtering comprise comparing the particular characteristics of the at least one stream from the set of alternative streams and the specific playback device capabilities identified in the request, wherein the filtered information describes a plurality of alternative streams from the set of alternative streams that can be utilized to perform adaptive bitrate streaming."
Finally, as articulated above, when combining the teachings of the prior art, we arrive at applicant’s claimed feature of: "filtering, by the playback server system, the information concerning the set of alternative streams to remove information concerning at least one stream from the set of alternative streams based on the request, wherein the filtering comprise comparing the particular characteristics of the at least one stream from the set of alternative streams and the specific playback device capabilities identified in the request, wherein the filtered information describes a plurality of alternative streams from the set of alternative streams that can be utilized to perform adaptive bitrate streaming," which is an obvious variation of the combination of teachings of Lewis in view of Tinsman.
Applicant states on page[s] 2 – 4, of the remarks as filed: “
1. A Person of Ordinary Skill Would Not Be Motivated to Combine Tinsman's Teachings with Lewis
The Office action asserts that previously pending claim 1 is unpatentable over Lewis in view of Tinsman. The statement of rejection asserts that Lewis teaches all elements of claim 1 with the exception of "remove information concerning at least one stream from the set of alternative streams based on a comparison between the particular characteristics of the at least one stream from the set of alternative streams and the specific playback device capabilities identified in the request," but that paragraph [0207] of Tinsman discloses to "remove information concerning at least one stream that can be utilized to perform adaptive bitrate streaming." Furthermore, the Office action states that "[i]t 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 to generate a dynamic manifest file in response to a request by the user-client to access the video content of a provider of Lewis as modified to multi-cast network operations of Tinsman". Office action, p. 13-14. Applicant respectfully disagrees.
Tinsman describes multiple architectural configurations including point-to-point ([0153] to [0159]), multicast ([0160] to [0163]) and hybrid multicast and point-to-point ([0164] to [0167]). The statement of the rejection relies upon the teachings of paragraph [0207] of Tinsman, which is limited to a discussion of the configuration of a router device that is utilized in the multicast architecture to increase video delivery efficiency by preemptively removing streams at the router when the router determines that certain streams cannot be supported by the current bandwidth capacity. Tinsman does not provide any disclosure with respect to performing filtering at a playback server system, as required in claim 1. In addition, Tinsman does not disclose that there is any benefit to performing the disclosed filtering operation in a point-to-point system, such as the system described in Lewis. Furthermore, modifying the system of Lewis to utilize a multicast core network as proposed in the statement of the rejection of claim 1 would not result in a system in which the disclosed filtering operation is performed at a playback server system in Lewis. Tinsman teaches performing filtering within multicast routers, because all streams are transmitted through the core network. Therefore, modifying the system of Lewis to employ the multicast network of Tinsman would result in a system in which a filtering operation was performed in multicast routers, which do not retain information regarding "specific playback device capabilities identified in the request" and not a system in which a filtering operation is performed at a playback server system based upon the playback device's request and the "specific playback device capabilities identified in the request".
Applicant respectfully submits that the statement of the rejection of claim 1 fails to establish a prima facie case of obviousness, because the proposed combination lacks any motivation to combine the teachings of Lewis with the teachings of Tinsman in the manner proposed in the Office action. The following discussion provides an overview of the teachings of Tinsman with respect to the benefits of filtering in multicast networks and establishes that the proposed combination of Tinsman is based upon impermissible hindsight, as Tinsman's filtering teaching is inextricably tied to solving a bandwidth problem specific to its multicast core network architecture that does not exist in Lewis's point-to-point system, and Tinsman's own disclosure teaches away from applying filtering to point-to-point systems by remaining silent about filtering in its point-to-point embodiments. Furthermore, the proposed combination is impermissible on the basis that modifying Lewis' point-to-point system to become a multicast system would involve modifying its fundamental principle of operation.
In response the examiner isn’t persuaded, the functionality of the router of Tinsman would be incorporated with in the dynamic manifest file server 110 of Lewis. Both devices send and receive data based on computer program functionality (emphasis added).
Further of Lewis, at paragraph: 0016, the operation of Lewis does embody IP multicast streaming protocol. Therefore, both operations/embodiments of Tinsman and Lewis are indeed combinable in the manner articulated by the examiner based on that they both utilize multicast streaming platforms and operations. See paragraph: 0041, of Tinsman and paragraph: 0016 of Lewis.
Applicant states on page[s] 4 – 7 of the remarks as filed: “
A. A POSITA Would Not be Motivated to Combine Tinsman's Filtering in the Context of the Multicast Core Network Architecture with Lewis
Applicant respectfully submits that a POSITA would not be motivated by the specific teachings in Tinsman with respect to multicast architectures, to rely on the teachings of Tinsman to modify the system of Lewis to achieve the combination of claim 1, because Tinsman's filtering is inextricably tied to solving a problem specific to its multicast core network architecture-a problem that does not exist in Lewis's point-to- point system. Furthermore, modifying Lewis to employ a multicast core network architecture would not create a need to for the filtering process described by Tinsman to be performed at a playback server system based upon the playback device's request and the "specific playback device capabilities identified in the request". Quite the contrary, Tinsman teaches that the filtering it describes should be employed in multicast routers that do not retain any information regarding the "specific playback device capabilities identified in the request". MPEP § 2143.01 provides that there must be "some teaching, suggestion or motivation" in the teachings of the prior art to modify or combine the teachings of the prior art. MPEP § 2145 further provides that "[a] reference may be said to teach away when a person of ordinary skill, upon reading the reference, would be discouraged from following the path set out in the reference, or would be led in a direction divergent from the path that was taken by the applicant." In re Gurley, 27 F.3d 551, 553 (Fed. Cir. 1994). Additionally, MPEP § 2141.01 instructs that "a prior art reference must be considered in its entirety, i.e., as a whole, including portions that would lead away from the claimed invention." Tinsman's multicast architecture creates a specific technical problem that necessitates filtering. As paragraph [0160] explains, "The encoders 2003 encode each of these channels to a corresponding channel of encoded (hierarchical) video data 2012 for a multicast core network 2005. The multicast core network 2005 transports the hierarchical data 2012 as a multicast set 2013." In this architecture, all available streams for all channels are transmitted through the multicast core network to a multicast router. Paragraph [0165] further clarifies: "The encoder 2103 forwards the streams of video data 2112 to a multicast core network 2105, which combines the streams into a set of multicasts 2113 and transmits the multicast set 2113 to a switch/router 2104."
The fundamental efficiency principle of Tinsman's multicast architecture is that "multiple copies of encoded video data 2012 are not carried in the multicast set 2013, regardless of the number of devices 2008 requesting the same channel." This means that all streams for all channels are transmitted only once through the multicast core network to the multicast router, achieving significant bandwidth efficiency in the core network. As Tinsman explains, "network communication bandwidth need not be reserved for each device for the entirety of the connection from the multicast core network 2005 to the devices 2008 due to the multicast nature of the connection. Instead, duplicate bandwidth need only be reserved for the portion of the network that is unique to each device 2008 (sometimes termed 'the last mile')."
However, this multicast efficiency creates a tradeoff: while bandwidth is saved in
the core network by transmitting each stream only once, the router receives all streams for all channels regardless of what any individual device actually needs. This creates a bandwidth bottleneck between the router and the end devices on the "last mile" connection, which Tinsman addresses through filtering at the router device.
Paragraph [0207] teaches the filtering solution: "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 with higher data rates from the manifest that would oversubscribe the capacity of the communication link between the router 2400 and its devices." This filtering occurs at the router precisely because the multicast architecture has already delivered all streams to that point-the router must filter because it has received all streams via multicast but has limited bandwidth to transmit them to devices via point-to-point connections. As paragraph [0166] explains, "Since the multicast core network 2105 maintains the multicast set 2113 only as far as the router 2104, some significant savings in terms of communication bandwidth is achieved." The filtering is thus a direct consequence of the multicast architecture's fundamental design: transmitting all streams once to a central point (the router) to achieve core network efficiency, which then requires filtering at that central point to manage the limited last-mile bandwidth to individual devices.
In contrast, Lewis operates on an entirely different architecture that does not create this problem. Lewis utilizes a point-to-point system, and therefore there is no bandwidth bottleneck that would necessitate filtering. A person of ordinary skill in the art would recognize that Tinsman's filtering exists precisely because its multicast architecture creates a situation where all streams have been transmitted to the router but only some can be forwarded to devices, whereas Lewis's architecture avoids this situation entirely because it is a point-to-point system. Accordingly, a POSITA would not be motivated by Tinsman's specific teaching on filtering streams in a multicast system to utilizing the disclosed filtering technique in the point-to-point system of Lewis. The statement of the rejection appears to acknowledge this point and instead proposed modifying Lewis to adopt the multicast network of Tinsman. As noted above, Tinsman does not disclose using a playback server system to perform filtering based upon the playback device's request and the "specific playback device capabilities identified in the request". Instead, Tinsman performs filtering within a multicast router in a manner that is unrelated to the "specific playback device capabilities identified in the request".”
In response the examiner isn’t persuaded, the functionality of the router of Tinsman would be incorporated with in the dynamic manifest file server 110 of Lewis. Both devices send and receive data based on computer program functionality (emphasis added).
Further of Lewis, at paragraph: 0016, the operation of Lewis does embody IP multicast streaming protocol. Therefore, both operations/embodiments of Tinsman and Lewis are indeed combinable in the manner articulated by the examiner based on that they both utilize multicast streaming platforms and operations. See paragraph: 0041, of Tinsman and paragraph: 0016 of Lewis.
Applicant states on page[s] 7 - 9 of the remarks as filed: “
B. Point-to-Point System in Tinsman Does Not Disclose Filtering or Contemplate the Benefits of Filtering
Applicant acknowledges that Tinsman discloses multiple streaming system architectures, including point-to-point systems and multicast/hybrid systems. While Tinsman teaches filtering in the context of its multicast architectures, Tinsman critically does not teach performing a similar filtering process in the point-to-point systems. This selective teaching demonstrates that a POSITA would regard the teaching in Tinsman of filtering as solving an architecture-specific problem rather than as a technique that can be adaptable to obtain benefits in systems more broadly (i.e. point-to-point systems).
Tinsman describes point-to-point adaptive streaming systems with respect to Figure 19, where "the video server 1904 may provide information in the form of a 'manifest,' which indicates the various streams available for each program or channel" and "each device 1908 may request a particular stream 1914 for the next video chunk, and receive that chunk... from the video server 1904 in response." (Tinsman, [0158]).
These point-to-point systems use manifests to describe available streams, and devices select streams based on link quality and other factors-structurally similar to Lewis. Yet Tinsman does not teach or suggest filtering manifests at a playback server system based upon the playback device's request and the "specific playback device capabilities identified in the request" in these point-to-point systems. Indeed, Tinsman does not disclose any filtering of manifests anywhere within these point-to-point systems. Tinsman clearly considered point-to-point systems, but did not appreciate (or disclose) any benefit of performing filtering in point-to-point systems.
The fact that Tinsman only teaches filtering where a multicast router receives all streams highlights that the filtering process disclosed in Tinsman is solving a multicast- specific problem. A person of ordinary skill in the art, reading Tinsman in its entirety as required by MPEP § 2141.01, would understand that the disclosed filtering process is tied to the multicast architecture. Accordingly, a POSITA would not be motivated to apply the disclosed filtering process in the point-to-point system disclosed in Lewis. The statement of the rejection in the Office action appears to acknowledge that it would not be obvious to perform the filtering process described in Tinsman in a point-to-point system and instead asserts that a POSITA would be motivated to modify Lewis to incorporate a multicast system. As discussed above, such a combination does not result in the claimed invention. As is discussed further below, such a combination is also impermissible as it would render Lewis unsuitable for its intended purpose and would also involve modifying the fundamental principle of operation of the system of Lewis.”
In response the examiner isn’t persuaded, the examiner points out that
both operations/embodiments of Tinsman and Lewis are indeed combinable in the manner articulated by the examiner based on that they both utilize multicast streaming platforms and operations. See paragraph: 0041, of Tinsman and paragraph: 0016 of Lewis.
Applicant states on page[s] 10 - 12 of the remarks as filed: “
2.The Proposed Combination Would Render Lewis's Adaptive Bitrate Streaming Unsatisfactory for Its Intended Purpose
Applicant respectfully submits that the proposed combination of Lewis and
Tinsman involves modifying the fundamental principle of operation of Lewis from a point-to-point system to a multicast system. The proposed combination would require changing the server-side dynamic manifest generation system of Lewis to a multicast system with router-based manifest modification. Such extensive modifications would not only alter Lewis's fundamental principle of operation, but would also be so substantial that a person of ordinary skill in the art would have no reasonable expectation of success in making the proposed modification.
MPEP § 2143.01(VI) provides that "[i]f a 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." Additionally, MPEP § 2143.02 provides that "[e]vidence showing there was no reasonable expectation of success may support a conclusion of non-obviousness." The Office action proposes to modify Lewis "to [utilize the] multi-cast network operations of Tinsman." This proposed modification would fundamentally change Lewis's principle of operation in ways that neither cited reference teaches and for which a person of ordinary skill in the art would have no reasonable expectation of success.
Lewis and Tinsman operate on fundamentally different architectural principles.
Lewis teaches that "a client device 150 may send a request to dynamic manifest file
server 110 for live video content Dynamic manifest file server 110 may then forward
various parameters received from the request originating from client device 150 to rule
resolution server 120 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." (Lewis, [0017]). By contrast, Tinsman teaches that "[t]he encoder 2103 forwards the streams of video data 2112 to a multicast core network 2105, which combines the streams into a set of multicasts 2113 and transmits the multicast set 2113 to a switch/router 2104. The
switch/router 2104 may also receive a manifest or similar information from the video encoder 2103 via the multicast core network 2105." (Tinsman, [0165]). The router then "may forward the manifest unchanged, or may revise or otherwise modify the manifest prior to transmission to the devices." (Tinsman, [0177]). In Tinsman's architecture, manifests are generated at the encoder, transmitted via multicast to routers, and may be modified by routers. Tinsman does not teach that manifests are generated dynamically by a server in response to individual device requests. Modifying Lewis to incorporate Tinsman's multicast network operations would require fundamentally changing Lewis's server-side manifest generation system. However, Tinsman provides no teaching as to how to incorporate Lewis's server-side dynamic manifest generation system into a multicast architecture. While Tinsman describes point-to-point systems (FIG. 18-19) and multicast systems (FIG. 20-21) as distinct architectures with different operational characteristics, it does not teach or suggest how Lewis's rule-based customization could operate in an encoder-router multicast system. Neither reference provides any teaching or suggestion as to how these fundamental architectural differences could be reconciled. Moreover, Tinsman itself acknowledges the complexity of managing manifests in its multicast system. Tinsman teaches that "[a]t 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." (Tinsman, [0207]). This requirement for the router to continuously monitor conditions and update received manifests before forwarding them to specific clients adds significant complexity. Tinsman does not explain how to implement this additional required functionality in the context of Lewis's disclosure of dynamic server- side manifest generation. A person of ordinary skill in the art would face numerous technical challenges for which neither reference provides guidance. The Office action's stated motivation, which is "to allow for the requested content to be routed to the appropriate intermediary with the most efficient distance to the requestor," does not provide articulated reasoning for how to overcome these fundamental architectural incompatibilities or why a person of ordinary skill in the art would have a reasonable expectation of success in making such extensive modifications. The Office action, together with the cited references, does not explain how to restructure Lewis's entire system architecture to operate on multicast principles while maintaining its dynamic manifest generation capabilities. Such a fundamental change goes beyond the teachings of the references and would require extensive modifications for which a person of ordinary skill in the art would have no reasonable expectation of success. Accordingly, Applicant respectfully submits that the statement of the rejection fails to establish a prima facie case of obviousness on this basis alone.”
In response the examiner isn’t persuaded, the examiner points out that
both operations/embodiments of Tinsman and Lewis are indeed combinable in the manner articulated by the examiner based on that they both utilize multicast streaming platforms and operations. See paragraph: 0041, of Tinsman and paragraph: 0016 of Lewis. Therefore, the operation of Lewis would not have to be extensively modified as alleged by applicant.
Applicant states on page[s] 12 - 14 of the remarks as filed: “
3.The Cited Combination Fails to Teach Filtering Based on Comparing Stream Characteristics with Device Capabilities Identified in the Request
Applicant respectfully submits that the cited combination of Lewis and Tinsman fails to teach or suggest the claimed limitation of "filtering, by the playback server system, the information concerning the set of alternative streams to remove information concerning at least one stream from the set of alternative streams based on a comparison between the particular characteristics of the at least one stream from the set of alternative streams and the specific playback device capabilities identified in the request." Tinsman's filtering is based on router bandwidth limitations rather than on comparing stream characteristics with device capabilities. MPEP § 2143 provides that the examiner bears the initial burden of presenting a prima facie case of unpatentability, which requires the examiner to "adequately explain the rationale supporting a rejection to facilitate effective communication between the examiner and the applicant." In re Jung, 637 F.3d 1356, 1362 (Fed. Cir. 2011). The examiner must "set forth the statutory basis of the rejection and the reference or references relied upon in a sufficiently articulate and informative manner as to meet the notice requirement of [35 U.S.C. § 132]." In re Hoch, 428 F.2d 1341, 1342 n.3 (CCPA 1970). Claim 1, as amended, recites "filtering, by the playback server system, the information concerning the set of alternative streams to remove information concerning at least one stream from the set of alternative streams based on a comparison between the particular characteristics of the at least one stream from the set of alternative streams and the specific playback device capabilities identified in the request." Tinsman teaches removing video streams, but the removal is based on bandwidth limitations at the router, not on comparing stream characteristics with device capabilities. Paragraph [0207] explains that "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 with higher data rates from the manifest that would oversubscribe the capacity of the communication link between the router 2400 and its devices." This removing of streams occurs based on a determination of insufficient bandwidth at the router, and high-bitrate streams are removed to prevent oversubscription of the communication link. The router is not evaluating whether a particular device is capable of playing back a stream based on comparing the stream's characteristics against the device's capabilities. Instead, the router is simply removing streams that would exceed available bandwidth based on bitrate alone and in a manner that is independent of the specific capabilities of the playback device. Moreover, Tinsman's filtering is not based on the playback device's request. In Tinsman's system, the router makes its filtering decision based on information available at the router itself. Specifically, the available bandwidth on the communication link between the router and its devices. Paragraph [0207] states that the router removes streams when "the router 2400 may not have access to enough communication bandwidth to transmit the video data." This is information that the router determines itself by monitoring the communication link, not information that the device communicates to the router in a request. The Office action has not adequately explained how the combination teaches removing streams based on comparing stream characteristics against device capabilities identified in the request. The Office action has not shown where in the cited references, or in the combination thereof, there is a teaching or suggestion to perform the specific comparison recited in the claims-comparing particular characteristics of streams against specific device capabilities identified in a request from the device to determine which streams to remove. Accordingly, the cited combination fails to teach or suggest the claimed limitation of filtering based on a comparison between stream characteristics and device capabilities identified in the request. Applicant respectfully submits that the Office action has not met the burden of presenting a prima facie case of unpatentability with respect to this limitation, for the additional reason that the rejection does not adequately explain how the cited references teach this specific comparison.”
In response the examiner isn’t persuaded, the examiner points to the prior art of Lewis. Specifically, at 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.
Response to Amendment
Status of the instant application:
Claim[s] 1 – 5, 10 – 21, 23 are pending in the instant application.
Regarding claim[s] 1 – 5, 10 – 21, 23 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 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 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 [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 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.];
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 playback device capabilities 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
generating, by the playback server system, a top-level index, where the 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 generated 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 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 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 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], and a sample aspect ratio.
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, 23 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 generating a top-level index [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 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] 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];
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 particular characteristics of the at least one stream from the set of alternative streams and the specific playback device capabilities 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];
generating, at a playback server system, a top-level index using a playback server system, where the 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 generated 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 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 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 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 23. Lewis does teach the method of claim 20, wherein the capabilities of the playback device comprise at least one capability selected from the group consisting of:
a playback capability, a display aspect ratio, an anticipated maximum network connection data rate, a device output, a supported format, a device buffer size, a device 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 device region, and a device language.
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, 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