DETAILED ACTION
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 02/20/2026 has been entered. Claims 1-14,22-28 have been examined. Claim 15-21 are cancelled.
Response to Arguments
Applicant’s arguments, see Remarks – Pages 8-10 , filed on 02/20/2026, with respect to the rejections of claims 1,22 under 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground of rejection is made in view of Glasser.
Applicant’s arguments, see Remarks – Pages 10-11 , filed on 02/20/2026, with respect to the rejection of claim 8 under 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground of rejection is made in view of Karthikeyan.
With regards to Double Patenting (DP) rejection, the Applicant requests that this rejection be held in abeyance until the claims of the instant application are otherwise in condition for allowance – Therefore, the DP rejection is maintained.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory obviousness-type double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the conflicting application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement.
Effective January 1, 1994, a registered attorney or agent of record may sign a terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3.73(b).
Claims 1-6,22-27 are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 1-2,4,8,11,13 of Patent No. US 11,553,018 in view of Maggenti in view of Glasser
Although the conflicting claims are not identical, they are not patentably distinct from each other because:
See Analysis below:
Claims 1-6,22-27 of Instant application
Claims 1-2,4,8,11,13 of patent No. 11,553,018
Claims 1,22
A method /system comprising:
One or more processor, and memory storing instructions that , when executed by the one or more processors configure the computer device to
receiving, by a computing device and from a plurality of client devices, a plurality of requests for a content item;
determining based on common characteristics associated with the plurality of requests and the plurality of client devices one or more group of requests for the content item
selecting, for each of the groups, between multicast delivery and unicast delivery to deliver, the content item, wherein the selecting is based on:
determining that a plurality of requests older than a minimum amount of time, has satisfied a request count.
initiating, based on the selecting, a multicast delivery to deliver, to one or more of the plurality of client devices, the content item.
Claims 1,
A method/system comprising:
One or more processor, and memory storing instructions that , when executed by the one or more processors configure the computer device to
receiving, by a computing device and from a plurality of client devices, a plurality of requests for a version of a content item formatted according to a content parameter;
selecting between multicast delivery and unicast delivery to deliver, for each of the plurality of client devices, the version of the content item formatted according to the content parameter, wherein the selecting is based on:
a determination of whether a quantity of the plurality of requests satisfies a threshold;
a determination of whether network resources satisfy a threshold value; a plurality of heartbeat messages received from the plurality of client devices; and
an elapsed amount of time since one of the plurality of client devices requested the version of the content item; and
initiating, based on the selecting, a multicast delivery to deliver, to one or more of the plurality of client devices, the version of the content item formatted according to the content parameter..
Claims 2,23
after initiating the multicast delivery, monitoring network resources; and changing the multicast delivery to unicast delivery to deliver, to the one or more of the plurality of client devices and based on a determination that the network resources do not satisfy a threshold value, at least a portion of a second version of the content item.
Claim 2
after initiating the multicast delivery, monitoring the network resources; and continuing the multicast delivery to deliver, to the one or more of the plurality of client devices and based on a determination that the network resources satisfy the threshold value, the version of the content item formatted according to the content parameter.
Claims 3,24
sending, to a first subset of the plurality of client devices and via one or more multicast streams, the content item; and sending, to a second subset of the plurality of client devices and via one or more unicast streams, the content item.
Claim 13
sending, to the first subset of the plurality of client devices and via one or more multicast streams, the content item formatted according to the same parameter; and sending, to the second subset of the plurality of client devices and via one or more unicast streams, the content item.
Claims 4 ,25
wherein the multicast delivery comprises sending, to the one or more of the plurality of client devices via an Internet Protocol (IP) or a Hypertext Transfer Protocol (HTTP), the content item.
Claim 4
wherein the multicast delivery comprises sending, to the one or more of the plurality of client devices, the version of the content item, via an Internet Protocol (IP) or a Hypertext Transfer Protocol (HTTP).
Claims 5,26
wherein the initiating the multicast delivery comprises: initiating a multicast stream for the content item, wherein the multicast stream is associated with a multicast source identifier, a multicast group identifier, and a port identifier; and sending, to the one or more of the plurality of client devices, the multicast source identifier, the multicast group identifier, and the port identifier.
Claim 8
wherein the initiating the multicast delivery comprises: initiating a multicast stream for the version of the content item, wherein the multicast stream is associated with a multicast source identifier, a multicast group identifier, and a port identifier; and sending, to the one or more of the plurality of client devices, the multicast source identifier, the multicast group identifier, and the port identifier.
Claims 6,27
receiving, from a second plurality of client devices, a second plurality of requests for a second version of the content item; and initiating a unicast delivery to deliver, to each of the second plurality of client devices and based on the second plurality of requests, older than the minimum amount of time, does not satisfy the request count threshold, the second version of the content item.
Claim 11
receiving, from a second plurality of client devices, a second plurality of requests for a second version of a content item formatted according to a second content parameter; and initiating a unicast delivery to deliver, to each of the second plurality of client devices and based on a determination that a quantity of the second plurality of requests does not satisfy the threshold, the second version of the content item formatted according to the second content parameter.
With regards to claims 1, 22
The Patent No. US 11,553,018 does not explicitly teach one or more processor, and memory storing instructions that , when executed by the one or more processors configure the computer device to determining based on common characteristics associated with the plurality of requests and the plurality of client devices one or more group of requests for the content item, selecting for each of the groups, between multicast delivery and unicast delivery to deliver, the content item
However, Maggenti teaches one or more processor, and memory storing instructions that , when executed by the one or more processors configure the computer device to determining based on common characteristics associated with the plurality of requests and the plurality of client devices one or more group of requests for the content item, selecting for each of the groups, between multicast delivery and unicast delivery to deliver, the content item (¶ 0025 – ¶ 0027).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Patent No. US 11,553,018 to include to the teachings of Maggenti. The motivation for doing so is to allow the system to provide efficient data distribution to a group of users (Maggenti – Abstract).
The Patent No. US 11,553,018 teaches determining that a plurality of requests has satisfied a request count (Claim 1 – teaches determining a quantity of a plurality of requests that satisfied a threshold) . However, Patent No. US 11,553,018 does explicitly teach determining that a plurality of requests older than minimum amount of time. Glasser teaches determining that a plurality of requests older than minimum amount of time (Fig.3, ¶0028)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Patent No. US 11,553,018 to include to the teachings of Glasser. The motivation for doing so is to allow the system to provide synchronization of clients to maximize multicast opportunities (Glasser – ¶0002)
With regards to claim 6, The patent No. US 11,553,018 does not explicitly teach the second plurality of requests, older than the minimum amount of time. Glasser teaches second plurality of requests, older than the minimum amount of time (Fig.3, ¶0028)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Patent No. US 11,553,018 to include to the teachings of Glasser. The motivation for doing so is to allow the system to provide synchronization of clients to maximize multicast opportunities (Glasser – ¶0002)
Claim Objections
Claims 1,22 are objected to because of the following informalities:
With regards to claims 1,22, the claim recites “ one or more groups of requests… selecting for each of the groups….” Examiner suggests amending the claim to recite “one or more groups of requests… selecting for each of the one or more groups”. For consistency.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 8-14 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claims contain subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention.
Regarding claim 8, the claim recites “determining a quantity of multicast streams based on … a plurality of requests, older than a minimum amount time,”.
The specification does not support the claim limitation as indicated above. The closest recitation in the published specification US 2023/0216906 A1 stated:
¶0129 - the multicast controller 308 may determine an optimal amount of multicast streams for current (and/or future) network resources. This optimal amount may fluctuate in accordance with the number of requests for content, number of current multicast streams being transmitted, number of unicast streams being transmitted, characteristics of the content being transmitted (e.g., resolution, bitrate, codec, streaming format, etc.), available network resources, and the like. In some embodiments, this optimal amount of multicast streams may include the multicast streams transmitting the most popular content and/or channels, such as the most requested content and/or the most requested types of content (e.g., content requested in high definition at a high bitrate on a particular CODEC).
Therefore, the above specification does not describe “determining a quantity of multicast streams based on … a plurality of requests, older than a minimum amount time”.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1,22 are rejected under 35 U.S.C. 103 un-patentable over Maggenti et al. Publication No. US 2007/0298708 A1 (Maggenti hereinafter) in view of Glasser et al. Publication No. US 2012/0158983 A1 (Glasser hereinafter)
Regarding claim 1,
Maggenti teaches a method comprising:
receiving, by a computing device and from a plurality of client devices, a plurality of requests for a content item (Fig.3, ¶ 0050 - At block 302, one or more requests for information are received and/or detected. For example, one or more unicast requests for information are detected from one or more devices. In an embodiment, the requests are received or detected by the receiver/detector 208).
determining, based on common characteristics associated with the plurality of requests and the plurality of client devices, one or more groups of requests for the content item (¶ 0026 - the determination module 120 may perform any algorithm to determine whether the information 116 is to be broadcast. For example, the algorithm may be based on the number and/or rate of the received requests, the region of the received requests, the importance of the information, the time of the received requests, and/or any other characteristics associated with the requests or the operation of the network 112) – ¶ 0040 - the determination module 202 maintains one or more parameters that are associated with requests for the information and/or the operation of a distribution network. For example, the parameters may describe the number and/or rate of the received requests, the region of the received requests, the importance of the information being requested, the time of the received requests, and/or any other characteristics associated with the requests or the operation of the network).
selecting, for each of the groups, between multicast delivery and unicast delivery to deliver, the content item, wherein the selecting is based on: a determining that a plurality of requests [..] has satisfied a request count threshold (¶ 0025 - the determination module 120 operates to detect the received requests and to determine if the requested information is of interest to many devices. For example, in an embodiment, the determination module 120 operates to keep track of the total number of requests for the information, and if that total number exceeds a threshold value, the determination module 120 determines that the information is of interest to enough devices that it would be efficient to broadcast the information on the network 112. The broadcast threshold may be set to any value to indicate a level of interest needed to cause a broadcast to occur – ¶ 0041 - The determination module 202 operates to perform an algorithm to determine if requested information is to be broadcast based on one or more of the broadcast conditions. In an embodiment, the algorithm determines if a broadcast threshold is exceeded. For example, a parameter may describe the total number of requests received for some or all of the information 206. The determination module 202 operates to determine if the number of requests exceeds a broadcast threshold. Exceeding the threshold indicates that there are many devices interested in the information, and so the determination module 202 determines that the information is to be broadcast) ; and
initiating, based on the selecting, a multicast delivery to deliver, to one or more of the plurality of client devices, the content item (¶ 0027 Once the determination module 120 has determined that the information is to be broadcast, a broadcast module 122 at the server 110 operates to broadcast the information over a broadcast channel provided by the network 112 as shown by broadcast 124).
However, Maggenti does not explicitly teach
determining that that a plurality of requests older than a minimum amount of time
Glasser teaches
determining that that a plurality of requests older than a minimum amount of time has satisfied a request count threshold (Fig.3, ¶ 0028 - If the current time is not after the second specified time, the content delivery system can increase a count of the requests received for the content within the second specified time, ¶ 0030 - when the current time is after the second specified time, the content delivery system can determine if sufficient requests have been received to make multicast delivery more efficient than unicast delivery as illustrated at 314 – When there are a sufficient number of requests, the content delivery system can instruct the client system to join a multicast session to retrieve the content, as illustrated at 316, and the content delivery system can receive another request at 302. Alternatively, when there is not a sufficient number of requests, the content delivery system can instruct the client system to request unicast delivery of the content, as illustrated at 318- As shown in Fig.3, requests are counted and accumulated between the first time and second time and when the time passes T-1 (making the counted requests older than that time), the system execute step 314 (sufficient request) to determine if the threshold is met, and selecting multicast or unicast based on threshold).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Maggenti to include the teachings of Glasser. The motivation for doing so is to allow the system to provide synchronization of clients to maximize multicast opportunities (Glasser – ¶ 0002)
Regarding claim 22,
Maggenti teaches a computing device comprising:
one or more processors; and memory storing instructions that, when executed by the one or more processors, configure the computing device to: receiving, from a plurality of client devices, a plurality of requests for a content item; (Fig.3, ¶ 0050 - At block 302, one or more requests for information are received and/or detected. For example, one or more unicast requests for information are detected from one or more devices. In an embodiment, the requests are received or detected by the receiver/detector 208).
determine, based on common characteristics associated with the plurality of requests and the plurality of client devices, one or more groups of requests for the content item (¶ 0026 - the determination module 120 may perform any algorithm to determine whether the information 116 is to be broadcast. For example, the algorithm may be based on the number and/or rate of the received requests, the region of the received requests, the importance of the information, the time of the received requests, and/or any other characteristics associated with the requests or the operation of the network 112) – ¶ 0040 - the determination module 202 maintains one or more parameters that are associated with requests for the information and/or the operation of a distribution network. For example, the parameters may describe the number and/or rate of the received requests, the region of the received requests, the importance of the information being requested, the time of the received requests, and/or any other characteristics associated with the requests or the operation of the network).
Select, for each of the groups, between multicast delivery and unicast delivery to deliver, the content item, wherein the selecting is based on: determining that a plurality of requests [..] has satisfied a request count threshold (¶ 0025 - the determination module 120 operates to detect the received requests and to determine if the requested information is of interest to many devices. For example, in an embodiment, the determination module 120 operates to keep track of the total number of requests for the information, and if that total number exceeds a threshold value, the determination module 120 determines that the information is of interest to enough devices that it would be efficient to broadcast the information on the network 112. The broadcast threshold may be set to any value to indicate a level of interest needed to cause a broadcast to occur – ¶ 0041 - The determination module 202 operates to perform an algorithm to determine if requested information is to be broadcast based on one or more of the broadcast conditions. In an embodiment, the algorithm determines if a broadcast threshold is exceeded. For example, a parameter may describe the total number of requests received for some or all of the information 206. The determination module 202 operates to determine if the number of requests exceeds a broadcast threshold. Exceeding the threshold indicates that there are many devices interested in the information, and so the determination module 202 determines that the information is to be broadcast) ; and
initiate, based on the selecting, a multicast delivery to deliver, to one or more of the plurality of client devices, the content item (¶ 0027 Once the determination module 120 has determined that the information is to be broadcast, a broadcast module 122 at the server 110 operates to broadcast the information over a broadcast channel provided by the network 112 as shown by broadcast 124).
However, Maggenti does not explicitly teach
determining that that a plurality of requests older than a minimum amount of time
Glasser teaches
determining that that a plurality of requests older than a minimum amount of time has satisfied a request count threshold (Fig.3, ¶ 0028 - If the current time is not after the second specified time, the content delivery system can increase a count of the requests received for the content within the second specified time, ¶ 0030 - when the current time is after the second specified time, the content delivery system can determine if sufficient requests have been received to make multicast delivery more efficient than unicast delivery as illustrated at 314 – When there are a sufficient number of requests, the content delivery system can instruct the client system to join a multicast session to retrieve the content, as illustrated at 316, and the content delivery system can receive another request at 302. Alternatively, when there is not a sufficient number of requests, the content delivery system can instruct the client system to request unicast delivery of the content, as illustrated at 318- As shown in Fig.3, requests are counted and accumulated between the first time and second time and when the time passes T-1 (making the counted requests older than that time), the system execute step 314 (sufficient request) to determine if the threshold is met, and selecting multicast or unicast based on threshold).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Maggenti to include the teachings of Glasser. The motivation for doing so is to allow the system provide synchronization of clients to maximize multicast opportunities (Glasser – ¶ 0002).
Claims 2-4,6,23-25,27 are rejected under 35 U.S.C. 103 un-patentable over Maggenti in view of Glasser further in view of Gonder et al. Publication No. US 2014/0282777 A1 (Gonder hereinafter).
Regarding claim 2,
Maggenti does not explicitly teach
after initiating the multicast delivery, monitoring network resources; and changing the multicast delivery to unicast delivery to deliver, to the one or more of the plurality of client devices and based on a determination that the network resources do not satisfy a threshold value, at least a portion of a second version of the content item
However, Gonder teaches
after initiating the multicast delivery, monitoring network resources; and changing the multicast delivery to unicast delivery to deliver, to the one or more of the plurality of client devices and based on a determination that the network resources do not satisfy a threshold value, at least a portion of a second version of the content item (¶ 0154 - FIG. 4b illustrates an exemplary assembled video buffer 406 after a switch occurs ( due to network condition change, transmission error conditions, scheduled change over events, etc.). Although illustrated as a multicast to unicast switch, it is appreciated that the herein described logic applies equally to a unicast to multicast switch, the illustration of FIG. 4b is merely exemplary – Fig.4, ¶ 0155 - In the given example, the content represented by the multicast stream. A 402 and the unicast stream B 404 is the same, and it is determined that (based on current playback locations) a switch from the multicast stream A 402 to the unicast stream B 404 will occur at segment 3. – See ¶ 0171,¶ 0070).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Maggenti to include the teachings of Gonder. The motivation for doing so is to allow the system to bridge multicast to unicast, so that the total network bandwidth consumption is significantly lower than a corresponding unicast-only delivery solution, (Gonder - Abstract).
Regarding claim 3,
Maggenti further teaches
sending, to a first subset of the plurality of client devices and via one or more multicast streams, the content (¶ 0027 Once the determination module 120 has determined that the information is to be broadcast, a broadcast module 122 at the server 110 operates to broadcast the information over a broadcast channel provided by the network 112 as shown by broadcast 124)
However, Maggenti does not explicitly teach
sending, to a second subset of the plurality of client devices and via one or more unicast streams, the content item
Gonder teaches
sending, to a first subset of the plurality of client devices and via one or more multicast streams, the content item(¶ 0128 - it is determined that a multicast for delivery of the identified content does not yet exist, per step 306, it is next determined whether one should be created based on e.g., the popularity of the particular content given the most recent request therefor. The streamer 204 and/or gateway 202 may be configured to recognize conditions for programs to be designated for a multicast. In one embodiment, the conditions are pre-established in the form of one or more operator-entered business rules. Such business rules may indicate, for example, that if a threshold number of requests for particular content are received within a service group and/or during a pre-determined time period, the content may be switched into multicast delivery – ¶ 00172 - When the number reaches a predetermined threshold, the switch application 506 causes a multicast to be created, and an identifier of the content is added to the database 510. The video QAM 225 and/or CCAP entities are then charged with adding the content to a multicast. The threshold may be based on a number of requests over a given period of time, and/or may be based on a service area within which the requests are received. Other mechanisms for determining popularity of requested content may be used as well); and
sending, to a second subset of the plurality of client devices and via one or more unicast streams, the content item(¶ 0154 - FIG. 4b illustrates an exemplary assembled video buffer 406 after a switch occurs ( due to network condition change, transmission error conditions, scheduled change over events, etc.). Although illustrated as a multicast to unicast switch, it is appreciated that the herein described logic applies equally to a unicast to multicast switch, the illustration of FIG. 4b is merely exemplary – Fig.4, ¶ 0155 - In the given example, the content represented by the multicast stream. A 402 and the unicast stream B 404 is the same, and it is determined that (based on current playback locations) a switch from the multicast stream A 402 to the unicast stream B 404 will occur at segment 3. –¶ 0157 -requests for the contents of a particular file are rerouted by the gateway and, where deemed appropriate are re-written to a multicast or unicast request (such as by simply re-writing the incoming stream between the file segment markers). The mechanisms disclosed herein create a continuous or seamless stream of the segment that the client expects to receive and buffer - See ¶ 0156,0171,¶ 0070).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Maggenti to include the teachings of Gonder. The motivation for doing so is to allow the system to bridge multicast to unicast, so that the total network bandwidth consumption is significantly lower than a corresponding unicast-only delivery solution (Gonder - Abstract).
Regarding claim 4,
Maggenti does not explicitly teach
wherein the multicast delivery comprises sending, to the one or more of the plurality of client devices via an Internet Protocol (IP) or a Hypertext Transfer Protocol (HTTP), the content item
However, Gonder teaches
wherein the multicast delivery comprises sending, to the one or more of the plurality of client devices via an Internet Protocol (IP) or a Hypertext Transfer Protocol (HTTP), the content item (¶ 0165 - In this example, the client device (or video player) 107 leaves multicast A. Using the segment identification information included in the multicast stream A, the gateway 202 identifies the last good segment from multicast stream, and then uses an HTTP GET request to request the next few (one or more) segments of multicast stream B from the HTTP content server – ¶ 0166 - the gateway 202 gets the segment identification from the playlist file, and switches so as to get segments from multicast stream B from HTTP server. The gateway 202 also joins the multicast stream B).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Maggenti to include the teachings of Gonder. The motivation for doing so is to allow the system to bridge multicast to unicast, so that the total network bandwidth consumption is significantly lower than a corresponding unicast-only delivery solution, (Gonder - Abstract).
Regarding claim 6,
Maggenti in view of Glasser teaches
receiving, from a second plurality of client devices, a second plurality of requests for the [..] content item; and initiating a unicast delivery to deliver, to each of the second plurality of client devices and based on second plurality of requests, older than the minimum amount of time, does not satisfy the request count threshold, the [..] content item(Glasser - Fig.3, ¶ 0028 - If the current time is not after the second specified time, the content delivery system can increase a count of the requests received for the content within the second specified time, ¶ 0030 - when the current time is after the second specified time, the content delivery system can determine if sufficient requests have been received to make multicast delivery more efficient than unicast delivery as illustrated at 314 – When there are a sufficient number of requests, the content delivery system can instruct the client system to join a multicast session to retrieve the content, as illustrated at 316, and the content delivery system can receive another request at 302. Alternatively, when there is not a sufficient number of requests, the content delivery system can instruct the client system to request unicast delivery of the content, as illustrated at 318- As shown in Fig.3, requests are counted and accumulated between the first time and second time and when the time passes T-1 (making the counted requests older than that time), the system execute step 314 (sufficient request) to determine if the threshold is met, and selecting multicast or unicast based on threshold).
However, Maggenti in view of Glasser does not explicitly teach
receiving, from a second plurality of client devices, a second plurality of requests for a second version of the content item, initiating a unicast delivery to deliver and based on a determination that a second plurality of requests does not satisfy the request count threshold, the second version of the content item
However, Gonder teaches
receiving, from a second plurality of client devices, a second plurality of requests for a second version of the content item; and initiating a unicast delivery to deliver, to each of the second plurality of client devices and based on a determination that a second plurality of requests does not satisfy the request count threshold, the second version of the content item (¶ 0172 -¶0173 - The threshold may be based on a number of requests over a given period of time, and/or may be based on a service area within which the requests are received. Other mechanisms for determining popularity of requested content may be used as well. [0173] The operational/business rules engine 507 performs similar steps as indicated above to identify and remove content which no longer meets the requirements for multicast distribution thereof (such as when a number of requests for the content is below a given threshold) – ¶ 0129 - If, upon evaluating the request, it is determined that the identified content will not be delivered via a multicast, per step 308, it is instead delivered via unicast mechanisms to the requesting device 107. In one embodiment, the unicast delivery comprises a direct communication between the CDN 101 and the IP device 107. Alternatively, the gateway 202 may still act as a go-between for the CDN 101 – ¶ 0197 - the present disclosure may facilitate a subsequent switch to a stream of higher bitrate and/or quality when network/CPU resources improves, and a switch to a stream of lower bitrate and/or quality when network/CPU resources deteriorate).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Maggenti in view of Glasser to include the teachings of Gonder. The motivation for doing so is to allow the system to bridge multicast to unicast, so that the total network bandwidth consumption is significantly lower than a corresponding unicast-only delivery solution, (Gonder - Abstract).
Regarding claim 23,
Maggenti does not explicitly teach
after initiating the multicast delivery, monitoring network resources; and changing the multicast delivery to unicast delivery to deliver, to the one or more of the plurality of client devices and based on a determination that the network resources do not satisfy a threshold value, at least a portion of a second version of the content item
However, Gonder teaches
after initiating the multicast delivery, monitoring network resources; and changing the multicast delivery to unicast delivery to deliver, to the one or more of the plurality of client devices and based on a determination that the network resources do not satisfy a threshold value, at least a portion of a second version of the content item (¶ 0154 - FIG. 4b illustrates an exemplary assembled video buffer 406 after a switch occurs ( due to network condition change, transmission error conditions, scheduled change over events, etc.). Although illustrated as a multicast to unicast switch, it is appreciated that the herein described logic applies equally to a unicast to multicast switch, the illustration of FIG. 4b is merely exemplary – Fig.4, ¶ 0155 - In the given example, the content represented by the multicast stream. A 402 and the unicast stream B 404 is the same, and it is determined that (based on current playback locations) a switch from the multicast stream A 402 to the unicast stream B 404 will occur at segment 3. – See ¶ 0171,¶ 0070).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Maggenti to include the teachings of Gonder. The motivation for doing so is to allow the system to bridge multicast to unicast, so that the total network bandwidth consumption is significantly lower than a corresponding unicast-only delivery solution, (Gonder - Abstract).
Regarding claim 24,
Maggenti further teaches
sending, to a first subset of the plurality of client devices and via one or more multicast streams, the content (¶ 0027 Once the determination module 120 has determined that the information is to be broadcast, a broadcast module 122 at the server 110 operates to broadcast the information over a broadcast channel provided by the network 112 as shown by broadcast 124).
However, Maggenti does not explicitly teach
sending, to a second subset of the plurality of client devices and via one or more unicast streams, the content item
Gonder teaches
sending, to a first subset of the plurality of client devices and via one or more multicast streams, the content item(¶ 0128 - it is determined that a multicast for delivery of the identified content does not yet exist, per step 306, it is next determined whether one should be created based on e.g., the popularity of the particular content given the most recent request therefor. The streamer 204 and/or gateway 202 may be configured to recognize conditions for programs to be designated for a multicast. In one embodiment, the conditions are pre-established in the form of one or more operator-entered business rules. Such business rules may indicate, for example, that if a threshold number of requests for particular content are received within a service group and/or during a pre-determined time period, the content may be switched into multicast delivery – ¶ 00172 - When the number reaches a predetermined threshold, the switch application 506 causes a multicast to be created, and an identifier of the content is added to the database 510. The video QAM 225 and/or CCAP entities are then charged with adding the content to a multicast. The threshold may be based on a number of requests over a given period of time, and/or may be based on a service area within which the requests are received. Other mechanisms for determining popularity of requested content may be used as well); and
sending, to a second subset of the plurality of client devices and via one or more unicast streams, the content item(¶ 0154 - FIG. 4b illustrates an exemplary assembled video buffer 406 after a switch occurs ( due to network condition change, transmission error conditions, scheduled change over events, etc.). Although illustrated as a multicast to unicast switch, it is appreciated that the herein described logic applies equally to a unicast to multicast switch, the illustration of FIG. 4b is merely exemplary – Fig.4, ¶ 0155 - In the given example, the content represented by the multicast stream. A 402 and the unicast stream B 404 is the same, and it is determined that (based on current playback locations) a switch from the multicast stream A 402 to the unicast stream B 404 will occur at segment 3. –¶ 0157 -requests for the contents of a particular file are rerouted by the gateway and, where deemed appropriate are re-written to a multicast or unicast request (such as by simply re-writing the incoming stream between the file segment markers). The mechanisms disclosed herein create a continuous or seamless stream of the segment that the client expects to receive and buffer - See ¶ 0156,0171,¶ 0070).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Maggenti to include the teachings of Gonder. The motivation for doing so is to allow the system to bridge multicast to unicast, so that the total network bandwidth consumption is significantly lower than a corresponding unicast-only delivery solution (Gonder - Abstract).
Regarding claim 25,
Maggenti does not explicitly teach
wherein the multicast delivery comprises sending, to the one or more of the plurality of client devices via an Internet Protocol (IP) or a Hypertext Transfer Protocol (HTTP), the content item
However, Gonder teaches
wherein the multicast delivery comprises sending, to the one or more of the plurality of client devices via an Internet Protocol (IP) or a Hypertext Transfer Protocol (HTTP), the content item (¶ 0165 - In this example, the client device (or video player) 107 leaves multicast A. Using the segment identification information included in the multicast stream A, the gateway 202 identifies the last good segment from multicast stream, and then uses an HTTP GET request to request the next few (one or more) segments of multicast stream B from the HTTP content server – ¶ 0166 - the gateway 202 gets the segment identification from the playlist file, and switches so as to get segments from multicast stream B from HTTP server. The gateway 202 also joins the multicast stream B).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Maggenti to include the teachings of Gonder. The motivation for doing so is to allow the system to bridge multicast to unicast, so that the total network bandwidth consumption is significantly lower than a corresponding unicast-only delivery solution, (Gonder - Abstract).
Regarding claim 27,
Maggenti in view of Glasser teaches
receiving, from a second plurality of client devices, a second plurality of requests for the [..] content item; and initiating a unicast delivery to deliver, to each of the second plurality of client devices and based on second plurality of requests, older than the minimum amount of time, does not satisfy the request count threshold, the [..] content item(Glasser - Fig.3, ¶ 0028 - If the current time is not after the second specified time, the content delivery system can increase a count of the requests received for the content within the second specified time, ¶ 0030 - when the current time is after the second specified time, the content delivery system can determine if sufficient requests have been received to make multicast delivery more efficient than unicast delivery as illustrated at 314 – When there are a sufficient number of requests, the content delivery system can instruct the client system to join a multicast session to retrieve the content, as illustrated at 316, and the content delivery system can receive another request at 302. Alternatively, when there is not a sufficient number of requests, the content delivery system can instruct the client system to request unicast delivery of the content, as illustrated at 318- As shown in Fig.3, requests are counted and accumulated between the first time and second time and when the time passes T-1 (making the counted requests older than that time), the system execute step 314 (sufficient request) to determine if the threshold is met, and selecting multicast or unicast based on threshold).
However, Maggenti in view of Glasser does not explicitly teach
receiving, from a second plurality of client devices, a second plurality of requests for a second version of the content item, initiating a unicast delivery to deliver and based on a determination that a second plurality of requests does not satisfy the request count threshold, the second version of the content item
However, Gonder teaches
receiving, from a second plurality of client devices, a second plurality of requests for a second version of the content item; and initiating a unicast delivery to deliver, to each of the second plurality of client devices and based on a determination that a second plurality of requests does not satisfy the request count threshold, the second version of the content item (¶ 0172 -0173 - The threshold may be based on a number of requests over a given period of time, and/or may be based on a service area within which the requests are received. Other mechanisms for determining popularity of requested content may be used as well. [0173] The operational/business rules engine 507 performs similar steps as indicated above to identify and remove content which no longer meets the requirements for multicast distribution thereof (such as when a number of requests for the content is below a given threshold) – ¶ 0129 - If, upon evaluating the request, it is determined that the identified content will not be delivered via a multicast, per step 308, it is instead delivered via unicast mechanisms to the requesting device 107. In one embodiment, the unicast delivery comprises a direct communication between the CDN 101 and the IP device 107. Alternatively, the gateway 202 may still act as a go-between for the CDN 101 – ¶ 0197 - the present disclosure may facilitate a subsequent switch to a stream of higher bitrate and/or quality when network/CPU resources improves, and a switch to a stream of lower bitrate and/or quality when network/CPU resources deteriorate).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Maggenti in view of Glasser to include the teachings of Gonder. The motivation for doing so is to allow the system to bridge multicast to unicast, so that the total network bandwidth consumption is significantly lower than a corresponding unicast-only delivery solution, (Gonder - Abstract).
Claims 5,26 are rejected under 35 U.S.C. 103 un-patentable over Maggenti in view of Glasser further in view of White et al. Publication No. US 2013/0007226 A1 (White hereinafter)
Regarding claim 5,
Maggenti teaches wherein the initiating the multicast delivery comprises: initiating a multicast stream for the content item (¶ 0025-¶ 0027),
However, Maggenti does not explicitly teach
wherein the multicast stream is associated with a multicast source identifier, a multicast group identifier, and a port identifier; and sending, to the one or more of the plurality of client devices, the multicast source identifier, the multicast group identifier, and the port identifier.
White teaches
multicast stream is associated with a multicast source identifier, a multicast group identifier, and a port identifier; and sending, to the one or more of the plurality of client devices, the multicast source identifier, the multicast group identifier, and the port identifier (¶ 0087 -0088 - Multicast stream include stream ID, group address, port number, source address - The catalog message is sent periodically using a reliable multicast transport on a provisioned group address and port that the eMG opens upon initiation).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Maggenti to include the teachings of White. The motivation for doing so is to allow the system to process the message, retain the information for future use as all communication afterwards uses an identifier to communicate commands operations that the system will need to perform (¶ 0087 – White).
Regarding claim 26,
Maggenti teaches wherein the initiating the multicast delivery comprises: initiating a multicast stream for the content item (¶ 0025-¶ 0027),
However, Maggenti does not explicitly teach
wherein the multicast stream is associated with a multicast source identifier, a multicast group identifier, and a port identifier; and sending, to the one or more of the plurality of client devices, the multicast source identifier, the multicast group identifier, and the port identifier.
White teaches
multicast stream is associated with a multicast source identifier, a multicast group identifier, and a port identifier; and sending, to the one or more of the plurality of client devices, the multicast source identifier, the multicast group identifier, and the port identifier (¶ 0087 -0088 - Multicast stream include stream ID, group address, port number, source address - The catalog message is sent periodically using a reliable multicast transport on a provisioned group address and port that the eMG opens upon initiation).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Maggenti to include the teachings of White. The motivation for doing so is to allow the system to process the message, retain the information for future use as all communication afterwards uses an identifier to communicate commands operations that the system will need to perform (¶ 0087 – White).
Claims 7,28 are rejected under 35 U.S.C. 103 un-patentable over Maggenti in view of Glasser further in view of Gonder further in view of Hanks et al. Patent No. US 9,113,211 B1 ( Hanks hereinafter)
Regarding claim 7,
Maggenti does not explicitly teach
determining a quantity of multicast streams based on a quantity of requests for one or more of a plurality of content items during a time period, a quantity of current multicast streams being transmitted, a quantity of current unicast streams being transmitted, and available network resources; and initiating, based on the determined quantity of multicast streams, a multicast delivery to deliver a subset of the plurality of content items
However, Gonder teaches
determining a quantity of multicast streams based on a quantity of requests for one or more of a plurality of content items during a time period, a quantity of current multicast streams being transmitted, [..]and available network resources; and initiating, based on the determined quantity of multicast streams, a multicast delivery to deliver a subset of the plurality of content items ( ¶ 0067 - when a multicast has not been previously established, a network edge device determines whether the content is to be provided via a multicast. The determination may be based in one implementation on a current number of requests, historical patterns, and/or the identity of the particular content (and/or the 7content provider) – ¶ 0068 - In the instance that the content is not to be provided as a multicast, the requesting device receives the content as a unicast stream from a unicast server. In the instance the content is to be provided as a multicast, the edge device generates in one implementation a single program transport stream (SPTS) including the identified content. The identified content is then switched into delivery on available QAM dedicated to the multicast delivery of IP packetized content and delivered via a multi-program transport stream. ¶ 0107 - the edge streamer 204 allocates an amount of the QAM spectrum based on overall capacity and/or historical use information i.e., information relating to the use of the IP multicast allocated bandwidth in the past. In addition, the edge streamer 204 may take into account the historical and/or current requests for and bandwidth utilized by each of unicast IP content delivery, multicast IP content delivery, and non-IP content delivery. In one particular example, one QAM is identified for the delivery of multicast IP content. The allocated QAM is used to set up SDV-like video sessions of the requested ABR streamer 204 multicast SPTS, and an MPTS that is broadcast on the plant is generated for delivery on the allocated and remaining QAM).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Maggenti to include the teachings of Gonder. The motivation for doing so is to allow the system to bridge multicast to unicast, so that the total network bandwidth consumption is significantly lower than a corresponding unicast-only delivery solution, (Gonder - Abstract).
Maggenti in view of Gonder does not explicitly teach
determining a quantity of multicast streams based a quantity of current unicast streams being transmitted
However, Hanks teaches
determining a quantity of multicast streams based a quantity of current unicast streams being transmitted (Abstract - a skewing window associated
with multiple unicast video streams for a video can be identified using a maximum skewing rate and a program duration, and a multicast stream for the video can be generated based on the skewing window. The unicast video streams can then be skewed and merged with the multicast stream -Fig.8, Col.6, lines 10-70 - At stage 820, multicast streams can be generated based on the skewing window. The multicast streams can be generated, for example, by the video server (e.g., VoD server 145, streaming media source 180, or source 150). In other 15 examples, the multicast streams can be generated by a multicast server. In various implementations, the number of multicast streams generated can be modified based upon design considerations. A multicast for each half skewing window results in lower savings but achieves efficiencies more quickly, since unicast videos require less skewing to merge into the half-skew multicast streams. Moreover, in a hybrid approach, the half-skewing multicast streams can 25 be supplemented by quarter-skew multicasts into which the unicast streams are merged, and which themselves are gradually merged into the half-skew multicast streams. the unicast streams are skewed into the multicast streams. The unicast streams can be skewed into the multicast streams).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Maggenti in view of Gondi to include to the teachings of Hanks. The motivation for doing so is to allow the system to consolidate unicast videos streams into multicast video streams ( Abstract – Hanks).
Regarding claim 28,
Maggenti does not explicitly teach
determining a quantity of multicast streams based on a quantity of requests for one or more of a plurality of content items during a time period, a quantity of current multicast streams being transmitted, a quantity of current unicast streams being transmitted, and available network resources; and initiating, based on the determined quantity of multicast streams, a multicast delivery to deliver a subset of the plurality of content items
However, Gonder teaches
determining a quantity of multicast streams based on a quantity of requests for one or more of a plurality of content items during a time period, a quantity of current multicast streams being transmitted, [..]and available network resources; and initiating, based on the determined quantity of multicast streams, a multicast delivery to deliver a subset of the plurality of content items ( ¶ 0067 - when a multicast has not been previously established, a network edge device determines whether the content is to be provided via a multicast. The determination may be based in one implementation on a current number of requests, historical patterns, and/or the identity of the particular content (and/or the 7content provider) – ¶ 0068 - In the instance that the content is not to be provided as a multicast, the requesting device receives the content as a unicast stream from a unicast server. In the instance the content is to be provided as a multicast, the edge device generates in one implementation a single program transport stream (SPTS) including the identified content. The identified content is then switched into delivery on available QAM dedicated to the multicast delivery of IP packetized content and delivered via a multi-program transport stream. ¶ 0107 - the edge streamer 204 allocates an amount of the QAM spectrum based on overall capacity and/or historical use information i.e., information relating to the use of the IP multicast allocated bandwidth in the past. In addition, the edge streamer 204 may take into account the historical and/or current requests for and bandwidth utilized by each of unicast IP content delivery, multicast IP content delivery, and non-IP content delivery. In one particular example, one QAM is identified for the delivery of multicast IP content. The allocated QAM is used to set up SDV-like video sessions of the requested ABR streamer 204 multicast SPTS, and an MPTS that is broadcast on the plant is generated for delivery on the allocated and remaining QAM).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Maggenti to include the teachings of Gonder. The motivation for doing so is to allow the system to bridge multicast to unicast, so that the total network bandwidth consumption is significantly lower than a corresponding unicast-only delivery solution, (Gonder - Abstract).
Maggenti in view of Gonder does not explicitly teach
determining a quantity of multicast streams based a quantity of current unicast streams being transmitted
However, Hanks teaches
determining a quantity of multicast streams based a quantity of current unicast streams being transmitted (Abstract - a skewing window associated
with multiple unicast video streams for a video can be identified using a maximum skewing rate and a program duration, and a multicast stream for the video can be generated based on the skewing window. The unicast video streams can then be skewed and merged with the multicast stream -Fig.8, Col.6, lines 10-70 - At stage 820, multicast streams can be generated based on the skewing window. The multicast streams can be generated, for example, by the video server (e.g., VoD server 145, streaming media source 180, or source 150). In other 15 examples, the multicast streams can be generated by a multicast server. In various implementations, the number of multicast streams generated can be modified based upon design considerations. A multicast for each half skewing window results in lower savings but achieves efficiencies more quickly, since unicast videos require less skewing to merge into the half-skew multicast streams. Moreover, in a hybrid approach, the half-skewing multicast streams can 25 be supplemented by quarter-skew multicasts into which the unicast streams are merged, and which themselves are gradually merged into the half-skew multicast streams. the unicast streams are skewed into the multicast streams. The unicast streams can be skewed into the multicast streams).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Maggenti in view of Gondi to include to the teachings of Hanks. The motivation for doing so is to allow the system to consolidate unicast videos streams into multicast video streams ( Abstract – Hanks).
Claims 8-11,14 is rejected under 35 U.S.C. 103 un-patentable over Gonder in view of Hanks further in view of Karthikeyan et al. Publication No. US 2016/0142789 A1 ( Karthikeyan hereinafter)
Regarding claim 8,
Gonder further teaches a method comprising:
receiving, by a computing device and from a plurality of client devices, a plurality of requests for a plurality of content items(¶ 0109 -when a particular device 107 requests particular IP packetized content, the request is evaluated by the gateway 202. The gateway 202 evaluates the request against a known set of available multicast ( or broadcast, etc.) IP streams and either joins an existing multicast or enables the requesting device to establish a unicast session with the network – ¶ 0111 -as more clients requests the same video content, the system may instruct more gateways to join the multicast stream and thus save network bandwidth from the video source to these gateway apparatus See Also ¶ 0112)
determining a quantity of multicast streams based on a quantity of requests for one or more of the plurality of content items during a time period, a quantity of current multicast streams being transmitted, [..] and available network resources( ¶ 0067 - when a multicast has not been previously established, a network edge device ( or other network entity) determines whether the content is to be provided via a multicast. The determination may be based in one implementation on a current number of requests, historical patterns, and/or the identity of the particular content (and/or the 7content provider) – ¶ 0107 - the edge streamer 204 allocates an amount of the QAM spectrum based on overall capacity and/or historical use information i.e., information relating to the use of the IP multicast allocated bandwidth in the past. In addition, the edge streamer 204 may take into account the historical and/or current requests for and bandwidth utilized by each of unicast IP content delivery, multicast IP content delivery, and non-IP content delivery. In one particular example, one QAM is identified for the delivery of multicast IP content. The allocated QAM is used to set up SDV-like video sessions (as discussed elsewhere herein) of the requested ABR streamer 204 multicast SPTS, and an MPTS that is broadcast on the plant is generated for delivery on the allocated and remaining QAM); and
initiating, based on the determined quantity of multicast streams, a multicast delivery to deliver, to one or more of the plurality of client devices, a subset of the plurality of content items ¶ 0154 - FIG. 4b illustrates an exemplary assembled video buffer 406 after a switch occurs ( due to network condition change, transmission error conditions, scheduled change over events, etc.). Although illustrated as a multicast to unicast switch, it is appreciated that the herein described logic applies equally to a unicast to multicast switch, the illustration of FIG. 4b is merely exemplary – Fig.4, ¶ 0155 - In the given example, the content represented by the multicast stream. A 402 and the unicast stream B 404 is the same, and it is determined that (based on current playback locations) a switch from the multicast stream A 402 to the unicast stream B 404 will occur at segment 3. –¶ 0157 -requests for the contents of a particular file are rerouted by the gateway and, where deemed appropriate are re-written to a multicast or unicast request (such as by simply re-writing the incoming stream between the file segment markers). The mechanisms disclosed herein create a continuous or seamless stream of the segment that the client expects to receive and buffer - See ¶ 0156,0171,¶ 0070).
However, Gonder does not explicitly teach
determining a quantity of multicast streams based a quantity of current unicast streams being transmitted and a plurality of requests, older than minimum amount of time
Hanks teaches
determining a quantity of multicast streams based a quantity of current unicast streams being transmitted (Abstract - a skewing window associated
with multiple unicast video streams for a video can be identified using a maximum skewing rate and a program duration, and a multicast stream for the video can be generated based on the skewing window. The unicast video streams can then be skewed and merged with the multicast stream -Fig.8, Col.6, lines 10-70 - At stage 820, multicast streams can be generated based on the skewing window. The multicast streams can be generated, for example, by the video server (e.g., VoD server 145, streaming media source 180, or source 150). In other 15 examples, the multicast streams can be generated by a multicast server. In various implementations, the number of multicast streams generated can be modified based upon design considerations. A multicast for each half skewing window results in lower savings but achieves efficiencies more quickly, since unicast videos require less skewing to merge into the half-skew multicast streams. Moreover, in a hybrid approach, the half-skewing multicast streams can 25 be supplemented by quarter-skew multicasts into which the unicast streams are merged, and which themselves are gradually merged into the half-skew multicast streams. the unicast streams are skewed into the multicast streams. The unicast streams can be skewed into the multicast streams).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Gondi to include to the teachings of Hanks. The motivation for doing so is to allow the system to consolidate unicast videos streams into multicast video streams ( Abstract – Hanks).
Karthikeyan teaches
determining quantity of multicast streams based on a plurality of requests, older than minimum amount of time (Claim1 -determining whether the content should be delivered in a multiple multicast time-shifted content delivery mode, the mode comprising delivering the piece of content using a plurality of multicast streams, the plurality of multicast streams each delivering the content with a relative time-shift between corresponding portions of the content; wherein the determination is based on at least one of; a measure of the number of requests for the content in a preceding time period – ¶ 0016 - The method can enable a system to determine whether content should be delivered using multiple time shifted multicast streams based on a number of factors, or optionally based on a combination of such factors. ¶ 0060 - If the source monitors that 11 hosts out of a small network of 20 have requested for a piece of content in the preceding time period, say 15 minutes, for content that lasts for two hours, it can trigger a multicast stream that starts from the beginning at the time of joining of the 12th host, based on a prediction that more hosts in this network might also request the same data – Note: at a determination T, the system counts requests from the preceding 15 minutes. So every counted request is older than some minimum elapsed time when a determination is occurs )
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Gonder to include the teachings of Karthikeyan. The motivation for doing so is to allow the system to enable the system to ensure content is delivered efficiently, but in accordance with current network conditions and capabilities. (Karthikeyan – Abstract).
Regarding claim 9,
Gonder further teaches
wherein the intuiting the multicast delivery comprises initiating a multicast delivery to deliver only the most requested content item of the plurality of content items (¶ 0128 Alternatively, if it is determined that a multicast for delivery of the identified content does not yet exist, per step 306, it is next determined whether one should be created based on e.g., the popularity of the particular content given the most recent request therefor. The streamer 204 and/or gateway 202 may be configured to recognize conditions for programs to be designated for a multicast. In one embodiment, the conditions are pre-established in the form of one or more operator-entered business rules. Such business rules may indicate, for example, that if a threshold number of requests for particular content are received within a service group and/or during a pre-determined time period, the content may be switched into multicast delivery.- See ¶ 0099).
Regarding claim 10,
Gonder further teaches
wherein the determining the quantity of multicast streams is further based on characteristics of content being transmitted via multicast and unicast delivery (¶ 0128 - The streamer 204 and/or gateway 202 may be configured to recognize conditions for programs to be designated for a multicast. In one embodiment, the conditions are pre-established in the form of one or more operator-entered business rules. Such business rules may indicate, for example, that if a threshold number of requests for particular content are received within a service group and/or during a pre-determined time period, the content may be switched into multicast delivery – ¶ 0173-¶ 0174 - The operational/business rules engine 507 performs similar steps as indicated above to identify and remove content which no longer meets the requirements for multicast distribution thereof (such as when a number of requests for the content is below a given threshold). Additionally, the determination of whether to add or remove content to/from multicast delivery may be based on e.g., user designated so-called "favorite channels", most recently watched content history, and/or other live event criteria).
Regarding claim 11,
Gonder further teaches
wherein the determining the quantity of multicast streams is further based on a resolution, a bitrate, a codec, or a streaming format of content being transmitted via multicast and unicast delivery (¶ 0151 - the gateway 202 may process the multicast streams to a format capable of being rendered by the device 107. An example of variant playlist with multicast streams coexist with the unicast stream - ¶ 0196 - As noted above, the present disclosure utilizes a playlist/manifest file. In the example given below, URLs of streams of different bitrate/quality of the same content are included in a given playlist file – ¶ 0197 - the playlist file includes URLs of3 video streams of different bandwidths and resolutions. In one embodiment ( depending on available network, CPU resources, etc.) a particular client 107 may select a best quality stream it can handle from the playlist. Accordingly, the present disclosure may facilitate a subsequent switch to a stream of higher bitrate and/or quality when network/CPU resources improves, and a switch to a stream of lower bitrate and/or quality when network/CPU resources deteriorate – See Also ¶ 0198).
Regarding claim 14,
Gonder further teaches
changing, based on the determined quantity of multicast streams, from unicast delivery to multicast delivery to deliver, to one of the plurality of client devices, one of the plurality of content items(¶ 0154 - FIG. 4b illustrates an exemplary assembled video buffer 406 after a switch occurs ( due to network condition change, transmission error conditions, scheduled change over events, etc.). Although illustrated as a multicast to unicast switch, it is appreciated that the herein described logic applies equally to a unicast to multicast switch, the illustration of FIG. 4b is merely exemplary – Fig.4, ¶ 0155 - In the given example, the content represented by the multicast stream. A 402 and the unicast stream B 404 is the same, and it is determined that (based on current playback locations) a switch from the multicast stream A 402 to the unicast stream B 404 will occur at segment 3. –¶ 0157 -requests for the contents of a particular file are rerouted by the gateway and, where deemed appropriate are re-written to a multicast or unicast request (such as by simply re-writing the incoming stream between the file segment markers). The mechanisms disclosed herein create a continuous or seamless stream of the segment that the client expects to receive and buffer - See ¶ 0156,0171,¶ 0070).
Claim 12 is rejected under 35 U.S.C. 103 un-patentable over Gonder in view of Hanks further in view of Karthikeyan further in view of Guan et al. Publication No. US 2009/0175273 A1 ( Guan hereinafter).
Regarding claim 12,
Gonder does not explicitly teach
wherein the determining the quantity of multicast streams is further based on locations of multicast servers transmitting one or more multicast streams associated the multicast delivery.
However, Guan teaches
wherein the determining the quantity of multicast streams is further based on locations of multicast servers transmitting one or more multicast streams associated the multicast delivery (¶ 0041 - The MSA node learns and stores multicast stream information. [0042] The multicast stream information includes: the mapping relationship between the multicast group and the multicast source, and/or the location of the ingress node. [0043] S602: The egress node in the MPLS domain sends a query request message to the MSA node to obtain the multicast stream information; [0044] After receiving the query request message, the MSA node searches the multicast stream information storing unit. the node in the MPLS domain may send a query request message to the MSA with respect to the mapping relationship between the multicast group and the multicast source. Such request messages may be intended to query the multicast source and/or the location of the node that publishes the mapping relationship with respect to the multicast group, or intended to query the list of the multicast groups available from a multicast source with respect to the multicast source. [0046] S603: The egress node joins the multicast stream according to the multicast stream information the node).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Gonder to include the teachings of Guan The motivation for doing so is to allow the system to support dynamic implementation of multicast services, and reduces the cost of maintaining a network topology (Guan – Abstract).
Claim 13 is rejected under 35 U.S.C. 103 un-patentable over Gonder in view of Hanks further in view of Karthikeyan further in view of Tsai et al. Publication No. US 2008/0034105 A1 ( Tsai hereinafter).
Regarding claim 13,
Gonder does not explicitly teach
wherein the determining the quantity of multicast streams is further based on estimated future network resources
However, Tsai teaches
wherein the determining the quantity of multicast streams is further based on estimated future network resources ( Abstract, ¶ 022- The present and future available bandwidths of the multicast-ready routers are estimated based on input and output traffic correlations in the routers. The multicast-ready router is considered as a server configured to duplicate a stream into a plurality of sub-streams to be sent to the clients and/or unicast routers for further forwarding the sub-streams to the clients. Further, in this system, the sub-streams may be transmitted over a plurality of paths over the communication network, wherein time-space trajectories of the paths do not cross each other).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Gonder to include the teachings of Tsai The motivation for doing so is to allow the system to provide a large scale optimal exploitation of available capacities such as network bandwidths, and computing resources for content delivery , while ensuring high QoS of content delivery (Tsai – Abstract).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to YOUNES NAJI whose telephone number is (571)272-2659. The examiner can normally be reached Monday - Friday 8:30 AM -5:30 PM.
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, Oscar A Louie can be reached on (571) 270-1684. 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.
/YOUNES NAJI/Primary Examiner, Art Unit 2445
Prosecution Insights