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 .
This Office action is in response to the amendment filed on 10/27/2025.
Claims 1-20 are presented for examination.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 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-20 are rejected under 35 U.S.C. 103 as being unpatentable over Vasseur et al. (US 2022/0060393), in view of Kubik et al. (US 10,079,749 B2).
As to claim 1, Vasseur discloses the invention as claimed, including a method comprising:
identifying, by a device (FIG. 2) and based on traceroute information (i.e., a routing/forwarding table, telemetry data, probe information) for a path in a network between an endpoint client (FIGS. 3A-3B, 302) and an online application (FIGS. 3A-3B, 308), a particular segment of the path (i.e., SLA failure, delay, loss, jitter, SLA violation, session disruptions) as most likely to cause degraded performance along the path (FIGS. 3A-3B; ¶0032, “a routing/forwarding table (a data structure 245) containing, e.g., data used to make routing/forwarding decisions”; ¶0040, “provide connectivity to SaaS provider(s) 308 via tunnels across any number of networks 306. This allows clients located in the LAN of remote site 302 to access cloud applications (e.g., Office 365™, Dropbox™, etc.) served by SaaS provider(s) 308”; ¶0049, ‘SLA failure’ refers to a situation in which the SLA for a given application, often expressed as a function of delay, loss, or jitter, is not satisfied by the current network path for the traffic of a given application. This leads to poor QoE from the standpoint of the users of the application”; ¶0051, “Routing s still entirely reactive: decisions are made using probes that reflect the status of a path at a given time, in contrast with the notion of an informed decision”; ¶0054; ¶0065, “a predictive routing engine 606 that uses telemetry data collected from network 600 to predict SLA violations along path 602a and path 602b”; ¶0071, “monitor different application experience metrics, while in FM mode, in addition to any SLA violations. For example, router 110c may monitor the number of users affected by an SLA violation, the number of session disruptions, or even explicit application feedback information (e.g., degradation of video application traffic can be detected by changes in the resolution observed over paths)”; ¶0077);
making, by the device and using a prediction model (FIG. 4B, 412), a prediction that routing traffic for the online application via the path will result in degraded quality of experience for the online application (¶0049, ‘SLA failure’ refers to a situation in which the SLA for a given application, often expressed as a function of delay, loss, or jitter, is not satisfied by the current network path for the traffic of a given application. This leads to poor QoE from the standpoint of the users of the application”; ¶0054, “predictive application aware routing engine 412 may compute a variety of models to understand application requirements, and predictably route traffic over private networks and/or the Internet”; ¶0057, “the predictive routing engine utilizes statistical and/or machine learning techniques to predict such path deterioration in the future (e.g., predict SLA violations)”);
obtaining, by the device and based on the prediction, additional traceroute information (i.e., routing patches, routing policies) in the network, to identify a bypass path (i.e., reroute path, alternate path, or avoid path) in the network between the endpoint client and the online application that bypasses the particular segment (¶0012, “a networking device reroutes traffic in a network from a first path to a second path, based on a prediction that the first path will not satisfy a service level agreement associated with the traffic. The networking device enacts a routing decision for the traffic by applying a routing policy to the determination”; ¶0051, “Routing s still entirely reactive: decisions are made using probes that reflect the status of a path at a given time, in contrast with the notion of an informed decision”; ¶0052, “SLA failures are in the Internet and a good proportion of them could be avoided (using an alternate path), if predicted in advance”; ¶0057, “predictive routing engine may identify trend changes in the network KPIs of a path by utilizing several probes that measure path health (e.g., loss, latency and jitter). In turn, the predictive routing engine utilizes statistical and/or machine learning techniques to predict such path deterioration in the future (e.g., predict SLA violations) and generate routing “patches” (e.g., policies) that proactively reroute application traffic before an SLA violation occurs”; ¶0065, “predictive routing engine 606 that uses telemetry data collected from network 600 to predict SLA violations along path 602a and path 602b and push routing patches to router 110c that cause router 110c to proactively avoid such violations by rerouting its traffic onto another path”); and
causing, by the device, traffic for the online application to be routed along the bypass path (¶0049, “Modern SaaS solutions like Viptela, CloudonRamp SaaS, and the like, allow for the computation of per application QoE by sending HyperText Transfer Protocol (HTTP) probes along various paths from a branch office and then route the application's traffic along a path having the best QoE for the application”; ¶0051, “Routing s still entirely reactive: decisions are made using probes that reflect the status of a path at a given time, in contrast with the notion of an informed decision”; ¶0057, “routing “patches” (e.g., policies) that proactively reroute application traffic before an SLA violation occurs”; ¶0065, “application traffic 608 may generate and send a routing patch 610, so as to reroute application traffic 608 onto path 602b in advance of the predicted SLA violation by path 602a”; ¶0066, “router 110c may reroute application traffic 608 onto the secondary path, path 602b, to avoid the predicted SLA violation by path 602a”; ¶0073; ¶0082, “Reroute where tunnel head-ends are rerouted onto the primary path”; ¶0084, “the additional information provided by router 110c on the status along path 602b when rerouting application traffic 608 may be used by predictive routing engine 606 its choice of alternate path for further rerouting decisions, when it forecasts SLA violations along the primary path 602a (e.g., by opting to reroute further traffic along a third path instead of path 602b, etc.)”).
Although Vasseur discloses an alternate path, a variety of different pathways between an edge device and an SaaS provider, and a routing decision for the traffic by applying a routing policy to the determination (Abstract; ¶0012; ¶0041; ¶0049; ¶0060; ¶0062; ¶0065), Vasseur does not specifically disclose the particular segment being an oriented hop pair of the path inferred from the traceroute information.
Kubik discloses the particular segment being an oriented hop pair of the path inferred from the traceroute information (Figs. 1-3; Figs. 6-7; col. 3, lines 16-46, “A tracerouting probe can be used to collect network performance metrics along the paths to the given endpoint, and trigger the reporting of performance metrics from the different intermediate nodes on the path. Such performance metrics, such as packet loss and latency, may then be used to detect transit traffic problems at least one edge or at least one node on the probe paths”; col. 3, line 47 – col. 4, line 3, “source node 110 may use a tracerouting probe. The tracerouting probe may be used to detect different routing paths between source node 110 and target node 160. In one example, the probe may begin at source node 110, and then move to network node 120 through edge 111”; col. 4, line 36 – col. 5, line 2). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Vasseur to include the particular segment being an oriented hop pair of the path inferred from the traceroute information, as taught by Kubik because it would help pinpoint exactly where latency spikes or packet loss occurs, thereby improving the efficiency of end-to-end traffic flows (Kubik; col. 2, line 63 – col. 3, line 58).
As to claim 2, Vasseur discloses the method as in claim 1, wherein the prediction model is trained using quality of experience metrics captured by the online application (¶0034, “supervised learning entails the use of a training set of data, as noted above, that is used to train the model to apply labels to the input data. For example, the training data may include sample telemetry that has been labeled as normal or anomalous”; ¶0083, “predictive routing engine 606 may use any reports of false positives by router 110c to improve the prediction accuracy of its model. Optionally, a report of a false positive by router 110c may even trigger model retraining”).
As to claim 3, Vasseur discloses the method as in claim 1, wherein the traffic for the online application is routed along the bypass path via a tunnel (¶0049, “Modern SaaS solutions like Viptela, CloudonRamp SaaS, and the like, allow for the computation of per application QoE by sending HyperText Transfer Protocol (HTTP) probes along various paths from a branch office and then route the application's traffic along a path having the best QoE for the application”; ¶0065, “application traffic 608 may generate and send a routing patch 610, so as to reroute application traffic 608 onto path 602b in advance of the predicted SLA violation by path 602a”; ¶0066, “router 110c may reroute application traffic 608 onto the secondary path, path 602b, to avoid the predicted SLA violation by path 602a”; ¶0073; ¶0082, “Reroute where tunnel head-ends are rerouted onto the primary path”; ¶0084, “the additional information provided by router 110c on the status along path 602b when rerouting application traffic 608 may be used by predictive routing engine 606 its choice of alternate path for further rerouting decisions, when it forecasts SLA violations along the primary path 602a (e.g., by opting to reroute further traffic along a third path instead of path 602b, etc.)”).
As to claim 4, Vasseur discloses the method as in claim 1, wherein causing the traffic for the online application to be routed along the bypass path comprises: setting a proxy configuration of the endpoint client (It is noted that setting a proxy configuration at the client is well known in the art for proper traffic redirection and security features; ¶0012, “a networking device reroutes traffic in a network from a first path to a second path, based on a prediction that the first path will not satisfy a service level agreement associated with the traffic”; ¶0052, “SLA failures are in the Internet and a good proportion of them could be avoided (using an alternate path), if predicted in advance”; ¶0057, “predictive routing engine may identify trend changes in the network KPIs of a path by utilizing several probes that measure path health (e.g., loss, latency and jitter). In turn, the predictive routing engine utilizes statistical and/or machine learning techniques to predict such path deterioration in the future (e.g., predict SLA violations) and generate routing “patches” (e.g., policies) that proactively reroute application traffic before an SLA violation occurs”; ¶0065, “predictive routing engine 606 that uses telemetry data collected from network 600 to predict SLA violations along path 602a and path 602b and push routing patches to router 110c that cause router 110c to proactively avoid such violations by rerouting its traffic onto another path”).
As to claim 5, Vasseur discloses the method as in claim 1, further comprising: identifying a new bypass point in the network, based on the additional traceroute information, when the additional traceroute information indicates that no bypass path exists; and provisioning the new bypass point to form the bypass path in the network (¶0012, “a networking device reroutes traffic in a network from a first path to a second path, based on a prediction that the first path will not satisfy a service level agreement associated with the traffic. The networking device enacts a routing decision for the traffic by applying a routing policy to the determination”; ¶0051, “Routing s still entirely reactive: decisions are made using probes that reflect the status of a path at a given time, in contrast with the notion of an informed decision”; ¶0052, “SLA failures are in the Internet and a good proportion of them could be avoided (using an alternate path), if predicted in advance”; ¶0057, “predictive routing engine may identify trend changes in the network KPIs of a path by utilizing several probes that measure path health (e.g., loss, latency and jitter). In turn, the predictive routing engine utilizes statistical and/or machine learning techniques to predict such path deterioration in the future (e.g., predict SLA violations) and generate routing “patches” (e.g., policies) that proactively reroute application traffic before an SLA violation occurs”; ¶0065, “predictive routing engine 606 that uses telemetry data collected from network 600 to predict SLA violations along path 602a and path 602b and push routing patches to router 110c that cause router 110c to proactively avoid such violations by rerouting its traffic onto another path”).
As to claim 6, Vasseur discloses the method as in claim 5, further comprising: deprovisioning the new bypass point, based on a prediction by the prediction model that routing traffic for the online application via the path will no longer degrade quality of experience for the online application (¶0012, “a networking device reroutes traffic in a network from a first path to a second path, based on a prediction that the first path will not satisfy a service level agreement associated with the traffic. The networking device enacts a routing decision for the traffic by applying a routing policy to the determination”; ¶0051, “Routing s still entirely reactive: decisions are made using probes that reflect the status of a path at a given time, in contrast with the notion of an informed decision”; ¶0052, “SLA failures are in the Internet and a good proportion of them could be avoided (using an alternate path), if predicted in advance”; ¶0057, “predictive routing engine may identify trend changes in the network KPIs of a path by utilizing several probes that measure path health (e.g., loss, latency and jitter). In turn, the predictive routing engine utilizes statistical and/or machine learning techniques to predict such path deterioration in the future (e.g., predict SLA violations) and generate routing “patches” (e.g., policies) that proactively reroute application traffic before an SLA violation occurs”; ¶0065, “predictive routing engine 606 that uses telemetry data collected from network 600 to predict SLA violations along path 602a and path 602b and push routing patches to router 110c that cause router 110c to proactively avoid such violations by rerouting its traffic onto another path”).
As to claim 7, Vasseur discloses the method as in claim 1, wherein the traceroute information for the path is captured by a probing agent (FIG. 6B, 612a-612b) executed by the endpoint client or an edge router (FIG. 6B, 110c) associated with the endpoint client (¶0012, “The networking device enters a fast monitoring state during which the networking device performs fast probing of the first path and of the second path onto which the traffic was rerouted”; ¶0049, “allow for the computation of per application QoE by sending HyperText Transfer Protocol (HTTP) probes along various paths from a branch office and then route the application's traffic along a path having the best QoE for the application”; ¶0067, “router 110c may begin a fast probing cycle onto path 602a and path 602b whereby probes 612a and probes 612b, respectively, are sent. Such probes 612a-612b may be of different forms, depending on the natures of paths 602a-602b”).
As to claim 8, Vasseur discloses the method as in claim 1, wherein obtaining the additional traceroute information in the network comprises: requesting that one or more probing agents in the network perform probing tests of additional paths in the network to the online application (¶0049, “Modern SaaS solutions like Viptela, CloudonRamp SaaS, and the like, allow for the computation of per application QoE by sending HyperText Transfer Protocol (HTTP) probes along various paths from a branch office and then route the application's traffic along a path having the best QoE for the application”; ¶0051, “Routing s still entirely reactive: decisions are made using probes that reflect the status of a path at a given time, in contrast with the notion of an informed decision”; ¶0057, “routing “patches” (e.g., policies) that proactively reroute application traffic before an SLA violation occurs”; ¶0065, “application traffic 608 may generate and send a routing patch 610, so as to reroute application traffic 608 onto path 602b in advance of the predicted SLA violation by path 602a”; ¶0066, “router 110c may reroute application traffic 608 onto the secondary path, path 602b, to avoid the predicted SLA violation by path 602a”; ¶0073; ¶0082, “Reroute where tunnel head-ends are rerouted onto the primary path”; ¶0084, “the additional information provided by router 110c on the status along path 602b when rerouting application traffic 608 may be used by predictive routing engine 606 its choice of alternate path for further rerouting decisions, when it forecasts SLA violations along the primary path 602a (e.g., by opting to reroute further traffic along a third path instead of path 602b, etc.)”).
As to claim 9, Vasseur discloses the method as in claim 1, wherein the device identifies the bypass path as an existing bypass path based on the additional traceroute information (¶0079, “router 110c may revert the reroute of predictive routing engine 606 from path 602b back onto path 602a”; ¶0088, “the networking device may enact a routing decision for the traffic by applying a routing policy to the determination. In one embodiment, the device may do so by rerouting the traffic back onto the first path”).
As to claim 10, Vasseur discloses the method as in claim 1, wherein the network comprises a software-defined networking (SDN) overlay (¶0027, “a software defined networking (SDN)-based approach to instantiate tunnels on top of the physical network and control routing decisions”; ¶0044-¶0045).
As to claim 11, it is rejected for the same reasons set forth in claim 1 above. In addition, Vasseur discloses an apparatus, comprising: one or more network interfaces (FIG. 2, 210); a processor (FIG. 2, 220) coupled to the one or more network interfaces (FIG. 2, 210) and configured to execute one or more processes; and a memory (FIG. 2, 240) configured to store a process that is executable by the processor (FIG. 2; ¶0031; ¶0092).
As to claims 12-19, they are rejected for the same reasons set forth in claims 2-9 above.
As to claim 20, it is rejected for the same reasons set forth in claim 1 above. In addition, Vasseur discloses a tangible, non-transitory, computer-readable medium storing program instructions that cause a device to execute a process (Fig. 2; ¶0031; ¶0092).
Applicant’s arguments with respect to claim(s) 1-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JUNGWON CHANG whose telephone number is (571)272-3960. The examiner can normally be reached 9AM-5:30PM.
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, GLENTON BURGESS can be reached at (571)272-3949. 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.
/JUNGWON CHANG/Primary Examiner, Art Unit 2454 January 10, 2026