DETAILED ACTION
This Non-Final Office Action is in response to application number 18/807,212 filed on August 16th 2024. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statements
The Information Disclosure Statements(IDS), submitted on August 16th 2024, is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement has been considered by the examiner.
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 may not be obtained though the invention is not identically disclosed or described as set forth in section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the manner in which the invention was made.
Claims 1-20-are rejected under 35 U.S.C.103 as being unpatentable over Dasgupta et al. (US 20230022959 A1) in view of Oliveira et al. (US 20230049207 A1).
Regarding claims 1,11 and 20, Dasgupta et al. disclose a method, comprising: generating, by a device, a routing graph using path trace data, wherein nodes of the routing graph represent different entities in one or more computer networks (US 20230022959 A1 Paragraph 0142 discloses US20230049207 A1 “At step 815, as detailed above, the device may generate a mapping between network paths traversed by traffic of the online application and the QoE metrics. In some embodiments, the device may do so by constructing a routing graph with each node representing a different autonomous system and edges of the graph connecting different autonomous systems. In turn, the device may assign a weight to each node or edge, representing its importance. The device may then associate the QoE metrics to the different paths represented in the graph.” Paragraphs 0071-0072 disclose “ Network data—for instance, this may include Netflow or other network records for the various user sessions. Such information may indicate, for instance, the source and destinations of traffic flows for the application, QoS metrics for the traversed paths, etc. [0072] Path trace data—this information can be obtained through various mechanisms, to trace the paths between the various user sites and application data centers.”); computing, by the device, importance metrics for the nodes in the routing graph based on their traffic loads (US 20230022959 A1 Paragraphs 0121-122 disclose “In further embodiments, ACGC 508 may enhance the connectivity graph by adding several novel graph metrics to describe the importance of a node, an edge, or sub-paths. Examples of such metrics may include, but are not limited to, any or all of the following: [0122] Centrality metrics for nodes: These metrics quantify the importance of the node with respect to a given weight of the node. In one embodiment, the weight of a node can be assigned to the number of paths that pass through that node. In other embodiments, ACGC 508 may use a centrality algorithm, such as Eigen centrality, Katz centrality, page-rank, or the like. For example, each node can be weighed by the degree and a centrality metric can be computed. Such a metric can be used to signify the importance of a node based on the number of other ASNs that it connects to and their importance. The more central a node is, the more ‘important’ it is in connecting different edge-routers to the given SaaS end-point.”); generating, by the device, an insight regarding the one or more computer networks based on the importance metrics for the nodes (US 20230022959 A1 Paragraphs 0128 discloses “Referring again to FIG. 5, core path alerter (CPA) 510 may be responsible for determining whether any QoE degradation for the application is attributable to any of the central nodes, edges or sub-paths. In addition, CPA 510 may be responsible for sending alerts to predictive application aware routing engine 412 and/or SaaS Provider device 516 regarding that core entity and the degraded application experience. To do so, CPA 510 may be responsible for first creating a mapping by assigning the application experience from ANC 502 to core connectivity entities of the SECG (such as central nodes, edges or sub-paths) computed by AGCG 508, and then performing correlation/causality analysis to check whether the application experience degradation is in fact attributable to any of the core entities.”);
Dasgupta et al. fail to explicitly disclose providing, by the device, the insight to a user interface for presentation to a user.
However in an analogous art Oliveira et al. disclose providing, by the device, the insight to a user interface for presentation to a user (US 20230049207 A1 Paragraph 0042 discloses “The controller 320 is the central processing and administration server for the observability intelligence platform. The controller 320 may serve a browser-based user interface (UI) 330 that is the primary interface for monitoring, analyzing, and troubleshooting the monitored environment. Specifically, the controller 320 can receive data from agents 310 (and/or other coordinator devices), associate portions of data (e.g., topology, business transaction end-to-end paths and/or metrics, etc.), communicate with agents to configure collection of the data (e.g., the instrumentation/tests to execute), and provide performance data and reporting through the interface 330. The interface 330 may be viewed as a web-based interface viewable by a client device 340. In some implementations, a client device 340 can directly communicate with controller 320 to view an interface for monitoring data. The controller 320 can include a visualization system 350 for displaying the reports and dashboards related to the disclosed technology. In some implementations, the visualization system 350 can be implemented in a separate machine (e.g., a server) different from the one hosting the controller 320.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to have modified Dasgupta et al. to incorporate the teachings of Oliveira et al., to provide, by the device, the insight to a user interface for presentation to a user, in order to enable the user to initiate corrective actions based up insights and analysis conducted.
Regarding claims 2 and 12, Dasgupta et al. disclose the method as in claim 1, wherein the insight indicates a rerouting event in the one or more computer networks based on a change in the importance metrics for a plurality of the nodes (US 20230022959 A1 Paragraphs 0139 discloses “In case of a “Central change and Bad-experience” alert, it may conclude that there is no point in changing the interfaces since the core connectivity entities have a bad experience to this SaaS data-center, and then change the SaaS data-center itself. When configured by the user, critical traffic sent through an arterial path that is severely impacting critical traffic may be explicitly rerouted along an alternate path….”. Additionally, paragraph 0144 discloses “At step 825, as detailed above, the device may send an alert regarding the core entity. In various embodiments, the alert may cause the traffic of the online application to avoid the core entity. In one embodiment, the device may send the alert to an application-aware routing engine. In turn, that routing engine may reroute the traffic of the online application to avoid the core entity, based on the alert….”).
Regarding claims 3 and 13, Dasgupta et al. disclose the method as in claim 1, wherein the insight indicates an outage associated with a particular one of the different entities based on a decrease in its associated importance metric (US 20230022959 A1 Paragraph 0132-0136 disclose “Referring again to FIG. 5, CPA 510 may track the changes in both the measure of centrality and the application experience metrics of entities such as nodes, edges, and sub-paths over time, in various embodiments. In turn, CPA 510 may generate and provide any or all of the following types of alerts: [0133] Bad-experience Alert: CPA 510 may generate this type of alert when an entity moves from providing good QoE metrics to bad QoE metrics. These can be alerts which indicate transition to bad experience irrespective of whether the entity is central or not. Predictive application aware routing engine 412 may act on this alert to search for better interfaces or paths which avoids such nodes or AS-AS edges. [0134] Centrality change alert: CPA 510 may generate this type of alert when an entity moves from being non-central to being central or vice-versa. Such alerts may be used to prioritize the severity of application experience changes. [0135] Central entity bad-experience alert: CPA 510 may generate this type of alert when an entity moves to bad experience state, as in the case of sub-path S in FIG. 7. In general, these are major alerts that indicate that something wrong has happened in the central routes. Such messages may be provided to either or both of predictive application aware routing engine 412 and SaaS Provider device 516, for purposes of alerting and troubleshooting. [0136] Central change and bad-experience alert: A centrality change can happen when there are sudden routing changes, or when certain central sub-paths are suddenly detected. If such an event is also accompanied by transition to bad-experience, CPA 510 may also generate an alert that indicates that a severe anomaly has occurred that might impact multiple users.”).
Regarding claims 4 and 14, Dasgupta et al. disclose the method as in claim 1, wherein the device computes the importance metrics for the nodes using a summarization model (US 20230022959 A1 Paragraph 0122 discloses “Centrality metrics for nodes: These metrics quantify the importance of the node with respect to a given weight of the node. In one embodiment, the weight of a node can be assigned to the number of paths that pass through that node. In other embodiments, ACGC 508 may use a centrality algorithm, such as Eigen centrality, Katz centrality, page-rank, or the like. For example, each node can be weighed by the degree and a centrality metric can be computed. Such a metric can be used to signify the importance of a node based on the number of other ASNs that it connects to and their importance. The more central a node is, the more ‘important’ it is in connecting different edge-routers to the given SaaS end-point.”. The applicant’s specification states “For instance, such a summarization model may take the form of a machine learning model, a page rank algorithm, the Hyperlink-Induced Topic Search (HITS) algorithm, algorithms based on graph neural networks, or the like. In general, the summarization may take the form of importance metrics for each of the nodes in the graph under analysis that indicate the traffic load of the entity associated with that node.”).
Regarding claims 5 and 15, Dasgupta et al. disclose the method as in claim 1, further comprising: providing, by the device and based in part on the insight, a recommendation indicative of an optimal routing path for traffic of a particular application (US 20230022959 A1 Paragraphs 0054 discloses “Other solutions compute a metric reflecting a particular network characteristic (e.g., delay, throughput, etc.) and then selecting the supposed ‘best path,’ according to the metric.”).
Regarding claims 6 and 16, Dasgupta et al. disclose the method as in claim 1, wherein the different entities are autonomous systems (US 20230022959 A1 Paragraph 0142 discloses “At step 815, as detailed above, the device may generate a mapping between network paths traversed by traffic of the online application and the QoE metrics. In some embodiments, the device may do so by constructing a routing graph with each node representing a different autonomous system and edges of the graph connecting different autonomous systems. In turn, the device may assign a weight to each node or edge, representing its importance. The device may then associate the QoE metrics to the different paths represented in the graph.”).
Regarding claims 7 and 17, Dasgupta et al. disclose the method as in claim 1, wherein the different entities are points-of-presence (PoPs) located in different geographical areas (US 20230022959 A1 Paragraph 0062 discloses “As noted above, SaaS applications are usually deployed across the globe in different data centers. Users from different regions connect via core Internet links to these SaaS applications. Hence, the application experience of a user of a SaaS application depends on a number of different points of failure: the endpoint device of the user, their LAN, the core Internet, the SaaS endpoint/data center, etc. Accordingly, troubleshooting poor SaaS application experience to trigger corrective measures (e.g., rerouting the application traffic) with such a wide array of possible components interacting with each other is challenging.”).
Regarding claims 8 and 18, Dasgupta et al. disclose the method as in claim 1, further comprising: updating the routing graph over time based on additional path trace data collected over time from the one or more computer networks (US 20230022959 A1 Paragraph 0125 discloses “Note that the node, edge and sub-path centralities change over time, and ACGC 508 keeps track of the time-evolving data about the centralities of the above entities.”).
Regarding claims 9 and 19, Dasgupta et al. disclose the method as in claim 8, wherein the device updates the routing graph over time by removing a particular node in the routing graph representing an entity that is not indicated in the additional path trace data (US 20230022959 A1 Paragraph 0125 discloses “Note that the node, edge and sub-path centralities change over time, and ACGC 508 keeps track of the time-evolving data about the centralities of the above entities.”).
Regarding claim 10, Dasgupta et al. disclose the method as in claim 1, further comprising: obtaining, by the device, the path trace data from a plurality of probing agents distributed throughout the one or more computer networks (US 20230022959 A1 Paragraphs 0071-0072 disclose “Network data—for instance, this may include Netflow or other network records for the various user sessions. Such information may indicate, for instance, the source and destinations of traffic flows for the application, QoS metrics for the traversed paths, etc. [0072] Path trace data—this information can be obtained through various mechanisms, to trace the paths between the various user sites and application data centers.”).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Samuel Dilan Rutnam whose telephone number is 703-756-1374. The examiner can normally be reached between 8:30am-5:00pm Mon-Fri.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Sujoy Kundu can be reached on 571-272-8586.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR.
Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
/Samuel Dilan Rutnam/
Patent Examiner, Art Unit 2471
/SUJOY K KUNDU/Supervisory Patent Examiner, Art Unit 2471
