DETAILED ACTION
This Office Action is in response to the RCE filed on 08/12/2026.
Claims 1, 8, and 15 are amended.
Claims 1-20 are presented for examination.
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 08/12/2026 has been entered.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 08/12/2026 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Response to Arguments
Applicant's arguments filed 08/12/2026 regarding the 35 USC 103 rejections on pg. 7-12 of Remarks have been fully considered but they are not persuasive.
Applicant argues in essence:
[a] “The Office cannot show that Rao teaches or suggests these features. Rao describes a system for determining metric data associated with destination network elements by providing interrogatory packets in-line over an existing SIP or RTP connection. Specifically, Rao describes that "Ta]n interrogation module 114 may be used to provide interrogatory data 116 to the second SBC 108(2) and the third SBC 108(3)" and that "[t]he interrogatory data 116 may be used to determine metric data 118 (e.g., latency, jitter, packet loss, and SO forth) associated with the endpoint of the SIP or RTP connection or one or more intermediate devices." (Rao, col. 6, II. 45-53.) Rao collects network metrics by sending specially-crafted packets between networks, not by receiving session-specific performance metrics from each participant device during participation in real-time communications. Similarly, Rao does not describe identifying a simultaneous increase in network performance degradation across a plurality of devices. Rao describes comparing metric data for a single network against a threshold value and generating a notification if the metric deviates. (Rao, col. 21, 11. 5-27.)” pg. 7 of Remarks.
In response to [a], examiner respectfully disagrees. While Rao is not relied upon for the concept of simultaneous performance degradation limitation, it is still relied upon for the limitation of “receiving network data from devices participating in real-time communications, the network data comprising session-specific performance metrics received from each of the devices during participation in the real-time communications, the session-specific performance metrics indicating a quality of media transmission between each of the devices and a communication server”
Under broadest reasonable interpretation, this limitation means, that the monitoring software receives from a plurality of devices that are participating in the real time communication, any performance metrics related to sessions from these devices. The metrics indicating media transmission quality.
Rao shows in Fig. 1 the source and destination network elements that comprise the metric data 118, and communication between the communication devices go through these elements. Therefore each of these network elements participate in the network communications. Fig. 3 shows the process from steps 306-314 and in col. 9 line 65 to col.10 line 20, Col. 19 line 17 -65 cited below, wherein metrics related to particular session types are requested from each of these devices and obtained. These metrics including jitter, latency, and packet drop, each of which indicate quality of media transmission.
Therefore, while Rao is not relied upon the new limitation involving simultaneous degradation, Rao is still relied upon for the limitation of “receiving network data from devices participating in real-time communications, the network data comprising session-specific performance metrics received from each of the devices during participation in the real-time communications, the session-specific performance metrics indicating a quality of media transmission between each of the devices and a communication server”
Rao teaches: the network data comprising session-specific performance metrics received from each of the devices during participation in the real-time communications, the session-specific performance metrics indicating a quality of media transmission between each of the devices and a communication server (Rao: col. 9 line 65 to col.10 line 20 “The metric processing module 130 may also determine a communication type associated with the connection from which the response data 122 is received. A communication type may include a type of connection (e.g., a SIP connection), a type of communication (e.g., a VoIP call), a location or region associated with the communication, and so forth.” Col. 19 line 17 -65 “ In other implementations, a metric request 208 may lack one or more particular metric data types 312, and the response data 122 may include each of the latency data 218, jitter data 220, and packet loss data 222…. For example, at least a portion of the metric data 118 requested using the interrogatory data 116 may be determined from the response data 122. The response data 122 may also include destination network element data 214 indicative of one or more destination network elements 112 associated with the metric data 118.” The metrics received may be session specific, i.e. for a particular type of session, for example SIP connection and VOIP call between particular networks, and can be metrics that affect quality of media transmission such as jitter latency and packet loss.);
[b] “The Office cannot show that Mah teaches or suggests these features. Mah describes a root cause analysis (RCA) technique for SDN-controlled networks that relies on end-to-end TCP socket statistics collected from hosts. Specifically, Mah describes that "[t]he second piece of information that the RCA algorithm uses are the flow statistics for flows in the network 100. An example of flow statistics are end-to-end Transmission Control Protocol (TCP) statistics." (Mah, I [0037].) These TCP statistics are general-purpose host-level socket metrics (retransmissions, round-trip time) available through "/proc" or standard user-level tools. (Mah, I [0038].) They are not session-specific performance metrics indicating a quality of media transmission between each of the devices and a communication server as recited in amended claim 1.” Pg. 8 of Remarks.
In response to [b], examiner respectfully disagrees. Firstly, This limitation is mapped to primary reference Rao, as explained in more detail below and in response to argument [a].
Secondly, Mah discloses For a particular flow between 2 devices, i.e. a session, statistics are received from each host for that session.
For example, in para.0045 “The link that connects S1 and S2 is denoted as S1S2, the link that connects S2 and S2 is denoted as S2S2, and so on. The SDN controller 125 collects TCP statistics from the hosts H1-H5 (e.g., using a REST API provided by the hosts H1-H5) and thus has knowledge of the TCP statistics for each flow (e.g., global TCP statistics view table 320). As shown, the TCP statistics include the number of retransmissions (i.e., rtrans) and round trip time (i.e., rtt). For example, the TCP statistics for flow 1 indicates that the number of retransmissions is 0 and the round trip time is 8,0/4,0, where 8,0 is the most recent measurement (8 ms RTT, with 0 ms variance) and where 4,0 is the previous measurement (4 ms RTT, with 0 ms variance).”
Para.0037 “The TCP statistics collected by the host can include the internet protocol (IP) address and port of both ends of the flow, the round trip time (RTT), packet loss rate, and number of retransmissions. Other TCP flow statistics that can be collected from the kernel level of the host operating system include state of the TCP connection, congestion algorithm details, bandwidth, and data amount information.”
The controller obtains statistics from each host, and these statistics can be retransmissions and round trip time, as well as packet loss, bandwidth, congestion, all of which effect communication quality, for each flow between 2 hosts.
[c] “Furthermore, Mah does not describe identifying a simultaneous increase in network performance degradation across a plurality of the devices. Mah describes two analytical approaches.
The first approach is a process-of-elimination algorithm that checks "whether a non- problematic flow traverses the selected link" and, "[i]f a non-problematic flow traverses the selected link, then the selected link cannot be the source of the problem, and thus the selected link is excluded from being a candidate problem link." (Mah, I [0042].) Mah further states that "[w]hether a given flow is problematic can be determined based on the flow statistics for that flow. For example, a flow can be determined to be problematic if a flow metric value for that flow (e.g., delay) exceed a threshold value or if a flow metric value for that flow is abnormal for that flow (deviates from an average historical value for that flow by a threshold amount or a percentage amount)." (Id.)
The second approach is a k-means clustering algorithm in which "each flow can be represented as a point in an F|-dimensional space" and "[t]he dots that are clustered together represent the flows that are similar in terms of similarity score and each cluster represents an independent performance issue in the network." (Mah, I [0055].)
In both of these approaches, Mah performs static, snapshot-based comparisons of metric values to classify individual flows as problematic or non-problematic. Mah does not identify a simultaneous increase in degradation across multiple devices. That is, Mah does not detect that performance degradation is increasing concurrently across a plurality of devices participating in real-time communications. Rather, Mah determines whether individual flows are currently problematic based on point-in-time metric comparisons and then identifies shared links among those flows.” Pg. 8-9 of Remarks.
In response to [c], examiner respectfully disagrees. The limitation addressed in [c] is “localizing a network segment where the network performance degradation is occurring by correlating a timing and nature of the network performance degradation detected across the plurality of devices with network topology data that maps the plurality of devices to respective associated network paths, the correlating comprising identifying a simultaneous increase in the network performance degradation across the plurality of the devices”
Under broadest reasonable interpretation, this limitation requires determining a common network segment by correlating degradation of multiple flows on network topology based on simultaneous increase in network degradation experienced by the devices.
In Mah, this process is the same. As described in Fig. 3A-3B, each flow that has an increase in network degradation is mapped. For example, in para.0045 and para.0046 both are currently experiencing an increase in degradation, from 4ms to 8ms for flow 1, and 16ms to 42ms for flow 4, i.e. simultaneously as both current measurements are compared to the last previous measurement when the SDN updates its TCP statistics for the flows. This information is then used to identify the common link for the flows to determine the root cause.
Therefore, because of at least the reasons above, examiner maintains rejection in view of Mah.
Mah: Para.0045 “For example, the TCP statistics for flow 1 indicates that the number of retransmissions is 0 and the round trip time is 8,0/4,0, where 8,0 is the most recent measurement (8 ms RTT, with 0 ms variance) and where 4,0 is the previous measurement (4 ms RTT, with 0 ms variance).”
Mah: Para.0046 “FIG. 3B is a block diagram illustrating flows in a network that are experiencing a performance issue, according to some embodiments. In this example, a performance issue (e.g., long delay) experienced by flow 4 (between H1 and H5) triggers the RCA algorithm. When the SDN controller 125 updates its TCP statistics (shortly after flow 4 experiences a problem), the updated TCP statistics indicate that the number of retransmissions for flow 4 is 20 and the round trip time for flow 4 is higher at 32,0/16,0, where 32,0 is the most recent measurement (32 ms RTT, with 0 ms variance) and where 16,0 is the previous measurement (16 ms RTT, with 0 ms variance). These statistics indicate that flow 4 is experiencing a performance issue. For simplicity and clarity, the round trip time is assumed to be the same in both directions of a flow. The RCA algorithm described with reference to FIG. 2 or similar algorithm can be executed over the combined data view to determine the root cause of the performance issue of flow 4. The process iterates through each link on flow 4 (thus excluding links S2S3 and S3S5, which are not on path of flow 4). As the process iterates through each link on flow 4, the process will use the combined data view to determine that links S1S2, S2S4, and S4S5 each have a non-problematic flow that traverses them. As such, the process excludes these links from being the source of the performance issue. On the other hand, all flows that traverse link S5S6 (namely flows 3 and 4) are experiencing a problem, and thus the RCA algorithm identifies link S5S6 as a candidate problem link.”
[d] “The Office cannot show that Raj teaches or suggests these features. Raj describes a diagnostics server that classifies faults and sends corrective action messages. Specifically, Raj describes that "the diagnostic server may identify the fault classification" and "may also identify one or more fault sub-classes, for example: system fault, subsystem fault, component fault, service fault, device fault, data fault, global fault, etc." (Raj, I [0064].) Raj further describes that "the diagnostics server may determine the remedy according to the fault classification" and "may send corrective action messages to the identified hardware, software, or processes specifying the corrective actions." (Raj, I [0065].) Raj does not describe session-specific performance metrics indicating a quality of media transmission between each of the devices and a communication server, or identifying a simultaneous increase in network performance degradation across a plurality of the devices.” Pg. 9 of Remarks.
In response to [d], Raj is not relied upon to teach the newly added limitations, therefore this argument does not apply.
[e] “Since Rao describes collecting metrics via interrogatory packets between networks, Mah describes analyzing general TCP socket statistics using static snapshot comparisons, and Raj describes fault classification with corrective action messaging, the combination of Rao with Mah and Raj does not teach or suggest at least the features of "the network data comprising session- specific performance metrics received from each of the devices during participation in the real- time communications, the session-specific performance metrics indicating a quality of media transmission between each of the devices and a communication server" and "the correlating comprising identifying a simultaneous increase in the network performance degradation across the plurality of the devices." Thus, claim 1 and its dependent claims 2-3 are not obvious over Rao, Mah, Raj, or any combination thereof.” Pg. 9 of Remarks.
In response to [e], examiner respectfully disagrees. At least Rao and Mah are relied upon for these limitations as explained in more detail above, in response to arguments [a]-[c].
[f] Dependent claims are non obvious because they depend on amended independent claims 1, 8 and 15. Pg. 9-11 of Remarks.
In response to [f], examiner maintains rejection of each independent claim, and maintains rejection for each dependent claim as well, therefore these arguments do not apply.
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.
Claim(s) 1-3, 8-10, 13-16, 18 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Rao (US 9,749,886 B1) in view of Mahkonen et al (hereinafter Mah, US 2017/0126475 A1) in view of Rajagopal et al. (hereinafter Raj, US 2015/0227404 A1).
Regarding Claim 1, Rao discloses A method implemented by a communications monitoring software (Rao: Fig. 4 Col. 20 lines 21-30 the software that performs the communications monitoring steps in Fig. 4, col. 29 lines 5-10 “The processes discussed in this disclosure may be implemented in hardware, software,”), comprising:
receiving network data from devices participating in real-time communications (Rao: Fig. 4 408 col. 20 lines 63-col. 21 line 5. “At 408, response data 122 from the second network 102(2) may be received by the first network 102(1). The response data 122 may include at least a portion of the metric data 118 corresponding to the metric request 208 provided in the interrogatory data 116. For example, responsive to a request for metric data 118 indicative of the latency of one or more destination network elements 112, the response data 122 may include latency data 218 indicative of the latency of one or more devices associated with the second network 102(2).” Col. 7 lines 16-20 “ The interrogation module 114 may provide one or more interrogatory packets to the second network 102(2) and the third network 102(3) in-line, via the existing connection that is currently being used to provide voice packets 110 between the networks 102.” Col. 5 line 5-12 “For example, the communication devices 104 may use Web Real-Time Communication (WebRTC) to support voice calling, video chat, file sharing, and so forth” Metrics are obtained from devices that are communicating using real time communications, such as voice communication. )
the network data comprising session-specific performance metrics received from each of the devices during participation in the real-time communications, the session-specific performance metrics indicating a quality of media transmission between each of the devices and a communication server (Rao: col. 9 line 65 to col.10 line 20 “The metric processing module 130 may also determine a communication type associated with the connection from which the response data 122 is received. A communication type may include a type of connection (e.g., a SIP connection), a type of communication (e.g., a VoIP call), a location or region associated with the communication, and so forth.” Col. 19 line 17 -65 “ In other implementations, a metric request 208 may lack one or more particular metric data types 312, and the response data 122 may include each of the latency data 218, jitter data 220, and packet loss data 222…. For example, at least a portion of the metric data 118 requested using the interrogatory data 116 may be determined from the response data 122. The response data 122 may also include destination network element data 214 indicative of one or more destination network elements 112 associated with the metric data 118.” The metrics received may be session specific, i.e. for a particular type of session, for example SIP connection and VOIP call between particular networks, and can be metrics that affect quality of media transmission such as jitter latency and packet loss.);
identifying, based on the network data, a network issue impacting a quality of the real-time communications (Rao: Fig. 4 410, col. 21 lines 5-22 “At 410, a device associated with the first network 102(1) may determine that one or more values of the received metric data 118 deviate from the threshold metric value(s) 404 determined from the communication data 126 by an amount equal to or exceeding a threshold quantity.” Col. 18 lines 10-24 “ Similarly, audible sound received by the communication device 104 associated with the second network 102(2) may be used to produce voice packets 110 to be provided to the first network 102(1). A SBC 108, source network elements 106, or other devices may process the voice packets 110 from the second network 102(2). Processed voice packets 110 may be emitted by the communication device 104 associated with the first network 102(1) as audible sound. Metric values, such as latency, jitter, packet loss, and so forth, may affect the quality of the communication using the SIP connection 304. For example, high latency in destination network elements 112 associated with the second network 102(2) may result in a significant delay between the time that a first user provides audible sound to a first communication device 104(1) and the time that a second user receives the audible sound at a second communication device 104(2). High packet loss may result in portions of the communication that do not reach one of the parties.” A network issue of a metric going over a threshold is determined, that negatively impact the voice communication.)
in response to identifying the network issue, generating an alert (Rao: Fig. 4 414 col. 21 lines 23-27 “At 414, responsive to the determination that the variance 412 equals or exceeds a threshold quantity, a notification 416 indicative of the variance 412 may be generated by the notification module 132.” A notification may be generated based on the metrics exceeding a threshold.).
However Rao does not explicitly disclose wherein identifying the network issue comprises: detecting a pattern of simultaneous network performance degradation across a plurality of the devices participating in the real-time communications; localizing a network segment where the network performance degradation is occurring by correlating a timing and nature of the network performance degradation detected across the plurality of devices with network topology data that maps the plurality of devices to respective associated network paths, the correlating comprising identifying a simultaneous increase in the network performance degradation across the plurality of the devices; and pinpointing, based on the localizing, a shared network infrastructure component within the localized network segment as a source of the network performance degradation impacting the real-time communications; and in response to identifying the network issue, generating an alert directed to the shared network infrastructure component, the alert including a remediation action for the shared network infrastructure component.
Mah discloses wherein identifying the network issue comprises: detecting a pattern of simultaneous network performance degradation across a plurality of the devices (Mah: para.0055 “In some cases, there can be multiple simultaneous failures in the network 100 (e.g., more than 1 link experiences congestion).” Simultaneous performance degradation is detected, the pattern being 2 or more occurrences of performance degradation occurring simultaneously)
real-time communications (Mah: para.0031 voice, para.0078 “ Voice Over Internet Protocol (VOIP) phones”);
localizing a network segment where the network performance degradation is occurring by correlating a timing and nature of the network performance degradation detected across the plurality of devices with network topology data that maps the plurality of devices to respective associated network paths (Mah: para.0053 “The process then identifies a common link shared between the flow and the one or more reference flows as a candidate problem link (block 430). The reference flows are the flows that are deemed to be experiencing a similar problem as the problematic flow. As such, a common link shared between the problematic flow and the reference flows is likely to be the root cause of the performance issue.” Para.0054 “When the number of flows is large, it may not be practical to obtain the flow statistics for all the flows. In one embodiment, the process maintains a top-p list of flows for each link. The top-p list of flows for a link maintains the p flows traversing the link that have the highest flow statistic metric values. In one embodiment, a heap data structure may be used to store the top-p list of flows. When an alarm is received for a problematic flow, the process can query for the top-p flows from each link on the path of the problematic flow. An RCA algorithm similar to that described with reference to FIG. 2 can then be applied to these flows to determine a root cause of the problem.”para.0055 “In some cases, there can be multiple simultaneous failures in the network 100 (e.g., more than 1 link experiences congestion). In one embodiment, a k-means clustering algorithm can be used to identify the set of problematic links Given |F| metrics, …. The common links shared among the clustered flows can be determined as a root cause of the problem. ” Fig. 4 430, when 2 or more failures occur simultaneously, in this case the nature being congestion and timing being at the same time, a set of common links that are shared between the flows is determined to be a root cause of the degradation. Para.0045, 0036 and Fig. 3A showing how the network topology is used to determine a root cause link para.0036 “The view of the network topology is commonly referred to as a network information base (NIB). The SDN controller 125 can use the NIB to determine the flow paths of flows in the network 100.”)
the correlating comprising identifying a simultaneous increase in the network performance degradation across the plurality of the devices (Mah: para.0045 “For example, the TCP statistics for flow 1 indicates that the number of retransmissions is 0 and the round trip time is 8,0/4,0, where 8,0 is the most recent measurement (8 ms RTT, with 0 ms variance) and where 4,0 is the previous measurement (4 ms RTT, with 0 ms variance). The SDN controller 125 may combine the flow path information and the TCP statistics to generate a combined data view (e.g., combined data view table 330).” para.0046 “FIG. 3B is a block diagram illustrating flows in a network that are experiencing a performance issue, according to some embodiments. In this example, a performance issue (e.g., long delay) experienced by flow 4 (between H1 and H5) triggers the RCA algorithm. When the SDN controller 125 updates its TCP statistics (shortly after flow 4 experiences a problem), the updated TCP statistics indicate that the number of retransmissions for flow 4 is 20 and the round trip time for flow 4 is higher at 32,0/16,0, where 32,0 is the most recent measurement (32 ms RTT, with 0 ms variance) and where 16,0 is the previous measurement (16 ms RTT, with 0 ms variance).” Fig. 3B shows a plurality of flows all experiencing network performance issues at the same time. For example, flow 1 and 4 can be experiencing higher RTT from 16 to 32, and flow 1 goes from 4ms to 8ms in view of Fig. 3A-B, at the same time when the SDN updates its TCP statistics.);
pinpointing, based on the localizing, a shared network infrastructure component within the localized network segment as a source of the network performance degradation impacting the communications (Mah: para.0054 “An RCA algorithm similar to that described with reference to FIG. 2 can then be applied to these flows to determine a root cause of the problem” the description of Fig. 4 includes the process of Fig. 2, para.0044 “ If all or most of the candidate problem links are connected to a single node, then this may indicate that there is a problem with that node. The candidate problem links could be physical links, virtual network links bridged in a software switch, for example, by a Link Aggregation Group (LAG). If the candidate problem link is a LAG, then extra steps can be taken to analyze the physical links within the LAG to determine which physical link is the source of the problem.” In the spec regarding the steps of Fig. 2, there is a secondary analysis after determining the candidate links that are likely to be the root cause. A particular node associated with those links may be identified, or if the candidate link is a LAG, link aggregation group which includes a plurality of links, a particular physical link from amongst the LAG may be identified to be the source of the problem, i.e. in both cases based on localizing the issue to a set of links and determining the source.)
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Rao with Mah in order to incorporate wherein identifying the network issue comprises: detecting a pattern of simultaneous network performance degradation across a plurality of the devices; real-time communications; localizing a network segment where the network performance degradation is occurring by correlating a timing and nature of the network performance degradation detected across the plurality of devices with network topology data that maps the plurality of devices to respective associated network paths, the correlating comprising identifying a simultaneous increase in the network performance degradation across the plurality of the devices; pinpointing, based on the localizing, a shared network infrastructure component within the localized network segment as a source of the network performance degradation impacting the communications, and apply this concept to the monitoring of real time communications as described in Rao.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of improving network analysis by reducing cost and simplification (Mah: para.0002-0004).
However Rao-Mah does not explicitly disclose in response to identifying the network issue, generating an alert directed to the shared network infrastructure component, the alert including a remediation action for the shared network infrastructure component.
Raj discloses in response to identifying the network issue, generating an alert directed to the shared network infrastructure component, the alert including a remediation action for the shared network infrastructure component (Raj: para.0064-para.0065 “Thereby, at step 755, the diagnostic server may identify the fault classification. As part of classifying the fault, the diagnostic server may also identify one or more fault sub-classes, for example: system fault, subsystem fault, component fault, service fault, device fault, data fault, global fault, etc….With reference to FIG. 7C, at step 760, the diagnostics server may obtain remedy rules/templates corresponding to the fault classification. At step 765, the diagnostics server may determine the remedy according to the fault classification. At step 770, the diagnostics server may identify corrective actions, and the corresponding hardware, software, data, or processes at which the corrective actions should be taken. At step 775, the diagnostics server may send corrective action messages to the identified hardware, software, or processes specifying the corrective actions.” Corrective actions for the identified network components of the issues may be sent to those components.).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Rao-Mah with that of Raj in order to incorporate in response to identifying the network issue, generating an alert directed to the shared network infrastructure component, the alert including a remediation action for the shared network infrastructure component.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of resolving the detected issue automatically (Raj: para.0064-0065)
Regarding Claim 2, Rao-Mah-Raj discloses claim 1 as set forth above.
Rao further discloses wherein receiving the network data from the devices participating in the real-time communications comprises: receiving latency data from the devices participating in the real-time communications (Rao: Fig. 4 408 lines 16-20 “ The interrogation module 114 may provide one or more interrogatory packets to the second network 102(2) and the third network 102(3) in-line, via the existing connection that is currently being used to provide voice packets 110 between the networks 102.” col. 20 lines 63-col. 21 line 5. “At 408, response data 122 from the second network 102(2) may be received by the first network 102(1). The response data 122 may include at least a portion of the metric data 118 corresponding to the metric request 208 provided in the interrogatory data 116.” Col. 14 lines 27-30 “The metric data 118 may include one or more of latency data 218, jitter data 220, packet loss data 222, or other metric data 224.” Latency data may be obtained);
receiving jitter data from the devices participating in the real-time communications (Rao: Fig. 4 408 col. 20 lines 63-col. 21 line 5. “At 408, response data 122 from the second network 102(2) may be received by the first network 102(1). The response data 122 may include at least a portion of the metric data 118 corresponding to the metric request 208 provided in the interrogatory data 116.” Col. 14 lines 27-30 “The metric data 118 may include one or more of latency data 218, jitter data 220, packet loss data 222, or other metric data 224.” Jitter data is obtained.); and
receiving packet loss data from the devices participating in the real-time communications (Rao: Fig. 4 408 col. 20 lines 63-col. 21 line 5. “At 408, response data 122 from the second network 102(2) may be received by the first network 102(1). The response data 122 may include at least a portion of the metric data 118 corresponding to the metric request 208 provided in the interrogatory data 116.” Col. 14 lines 27-30 “The metric data 118 may include one or more of latency data 218, jitter data 220, packet loss data 222, or other metric data 224.” Packet loss data is obtained. ).
Regarding Claim 3, Rao-Mah-Raj disclose claim 2 as set forth above.
Rao further discloses wherein identifying, based on the network data, the network issue impacting the quality of the real-time communications comprises: determining that the latency data exceeds a latency threshold (Rao: col. 15 lines 3-22 “Other metric data 224 may also include one or more threshold values. For example, a threshold value may indicate a latency, jitter, or packet loss value corresponding to a communication having an acceptable quality. Determination of deviation of one or more of the latency data 218, jitter data 220, packet loss data 222, or other metric data 224 from one or more threshold values may cause one or more notifications to be generated.” It can be determined that latency exceeds a threshold);
determining that the jitter data exceeds a jitter threshold (Rao: col. 15 lines 3-22 “For example, a threshold value may indicate a latency, jitter, or packet loss value corresponding to a communication having an acceptable quality. Determination of deviation of one or more of the latency data 218, jitter data 220, packet loss data 222, or other metric data 224 from one or more threshold values” it is determined that jitter exceeds a threshold); and
determining that the packet loss data exceeds a patent loss threshold (Rao: col. 15 lines 3-22 “For example, a threshold value may indicate a latency, jitter, or packet loss value corresponding to a communication having an acceptable quality. Determination of deviation of one or more of the latency data 218, jitter data 220, packet loss data 222, or other metric data 224 from one or more threshold values” it is determined that packet loss exceeds a threshold).
Regarding Claim 8, it teaches all the same steps as claim 1 but in A system, comprising: a memory module; and a processing circuitry, the processing circuitry configured to execute instructions stored in the memory module to (Rao: Fig. 8, col. 26 lines 51-col. 7 line 9). Therefore the supporting rationale for the rejection to claim 1 applies equally as well to that of claim 8.
Regarding Claim 9, Rao-Mah-Raj discloses claim 8 as set forth above.
However Rao does not explicitly disclose identify the shared network infrastructure component by referencing a configuration management database.
Mah discloses identify the shared network infrastructure component by referencing a configuration management database (Mah: para.0036 “The view of the network topology is commonly referred to as a network information base (NIB). The SDN controller 125 can use the NIB to determine the flow paths of flows in the network 100. In one embodiment, the SDN controller 125 can collect flow cache information and/or routing table information from the switches S1-S6 in the network 100, and use this information (along with knowledge of the network topology) to determine flow path information for flows in the network 100. In one embodiment, the forwarding scheme used in an SDN network can provide flow path information. The SDN controller 125 can make the flow path information available to the RCA algorithm.” Para.0053 “The process then identifies a common link shared between the flow and the one or more reference flows as a candidate problem link (block 430). …The flow path information for these flows can be obtained via the network monitoring system 120, as described above (e.g., based on NIB maintained by the SDN controller).”The computing device 110 in Fig. 1 that performs the RCA, root cause analysis, identifies the shared network infrastructure component by using topology information NIB from the SDN controller, a configuration management database that maintains an NIB comprising network configuration information.).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Rao with Mah in order to incorporate identify the shared network infrastructure component by referencing a configuration management database.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of improving network analysis by reducing cost and simplification (Mah: para.0002-0004).
Regarding Claim 10, Rao-Mah-Raj discloses claim 8 as set forth above.
However Rao does not explicitly disclose determine that the network issue is impacting multiple participants simultaneously and correlate the network issue to a specific network segment.
Mah discloses determine that the network issue is impacting multiple flows simultaneously and correlate the network issue to a specific network segment (Mah: para.0055 “In some cases, there can be multiple simultaneous failures in the network 100 (e.g., more than 1 link experiences congestion).” para.0053 “The process then identifies a common link shared between the flow and the one or more reference flows as a candidate problem link (block 430). The reference flows are the flows that are deemed to be experiencing a similar problem as the problematic flow. As such, a common link shared between the problematic flow and the reference flows is likely to be the root cause of the performance issue.” Simultaneous performance degradation is detected for a plurality of flows, and a common link may be identified)
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Rao with Mah in order to incorporate determine that the network issue is impacting multiple participants simultaneously and correlate the network issue to a specific network segment.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of improving network analysis by reducing cost and simplification (Mah: para.0002-0004).
Regarding Claim 13, Rao-Mah-Raj discloses claim 8 as set forth above.
Rao further discloses wherein the network data is received from network infrastructure devices, including routers and switches (Rao: col. 18 line 56-col. 19 line 10 “ In some implementations, device types 310 may include one or more sets of devices, such as devices within a particular geographic region, devices of a certain type (e.g., servers, modems, routers, switches, and so forth), devices associated with particular manufacturers, and so forth. For example, a metric request 208 may request metric data 118 associated with every destination network element 112 within a network 102, every SBC 108 within the network 102, each destination network element 112 used to provide a communication to a particular geographic region, each destination network element 112 used to facilitate a particular communication type 226, and so forth.” Col. 19 lines 31-35 “At 314, the response packet generated by the second network 102(2) may be received by the first network 102(1).” The request for metrics can be for metrics from every node in the network, including routers and switches, and the metrics in response to the request is received.).
Regarding Claim 14, Rao-Mah-Raj discloses claim 8 as set forth above.
Rao further discloses wherein the network issue is related to a malfunction in one of infrastructure devices (Rao: col. 209 lines 15-20 “For example, if the metric data 118 indicates significant latency associated with a particular device, that device may be repaired, replaced, deactivated, and so forth. Continuing the example, communications may be routed using alternate devices due to the latency associated with the particular device.” col. 21 lines 22-46 “For example, a particular destination network element 112 associated with the second network 102(2) may have a large quantity of latency associated therewith due to a current status of the destination network element 112 or the associated geographic region. The notification 416 may identify one or more devices associated with the variance 412. Providing the notification 416 to the second network 102(2) may enable one or more individuals associated with the second network 102(2) to correct the variance 412 by repairing or replacing deficient devices, routing communications using alternate devices, and so forth.” The network issue may be based on devices that are operating at a high latency, deficient, and/or needs to be repaired.).
Regarding Claim 15, it teaches all of the same steps as claim 1 but in One or more non-transitory computer readable media storing instructions operable to cause one or more processors to perform operations comprising (Rao: Fig. 8, col. 26 lines 51-64). Therefore the supporting rationale for the rejection to claim 1 applies equally as well to that of claim 15.
Regarding Claim 16, Rao-Mah-Raj discloses claim 15 as set forth above.
Rao further discloses the network issue is identified based on a latency threshold (Rao: col. 15 lines 3-22 “Other metric data 224 may also include one or more threshold values. For example, a threshold value may indicate a latency, jitter, or packet loss value corresponding to a communication having an acceptable quality. Determination of deviation of one or more of the latency data 218, jitter data 220, packet loss data 222, or other metric data 224 from one or more threshold values may cause one or more notifications to be generated.” It can be determined that latency exceeds a threshold)
wherein the latency threshold is set differently for different regions of a communication network based on expected network conditions (Rao: col. 10 lines 40-60 “The communication data 126 may also be used to determine potential errors, damage, or other deficiencies that may impact communication quality associated with one or more networks 102. For example, a notification module 132 may access threshold metric values associated with the one or more networks 102. The notification module 132 may determine that received metric data 118 associated with one or more networks 102 deviates from the threshold metric values by an amount equal to or exceeding a threshold variance.” col. 20 lines 21-39 “ At 402, one or more threshold metric values 404 associated with a network 102 may be determined based at least partially on communication data 126. For example, communication data 126 indicative of previous communications with a second network 102(2) may be accessed by a device associated with a first network 102(1). The communication data 126 may include metric data 118 previously received with regard to the second network 102(2). For example, the communication data 126 may include information regarding the latency of one or more devices associated with the second network 102(2) at previous time periods, based on a communication type 226 associated with previous communications.” Threshold metric values are based on past communication metrics of a particular network. Therefore for each of the networks 102 in 100 Fig. 1, a different region of a communication network, threshold values are set different as it is based on past metrics of that portion of the network.).
Regarding Claim 18, Rao-Mah-Raj discloses claim 15 as set forth above.
Rao further discloses wherein the network issue is identified when at least two of latency, jitter, or packet loss exceeds respective thresholds simultaneously (Rao: col. 15 lines 3-22 "Other metric data 224 may also include one or more threshold values. For example, a threshold value may indicate a latency, jitter, or packet loss value corresponding to a communication having an acceptable quality. Determination of deviation of one or more of the latency data 218, jitter data 220, packet loss data 222, or other metric data 224 from one or more threshold values may cause one or more notifications to be generated.” It can be determined that 2 of latency jitter and packet loss exceeds a threshold).
However Rao does not explicitly disclose wherein the network issue is identified when at least two of latency, jitter, or packet loss exceeds respective thresholds simultaneously.
Mah discloses wherein the network issue is identified when at least two failures occur simultaneously (Mah: para.0055 “In some cases, there can be multiple simultaneous failures in the network 100 (e.g., more than 1 link experiences congestion).” para.0053 “The process then identifies a common link shared between the flow and the one or more reference flows as a candidate problem link (block 430). The reference flows are the flows that are deemed to be experiencing a similar problem as the problematic flow. As such, a common link shared between the problematic flow and the reference flows is likely to be the root cause of the performance issue.” Simultaneous performance degradation is detected for a plurality of flows, and a common link may be identified)
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Rao with Mah in order to incorporate wherein the network issue is identified when at least two failures occur simultaneously, and apply this concept to the at least two of latency, jitter, or packet loss exceeds respective thresholds, as described in Rao.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of improving network analysis by reducing cost and simplification (Mah: para.0002-0004).
Regarding Claim 20, it does not teach nor further define over the limitations of claim 13, therefore the supporting rationale for the rejection of claim 13 applies equally as well to that of claim 20.
Claim(s) 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Rao (US 9,749,886 B1) in view of Mahkonen et al (hereinafter Mah, US 2017/0126475 A1) in view of Rajagopal et al. (hereinafter Raj, US 2015/0227404 A1) in view of Hermesh et al. (hereinafter Hermesh, US 2018/0288493 A1).
Regarding Claim 4, Rao-Mah-Raj discloses claim 1 as set forth above.
However while Rao analyzes bandwidth in col. 14 lines 28-30, and col. 15 lines 3-5 Rao-Mah-Raj does not disclose wherein generating the alert in response to identifying the network issue comprises: including in the alert that the network issue is related to at least one of a quality of service configuration or bandwidth saturation.
Hermesh discloses wherein generating the alert in response to identifying the network issue comprises: including in the alert that the network issue is related to at least one of a quality of service configuration or bandwidth saturation (Hermesh: para.0043 “In the illustrated example of FIG. 5, after startup, the STB bandwidth adjuster 320 of the vSTB 125 also sends an example notification registration message (AccessLoadNotificationRegister message) 425 to the vAF 110 to cause the vAF's load event notifier 220 to register the vSTB 125 with the vAF 110 for receiving notification messages transmitted by the vAF 110 when bandwidth utilization events (e.g., bandwidth utilization thresholds being reached by increasing/decreasing aggregate loads) are detected. Subsequently, the STB bandwidth adjuster 320 of the vSTB 125 is able to receive example notification messages (ThresholdNotify messages) 430 from the load event notifier 220 of the vAF 110 indicating or otherwise associated with bandwidth utilization events.” When bandwidth limits are reached, i.e. saturated, an alert is sent that indicates the bandwidth utilization event).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date to combine Rao-Mah-Raj with Hermesh in order to incorporate wherein generating the alert in response to identifying the network issue comprises: including in the alert that the network issue is related to at least one of a quality of service configuration or bandwidth saturation.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of performing a function to address the bandwidth issue (Hermesh: para.0043).
Claim(s) 5, 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Rao (US 9,749,886 B1) in view of Mahkonen et al (hereinafter Mah, US 2017/0126475 A1) in view of Rajagopal et al. (hereinafter Raj, US 2015/0227404 A1) in view of Meredith et al. (hereinafter Meredith, US 2013/0053023 A1).
Regarding Claim 5, Rao-Mah-Raj discloses claim 1 as set forth above.
However Rao-Mah-Raj does not explicitly disclose wherein generating the alert in response to identifying the network issue comprises: transmitting a request to create a ticket in a ticketing system based on the network issue.
Meredith discloses wherein generating the alert in response to identifying the network issue comprises: transmitting a request to create a ticket in a ticketing system (Meredith: para.0048 mobile network server) based on the network issue (Meredith: para.0048 “Reference component 206 can be configured to access a mobile network server (e.g., a base station ticketing server) and determine whether a base station failure associated with the deviation exists. … If not, reference component 206 can send a notice to data analysis component 202 that no failure ticket for this geographic area exists. In this case, data analysis component 202 will generate and issue a geographic repair ticket 208 identifying the geographic area, as provided by location component 204. … In at least one alternative example, reference component 206 can request the mobile network server to issue the geographic repair ticket, where such mobile network server is configured to issue a ticket identifying a geographic area independent of base station infrastructure equipment.” Upon identifying a base station failure, a request can be sent to the mobile network server to generate a repair ticket.).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Rao-Mah-Raj with that of Meredith in order to incorporate wherein generating the alert in response to identifying the network issue comprises: transmitting a request to create a ticket in a ticketing system based on the network issue.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of solving network issues (Meredith: para.0006).
Regarding Claim 19, it does not teach nor further define over the limitations in claim 5, therefore the supporting rationale for the rejection of claim 5 applies equally as well to that of claim 19.
Claim(s) 6-7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Rao (US 9,749,886 B1) in view of Mahkonen et al (hereinafter Mah, US 2017/0126475 A1) in view of Rajagopal et al. (hereinafter Raj, US 2015/0227404 A1) in view of Bergman (US 2015/0222536 A1).
Regarding Claim 6, Rao-Mah-Raj discloses claim 1 as set forth above.
However Rao-Mah-Raj does not explicitly disclose wherein identifying, based on the network data, the network issue impacting the quality of the real-time communications comprises: identifying a range of Internet Protocol (IP) addresses associated with the network issue.
Bergman discloses wherein identifying, based on the network data, the network issue impacting the quality of the real-time communications comprises: identifying a range of Internet Protocol (IP) addresses associated with the network issue (Bergman: para.0029 “Once it is determined that the communication between user device 440 and content server 410 meets the condition or exceeds the threshold, content server 410 is configured to modify the communication path for the user device. In some examples, content server 410 may define IP groups for the user devices that are affected by the latency or performance of the communication. These IP groups may be defined by a range of IP addresses that likely share a user ISP provider or that may be routed through the same or similar connection path in arriving at content server 410.” A range of ip addresses that are effected by the network issue may be determined.).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Rao-Mah-Raj with Bergman in order to incorporate wherein identifying, based on the network data, the network issue impacting the quality of the real-time communications comprises: identifying a range of Internet Protocol (IP) addresses associated with the network issue.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of solving issues for multiple devices based on addresses of devices that may be effected by the same issue (Bergman: para.0029).
Regarding Claim 7 Rao-Mah-Raj -Bergman discloses claim 6 as set forth above.
Rao further discloses devices or users participating in the real-time communications (Rao: Fig. 4 408 col. 20 lines 63-col. 21 line 5. “At 408, response data 122 from the second network 102(2) may be received by the first network 102(1). The response data 122 may include at least a portion of the metric data 118 corresponding to the metric request 208 provided in the interrogatory data 116. For example, responsive to a request for metric data 118 indicative of the latency of one or more destination network elements 112, the response data 122 may include latency data 218 indicative of the latency of one or more devices associated with the second network 102(2).” Col. 7 lines 16-20 “ The interrogation module 114 may provide one or more interrogatory packets to the second network 102(2) and the third network 102(3) in-line, via the existing connection that is currently being used to provide voice packets 110 between the networks 102.” Metrics are obtained from devices that are communicating using real time communications, such as voice communication. ).
However Rao-Mah-Raj does not explicitly disclose correlating the range of IP addresses with specific devices or users participating in the real-time communications.
Bergman discloses correlating the range of IP addresses with specific devices or users participating in the content delivery (Bergman: para.0029 “These IP groups may be defined by a range of IP addresses that likely share a user ISP provider or that may be routed through the same or similar connection path in arriving at content server 410. Accordingly, content server 410 may be configured to change the communication path for all similar or related devices in the IP group based on the attainment of a performance condition by at least one of the devices.” Para.0043 “In some examples, content server 610 may classify devices within a range of IP addresses as being effected by the performance or latency issues. As a result, when end user device 640 reaches the performance condition, a range of IP addresses near the IP address for end user device 640 may also have their path redirected.” The range of ip addresses is correlated with devices that have a nearby ip address in order to determine which devices have their communication path changed.).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Rao-Mah-Raj with Bergman in order to incorporate correlating the range of IP addresses with specific devices or users participating in the content delivery, and apply this concept to the devices or users participating the in the real time communication service as in Rao.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of solving issues for multiple devices based on addresses of devices that may be effected by the same issue (Bergman: para.0029).
Claim(s) 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Rao (US 9,749,886 B1) in view of Mahkonen et al (hereinafter Mah, US 2017/0126475 A1) in view of Rajagopal et al. (hereinafter Raj, US 2015/0227404 A1) in view of Bergman (US 2015/0222536 A1) in view of Sargent (US 2008/0250128 A1).
Regarding Claim 11, Rao-Mah-Raj discloses claim 8 as set forth above.
However Rao-Mah-Raj does not explicitly disclose wherein the processing circuitry configured to execute instructions stored in the memory module to: identify a physical location based on a range of Internet Protocol (IP) addresses associated with the network issue.
Bergman discloses a range of Internet Protocol (IP) addresses associated with the network issue (Bergman: para.0029 “Once it is determined that the communication between user device 440 and content server 410 meets the condition or exceeds the threshold, content server 410 is configured to modify the communication path for the user device. In some examples, content server 410 may define IP groups for the user devices that are affected by the latency or performance of the communication. These IP groups may be defined by a range of IP addresses that likely share a user ISP provider or that may be routed through the same or similar connection path in arriving at content server 410.” A range of ip addresses that are effected by the network issue may be determined.).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Rao-Mah-Raj with Bergman in order to incorporate a range of Internet Protocol (IP) addresses associated with the network issue.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of solving issues for multiple devices based on addresses of devices that may be affected by the same issue (Bergman: para.0029).
However Rao-Mah-Raj -Bergman does not explicitly disclose identify a physical location based on a range of Internet Protocol (IP) addresses associated with the network issue.
Sargent discloses identify a physical location based on a range of Internet Protocol (IP) addresses (Sargent: para.0071 “This grouping can be achieved when a partial mapping of IP addresses to geographic location is available to the manager. For example, it may be know that a certain range of IP addresses are associated with a given office location of a corporation.” Address ranges are associated with locations.).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date to combine Rao-Mah-Raj -Bergman with Sargent in order to incorporate identify a physical location based on a range of Internet Protocol (IP) addresses.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of identifying anomalies of a particular location (Sargent para.0071).
Claim(s) 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Rao (US 9,749,886 B1) in view of Mahkonen et al (hereinafter Mah, US 2017/0126475 A1) in view of Rajagopal et al. (hereinafter Raj, US 2015/0227404 A1) in view of Tiwari et al. (hereinafter Tiwari, US 2021/0256397 A1).
Regarding Claim 12, Rao-Mah-Raj discloses claim 8 as set forth above.
However Rao-Mah-Raj does not explicitly disclose wherein the alert includes a recommended action to resolve the network issue.
Tiwari discloses wherein the alert includes a recommended action to resolve the network issue (Tiwari: para.0046 “In addition to, or instead of, illustrative embodiments automatically performing the set of action steps, illustrative embodiments send a notification to a system or security analyst, for example, regarding the root cause of the anomaly and recommending the set of action steps to be taken to pre-empt or remediate the anomaly.” The notification may include the anomaly/cause as well as the recommended actions to remedy the situation).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date to combine Rao-Mah-Raj with Tiwari in order to incorporate wherein the alert includes a recommended action to resolve the network issue.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of improved resolution of a network issue (Tiwari: para.0046, para.0065).
Claim(s) 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Rao (US 9,749,886 B1) in view of Mahkonen et al (hereinafter Mah, US 2017/0126475 A1) in view of Rajagopal et al. (hereinafter Raj, US 2015/0227404 A1) in view of Klinker et al. (hereinafter Klinker, US 2006/0182034 A1).
Regarding Claim 17, Rao-Mah-Raj discloses claim 15 as set forth above.
Rao further discloses receiving network routing data receiving network routing data (Rao: col. 10 lines 40-60 “The metric data 118 received in the response data 122 may be associated with a particular communication type 226. For example, certain networks 102 and certain destination network elements 112 may experience a first quantity of latency when routing a communication of first communication type 226 and a second quantity of latency when routing a communication of a second communication type 226.” The metrics obtained include information regarding routing.)
However Rao-Mah-Raj does not explicitly disclose the operations further comprising: and identifying that the network issue relates to improper routing or routing loops.
Klinker discloses the operations further comprising: identifying that the network issue relates to improper routing or routing loops (Klinker: para.0304 “This in-depth topology analysis allows the system to determine some root cause analysis for each network event or performance problem that is seen. Events include but are not limited to routing loops, black holes, high congestion, peering problems, and other routing anomalies.” Routing loops may be identified as the network issue).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date to combine Rao-Mah-Raj with Klinker in order to incorporate identifying that the network issue relates to improper routing or routing loops.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of improved network performance (Klinker: para.0200, 0211).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Garvey et al. US 2020/0267057 A1 see para.0035, Fig. 3, 9c root cause analysis based on correlation of anomalies and time series data.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to EUI H KIM whose telephone number is (571)272-8133. The examiner can normally be reached 7:30-5 M-R, M-F alternating.
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, Kamal B Divecha can be reached at 5712725863. 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.
/EUI H KIM/ Examiner, Art Unit 2453
/KAMAL B DIVECHA/ Supervisory Patent Examiner, Art Unit 2453
Prosecution Insights