DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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 03/30/2026 has been entered.
Response to Arguments
Applicant’s arguments with respect to claim 1 have been considered but are moot because the arguments do not apply in view of newly found reference Reznik being used in the current rejection. See the new rejection below.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1, 9, and 17 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1, 9, and 17 recite the limitation "the selected specific third-party CDN" in line 10, line 10, and line 11, respectively. There is insufficient antecedent basis for this limitation in the claim.
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, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2, 5-10, 13-18, and 21-24 are rejected under 35 U.S.C. 103 as being unpatentable over US PG Pub 2017/0353522 to Van Brandenburg (“Van”) in view of US PG Pub 2024/0333784 to Reznik (“Reznik”) and US PG Pub 2018/0241796 to Srinivasan (“Srinivasan”).
Regarding claim 1, “A method of performing mid-stream content delivery network (CDN) steering” reads on the method/system for enabling network-initiated control of streaming of segmented content from a content delivery node to at least one client (abstract) disclosed by Van and represented in Fig. 1. Van further discloses (¶0011) during streaming of the content segments, the network configuration or load distribution in the CDN may change.
As to “comprising: receiving, by a processing system in a manifest manipulator computing device, a content request from a client device that is directed to obtain content from a uniform resource locator (URL) associated with a primary on-premise CDN” Van discloses (¶0006) that a CDN control function (CDNCF) centrally manages the locations within the CDN where CDNCF controls the distribution of content to the delivery nodes and for redirecting clients to appropriate delivery nodes; (¶0093) the user of the client device selects a link to a video on a website to send a request to the CDNCF to obtain the manifest file; (¶0094) using the manifest file, client obtains the location of the segment (i.e. URL) and setup a control channel between the client device and the CDN as represented in Fig. 7.
As to “receiving, by the processing system, an event notification that indicates an issue with the primary on-premise CDN…” Van discloses (¶0090, ¶0097, ¶0105) that during the streaming process, at some point in time, the CDNCF monitors for network notifications such as overload notifications or failure notifications as represented in Fig. 7 (element 708).
As to “modifying, by the processing system, a manifest file associated with the received content request in response to receiving the event notification from the CDN decision server” Van discloses (¶0097) that when the overload/failure of the node is detected, the system sends a manifest update trigger over the control channel of the client and (¶0098, ¶0115-¶0116) the client requests and obtains updated manifest file as represented in Fig. 7 (elements 710-712) and Fig. 9 (element 911-913).
As to “wherein modifying the manifest file comprises: selecting a specific third-party CDN…based on both a determined geographical location of the client device and real-time network conditions” Van discloses (¶0130) that the system uses load information associated with delivery nodes in the CDN and the location information of the client device to select delivery nodes; (¶0085) criteria for selecting a delivery node is based on the processing load of the delivery nodes and/or contextual information associated with the client: e.g. location of the client; the system dynamically generates a manifest file, which is optimized for efficiently delivering segments to the client; (¶0146) a delivery node is selected which is geographically closest to the location of the client device.
As to “replacing URLs in the manifest file to point to the selected specific third-party CDN to ensure non-disruptive redirection during streaming” Van discloses (¶0135-¶0136) that the updated manifest file replaces the URL associated with the first delivery node with URL associated with another delivery node hosting the same segments to redirect clients to continue streaming process.
As to “sending the modified manifest file to the client device to cause the client device to obtain the requested content from the selected specific third-party CDN” Van discloses (¶0097) that when the overload/failure of the node is detected, the system sends a manifest update trigger over the control channel of the client and (¶0098, ¶0115-¶0116) the client requests and obtains updated manifest file, where (¶0116) upon receiving this manifest file, the client continues the streaming process by requesting subsequent segments from the second delivery node DN2 instead of the first delivery node DN1.
Van meets all the limitations of the claim except “receiving, by the processing system, an event notification that indicates an issue with the primary on-premise CDN from a CDN decision server, wherein the event notification includes load status information indicating a current load level of a specific edge site of the primary on-premise CDN, and wherein the processing system uses the load status information to determine whether to redirect the client device to the selected specific third-party CDN, wherein the CDN decision server monitors performance metrics of the primary on-premise CDN to detect issues.” However, Reznik discloses (¶0142-¶0145, ¶0158) that the steering server receives CDN throughput statistics providing insights into current performance levels (current load level) of each CDN; these statistics include metrics such as latency, packet loss, and data transfer rates, which help the edge steering server assess the suitability of each CDN for delivering the requested content; the edge steering server tracks statistics of an active CDN based on the player feedback regarding the quality of service, including metrics such as buffering time, video resolution, and playback stability; based on the player feedback received in real-time, the edge steering server analyzes the performance of the active CDN and compares it against predefined thresholds and quality benchmarks, and if the player reports instances of buffering or degraded video quality, indicating suboptimal performance from a current CDN, the edge steering server initiates a CDN switch to redirect traffic through an alternative CDN with better performance characteristics as represented in Figs. 4 and 7-8. Therefore, it would have been obvious to one of the ordinary skills in the art before the effective filing date of the invention to modify Van’s system by receiving notification indicating a current load level of the edge site to determine to redirect the client to another CDN as taught by Reznik in order to perform adjustment to network protocol to deliver the media content to the end users (Reznik - ¶0003).
Combination of Van and Reznik meets all the limitations of the claim except “selecting a specific third-party CDN from multiple available third-party CDNs…to ensure non-disruptive redirection during streaming.” However, Srinivasan discloses (¶0051, ¶0054) that when the system detects an issue with the current CDN, it determines if there is an alternative CDN provider available, and when multiple CDNs are available for the content, then it selects a CDN provider to receive content as represented in Figs. 7 and 8; (¶0044) switching to alternate CDN provider ensures a smooth transition between segments without the user noticing the switch. Therefore, it would have been obvious to one of the ordinary skills in the art before the effective filing date of the invention to modify Van and Reznik’s systems by selecting a CDN from multiple available CDNs as taught by Srinivasan in order to speed up and increase the uptime of web offerings by utilizing multiple CDNs which further increase their benefits (Srinivasan - ¶0007).
Regarding claim 2, “The method of claim 1, wherein modifying the manifest file associated with the received content request in response to receiving the event notification from the CDN decision server comprises replacing a URL that points to the primary on- premise CDN with a URL that points to the third-party CDN” Van discloses (¶0099, ¶0115-¶0116) that updated manifest includes a URL that is pointing to a second delivery node DN2 to continue streaming process by requesting subsequent segments from the second delivery node instead of first delivery node as represented in Fig. 9 (elements 911-913).
Regarding claim 5, “The method of claim 1, wherein receiving the event notification that indicates the issue with the primary on-premise CDN from the CDN decision server comprises receiving data about a problematic market and a specific edge site experiencing difficulties, wherein the event notification further includes an identity of the specific edge site and a nature of the issue with the specific edge site” Van discloses (¶0114, ¶0146-¶0148) that the system selects a delivery node which is geographically closest to the location of the client device; during the streaming process, the system receives a network notification, e.g. overload/failure notification, and determines that the client should be redirected to other delivery nodes, and Reznik discloses (¶0142) that the system receives CDN throughput statistics that includes metrics such as latency, packet loss, and data transfer rates associated with each of the CDNs; (¶0150) the system continuously monitors the performance metrics of the active CDN, including throughput, latency, and packet loss. If the client device detects any degradation in performance that could impact the streaming quality, such as decreased throughput or increased latency, it refers to the CDN priority order received from the steering server.
Regarding claim 6, “The method of claim 1, wherein modifying the manifest file associated with the received content request in response to receiving the event notification from the CDN decision server further comprises modifying the manifest file based on real-time network conditions and a geographical location of the client device” Van discloses (¶0114-¶0115, ¶0146-¶0148) that the system selects a delivery node which is geographically closest to the location of the client device; during the streaming process, the system receives a network notification, e.g. overload/failure notification, and determines that the client should be redirected to other delivery nodes and sends update manifest trigger; (¶0005, ¶0086) the system uses HTTP live streaming protocol.
Regarding claim 7, “The method of claim 1, further comprising using a client-to-geolocation map to select the third-party CDN based on a current geographical location of the client device, wherein the client-to-geolocation map maps client subnets to specific edge sites on the primary on-premise CDN” Van discloses (¶0114, ¶0130, ¶0146-¶0148) that the system selects a delivery node which is geographically closest to the location of the client device; (¶0130) the system uses load information associated with the delivery nodes in the CDN and the location information of the client (e.g. the IP address) in order to select delivery nodes, which are best suited for delivering (part of) the requested segments to the client, and Reznik discloses (¶0104) the system considers each of the plurality of CDNs, geographical proximity of the plurality of CDNs to the client device.
Regarding claim 8, “The method of claim 7, wherein using the client-to-geolocation map to select the third-party CDN based on the current geographical location of the client device further comprises using the client-to-geolocation map to improve a reliability of a streaming service” Van discloses (¶0130) that the system uses load information (generated by a load-balancing function) associated with the delivery nodes in the CDN and, the location information of the client in order to select delivery nodes, which are best suited for delivering the requested segments to the client.
Regarding claim 9, see rejection similar to claim 1.
Regarding claim 10, see rejection similar to claim 2.
Regarding claim 13, see rejection similar to claim 5.
Regarding claim 14, see rejection similar to claim 6.
Regarding claim 15, see rejection similar to claim 7.
Regarding claim 16, see rejection similar to claim 8.
Regarding claim 17, see rejection similar to claim 1. Furthermore, Van discloses (¶0034) that the computer program product comprising software code stored in the memory of the computer executes the above-mentioned method.
Regarding claim 18, see rejection similar to claim 2.
Regarding claim 21, see rejection similar to claim 5.
Regarding claim 22, see rejection similar to claim 6.
Regarding claim 23, see rejection similar to claim 7.
Regarding claim 24, see rejection similar to claim 8.
Claims 3-4, 11-12, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Van in view of Reznik and Srinivasan as applied to claims 1, 9, and 17 above, and further in view of US Patent 10,735,489 to Joliveau (“Joliveau”).
Regarding claim 3, combination of Van, Reznik, and Srinivasan meet all the limitations of the claim except The method of claim 1, further comprising: indicates that the issue with the primary on-premise CDN has been resolved; updating the modified manifest file in response to receiving the second event notification from the CDN decision server; and sending the updated modified manifest file to the client device to cause the client device to obtain a remaining portion of the requested content from the primary on-premise CDN.” However, Joliveau discloses (8:55-9:3; 9:29-47) that while the fragment is being received from the new CDN, if it determined that the performance of the new CDN is not better, and the performance of the prior CDN is better than the new CDN then the system switches to the prior CDN as represented in Fig. 3. Therefore, it would have been obvious to one of the ordinary skills in the art before the effective filing date of the invention to modify Van, Reznik, and Srinivasan’s systems by switching back to original CDN when performance gets better as taught by Joliveau in order to avoid selecting a lower performing CDN that will produce unreliable and lower quality playback of the media content rather than a higher performing CDN (Joliveau - 1:25-30).
Regarding claim 4, “The method of claim 1, wherein sending the modified manifest file to the client device to cause the client device to obtain the requested content from the third-party CDN comprises redirecting the client device from the primary on-premise CDN to the third-party CDN without disrupting an ongoing content stream on the client device” Van discloses (¶0099, ¶0115-¶0116) that updated manifest includes a URL that is pointing to a second delivery node DN2 to continue streaming process by requesting subsequent segments from the second delivery node instead of first delivery node, and Joliveau discloses (7:1-17; claim 13) that the request for the additional fragments from the second edge server occurs without deterioration in the playback of the media content provided by the first edge server.
Regarding claim 11, see rejection similar to claim 3.
Regarding claim 12, see rejection similar to claim 4.
Regarding claim 19, see rejection similar to claim 3.
Regarding claim 20, see rejection similar to claim 4.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PINKAL R CHOKSHI whose telephone number is (571)270-3317. The examiner can normally be reached Monday - Friday, 8am-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, BRIAN T PENDLETON can be reached at (571)272-7527. 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.
/PINKAL R CHOKSHI/Primary Examiner, Art Unit 2425
Prosecution Insights