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 .
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1, 3-9, 11-17 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Jividen (US 20230016199 A1) hereafter Jividen.
Regarding Claim 1:
Jividen discloses:
A method ([Abstract] This disclosure describes systems, devices, and techniques for determining a root cause of anomalous events ) comprising: receiving, at one or more processing devices, a first set of performance data from a user equipment (UE) within a radio access network (RAN), the first set of performance data being associated with a triggering event and including a plurality of parameters associated with the UE connectivity to the RAN;([¶0035] The root cause manager 108 includes an alert aggregator 218, the alert aggregator 218 may acquire data from the network and aggregate the data. The aggregated data may include alarms or alerts generated by the components and applications being monitored, [¶0040] The aggregated data may include device-level data associated with device level performance metrics[¶0069] If another alert (e.g., “Alert 2”) is detected by the server 108 at operation 616, then process 602 proceeds to operation 618. As shown in the example, ) receiving, at the one or more processing devices, from one or more network components within the RAN, a second set of performance data associated with the triggering event, the second set of performance data representing performance of the RAN network; ([¶0035] The root cause manager 108 includes an alert aggregator 218, the alert aggregator 218 may acquire data from the network and aggregate the data. The aggregated data may include alarms or alerts generated by the components and applications being monitored, [¶0040] The aggregated data may include device-level data associated with device level performance metrics[¶0067] At operation 614, the server 108 detects an alert (“Alert 1”) that has been generated by component “A” 604. The alert may be detected, for example, by a sensor at the component “A” 604 that monitors the component for a variety of factors. ) identifying, by the one or more processing devices, based on the first and second sets of performance data, a root cause for the triggering event;([¶0072] the root cause of an anomalous event may be uncertain—e.g., a root cause may be identified but the likelihood of another root cause existing is probable. For example, and with reference to the topological relationship graph 600, suppose for purposes of discussion that component “A” 604 and component “E” 608 generate alerts related to an anomalous event. The server 108 will initially determine the indirect dependency between component “A” 604 and component “E” 608 and correlate any alerts that are detected. If the server 108 determines that the root cause of an anomalous event is component “E” 608) identifying an action to be performed by the UE to address the root cause; and transmitting, by the one or more processing devices, a signal configured to instruct an application on the UE to perform the action to address the identified root cause. ([¶0072] for example since it is the lowest dependent component in the topological relationship graph 600, an incident ticket will be generated and sent to the persons or entities responsible for handling the root cause of component “E” 608. A notification may also be sent to the persons or entities of component “A” 604 informing them that a performance issue exists within the dependency chain, and that component “E” is a potential root cause of the anomalous event. If, for example, the persons or entities handling resolution of the anomalous event for component “E” 608 determine that component “E” 608 is not the root cause of the anomalous event, the alert may be automatically or manually adjusted, and an updated incident ticket and notification may be sent to component “A” 604 informing them that the root cause has been updated to component “A” 604.))
Regarding Claim 3:
Jividen discloses the limitations of parent claims.
Jividen discloses:
comprising: storing the first and second set of performance data at a first memory location configured to be refreshed with incoming performance data corresponding to a predetermined period of time; ([¶0035] The alert aggregator 218 may aggregate data upon detection of a particular event (e.g., upon detection of an application failure) or may aggregate data periodically (e.g., every 5 minutes) and store the aggregated data in storage, such as database 112 or 120. )in response to occurrence of the triggering event, copying information from the first memory location to a second memory location, wherein the second memory location is configured to store performance data corresponding to multiple refresh cycles of the first memory location. ([¶0035] The causal relationship mapper 220 may map the alerts to nodes in a causal relationship graph. The alerts may be associated with a description of the underlying failure detected and a timestamp or time value for when the underlying failure occurred. In one example embodiment, the alerts are enriched with metadata (e.g., information about the network, resources, components, applications, etc.). [¶0036
Regarding Claim 4:
Jividen discloses the limitations of parent claims.
Jividen discloses:
wherein a triggering event comprises, a dropped voice call, a dropped video call, no network connectivity, uploading time exceeding an uploading threshold time, or downloading time exceeding a downloading threshold time. ([¶0040] In some example embodiments, the root cause manager 122 may aggregate data from one or more IT management software tools periodically or in response to a service-level performance issue being detected (e.g., a service is no longer available to an end user of the service). The aggregated data may include service-level data related to a service provided by the networked computing environment 100, such as the availability of the service and response times associated with the service. The service may require applications to be available (e.g., an online personal information manager may require a word processing application, an email application, and a database application to be available). The aggregated data may include application-level data related to the applications, such as a status of each of the applications (e.g., currently running, halted, or terminated) and an identification of a first set of servers which are running the applications. The aggregated data may include networking-level data associated with networks connected to the first set of servers, such as the resources available in the network and network utilization metrics. The aggregated data may include virtualization-level data associated with the performance of virtual machines on which applications are running. The aggregated data may include device-level data associated with device level performance metrics (e.g., computing device utilization or storage device utilization). From the aggregated data corresponding with the different perspectives offered by the IT management software tools, the root cause manager 122 may determine causal relationships between failures occurring at different layers within a hierarchy (e.g., represented as directed edges between failed nodes in a directed acyclic graph) and identify a root cause of a service-level performance issue based on the causal relationships.)
Regarding Claim 5:
Jividen discloses the limitations of parent claims.
Jividen discloses:
wherein the second set of performance data comprises one or more of: network strength data, radio unit function data, transport path congestion/latency metric level and distributed unit function data. ([¶0040] In some example embodiments, the root cause manager 122 may aggregate data from one or more IT management software tools periodically or in response to a service-level performance issue being detected (e.g., a service is no longer available to an end user of the service). The aggregated data may include service-level data related to a service provided by the networked computing environment 100, such as the availability of the service and response times associated with the service. The service may require applications to be available (e.g., an online personal information manager may require a word processing application, an email application, and a database application to be available). The aggregated data may include application-level data related to the applications, such as a status of each of the applications (e.g., currently running, halted, or terminated) and an identification of a first set of servers which are running the applications. The aggregated data may include networking-level data associated with networks connected to the first set of servers, such as the resources available in the network and network utilization metrics. The aggregated data may include virtualization-level data associated with the performance of virtual machines on which applications are running. The aggregated data may include device-level data associated with device level performance metrics (e.g., computing device utilization or storage device utilization). From the aggregated data corresponding with the different perspectives offered by the IT management software tools, the root cause manager 122 may determine causal relationships between failures occurring at different layers within a hierarchy (e.g., represented as directed edges between failed nodes in a directed acyclic graph) and identify a root cause of a service-level performance issue based on the causal relationships.)
Regarding Claim 6:
Jividen discloses the limitations of parent claims.
Jividen discloses:
further comprising: determining, by the one or more processing devices, based on the first and second sets of performance data that a root cause for the triggering event is not found; in response to determining that the root cause for the triggering event is not found, communicating, by the one or more processing devices, to an application server, the first and second sets of performance data; receiving, by the application server, a third set of performance data from one or more additional components within the RAN; accessing, by the application server, a machine learning model trained to determine a root cause for a triggering event based on performance; determining, by the application server, based on an output of the machine learning model, a root cause for the triggering event; and generating, by the application server, a signal configured to trigger a remedial action. ([¶0036] In one example embodiment, nodes in a causal relationship graph (not shown) may correspond with an individual alert or a collection of alerts aggregated by the alert aggregator 218. In another example embodiment, each node in the causal relationship graph may correspond with a particular type of alert at a particular level in a networked computing environment hierarchy (e.g., CPU utilization alerts associated with a particular server or application performance alerts associated with a particular application). In some example cases, a causal relationship graph may be generated for each alert generated. The causal relationship graph may include directed edges with a causal relationship between pairs of nodes in the graph. A directed edge in the graph may represent that a first failure is a direct consequence of another failure. For example, the first failure may correspond with a first node (e.g., a first component) in the graph with a directed edge to a second node (e.g., a second component) in the graph corresponding with a second failure that is a direct consequence of the first failure. In this case, the directed edge represents a causal relationship between the first failure and the second failure. In one example embodiment, the graph may be a directed acyclic graph (DAC). In another example embodiment, the graph may be a Bayesian network with causal relationship probabilities assigned to each of the directed edges. The causal relationship probabilities may be stored, for example, in database 112 or 120. In this case, the structure of the graph and the assigned probabilities may be learned from the aggregated data. In one further example, the graph structure of the Bayesian network may be determined using machine learning techniques based on the aggregated data and changes in the aggregated data over time (e.g., the aggregated data stored in the database may be used as training data for learning the causal relationships between the nodes over time). Additional example embodiments are discussed below. [¶0037] The causal relationship mapper 220 may also identify a chain of failures beginning from a first node in the failure graph (e.g., a leaf node) and ending at a root node of the graph. The root node of the graph may correspond with the highest-level alert and the leaf nodes of the graph may correspond with root causes of the highest-level alert. The leaf nodes may comprise nodes without any predecessor nodes or nodes without any incoming directed edges from another node in the graph. A chain of failures may comprise a set of nodes along a path from a leaf node in the graph to the root node of the graph. In one example embodiment, the causal relationship mapper 220 may identify a particular chain of failures based on a number of alerts that are a consequence of the leaf node of the particular chain of failures. For example, the particular chain of failures may include a leaf node in which fixing the failure associated with the leaf node will fix the greatest number of unresolved alerts. [¶0038] The incident ticket generator 222 may generate and transmit a report to a user of the report based on an identified chain of failures. In one example embodiment, the incident ticket generator 222 may identify a role associated with a user and output an incident report or ticket to the user based on the user's role. For example, the role of the user may be determined based on a username, an employee identification number, or an email address associated with the user. In one example, a person with a technical role within an insurance organization may receive a report with technical information (e.g., server utilization information). While a person with a non-technical role within the insurance organization may receive a report with business-focused information (e.g., the number of people who can currently connect to a particular application or the estimated downtime for the particular application). [¶0043] Any detected alerts may be stored in memory 118 or database 120. In one embodiment, the alerts may be stored with a timestamp or time value and information about the component or application and resource associated with the detected alert. The information may be gleaned, for example, by rules defined to monitor various resources within the networked computing environment 100 and to capture information relating to performance and other issues for those resources. In one example embodiment, the alerts may be grouped or organized into historical alerts for later use and retrieval. For example, the historical alerts may be used as input into a machine learning model in which to assist in categorizing future alerts as they are detected in the system. )
Regarding Claim 7:
Jividen discloses the limitations of parent claims.
Jividen discloses:
wherein generating a signal configured to trigger a remedial action comprises, generating a signal to instruct at least one component of the RAN to perform an action. ([¶0049] Once a root cause of the anomalous event has been identified, an incident (or support) ticket generated by the incident ticket generator 220 may be sent to the nodes identified as the root cause of the anomalous event,)
Regarding Claim 8:
Jividen discloses the limitations of parent claims.
Jividen discloses:
wherein generating a signal configured to trigger a remedial action comprises, generating a signal to instruct the one or more processing devices to instruct the UE to perform an action. ([¶0049] Once a root cause of the anomalous event has been identified, an incident (or support) ticket generated by the incident ticket generator 220 may be sent to the nodes identified as the root cause of the anomalous event,)
Regarding Claim 9:
Jividen discloses:
A system([Abstract] This disclosure describes systems, devices, and techniques for determining a root cause of anomalous events ) comprising: one or more computers and one or more storage devices on which are stored instructions that are operable, when executed by the one or more computers, to cause the one or more computers to perform operations comprising: receiving, at one or more processing devices, a first set of performance data from a user equipment (UE) within a radio access network (RAN), the first set of performance data being associated with a triggering event and including a plurality of parameters associated with the UE connectivity to the RAN;([¶0035] The root cause manager 108 includes an alert aggregator 218, the alert aggregator 218 may acquire data from the network and aggregate the data. The aggregated data may include alarms or alerts generated by the components and applications being monitored, [¶0040] The aggregated data may include device-level data associated with device level performance metrics[¶0069] If another alert (e.g., “Alert 2”) is detected by the server 108 at operation 616, then process 602 proceeds to operation 618. As shown in the example, ) receiving, at the one or more processing devices, from one or more network components within the RAN, a second set of performance data associated with the triggering event, the second set of performance data representing performance of the RAN network; ([¶0035] The root cause manager 108 includes an alert aggregator 218, the alert aggregator 218 may acquire data from the network and aggregate the data. The aggregated data may include alarms or alerts generated by the components and applications being monitored, [¶0040] The aggregated data may include device-level data associated with device level performance metrics[¶0067] At operation 614, the server 108 detects an alert (“Alert 1”) that has been generated by component “A” 604. The alert may be detected, for example, by a sensor at the component “A” 604 that monitors the component for a variety of factors. ) identifying, by the one or more processing devices, based on the first and second sets of performance data, a root cause for the triggering event;([¶0072] the root cause of an anomalous event may be uncertain—e.g., a root cause may be identified but the likelihood of another root cause existing is probable. For example, and with reference to the topological relationship graph 600, suppose for purposes of discussion that component “A” 604 and component “E” 608 generate alerts related to an anomalous event. The server 108 will initially determine the indirect dependency between component “A” 604 and component “E” 608 and correlate any alerts that are detected. If the server 108 determines that the root cause of an anomalous event is component “E” 608) identifying an action to be performed by the UE to address the root cause; and transmitting, by the one or more processing devices, a signal configured to instruct an application on the UE to perform the action to address the identified root cause. ([¶0072] for example since it is the lowest dependent component in the topological relationship graph 600, an incident ticket will be generated and sent to the persons or entities responsible for handling the root cause of component “E” 608. A notification may also be sent to the persons or entities of component “A” 604 informing them that a performance issue exists within the dependency chain, and that component “E” is a potential root cause of the anomalous event. If, for example, the persons or entities handling resolution of the anomalous event for component “E” 608 determine that component “E” 608 is not the root cause of the anomalous event, the alert may be automatically or manually adjusted, and an updated incident ticket and notification may be sent to component “A” 604 informing them that the root cause has been updated to component “A” 604.))
Regarding Claim 11:
Jividen discloses the limitations of parent claims.
Jividen discloses:
comprising: storing the first and second set of performance data at a first memory location configured to be refreshed with incoming performance data corresponding to a predetermined period of time;([¶0035] The alert aggregator 218 may aggregate data upon detection of a particular event (e.g., upon detection of an application failure) or may aggregate data periodically (e.g., every 5 minutes) and store the aggregated data in storage, such as database 112 or 120. ) in response to occurrence of the triggering event, copying information from the first memory location to a second memory location, wherein the second memory location is configured to store performance data corresponding to multiple refresh cycles of the first memory location.
Regarding Claim 12:
Jividen discloses the limitations of parent claims.
Jividen discloses:
wherein a triggering event comprises, a dropped voice call, a dropped video call, no network connectivity, uploading time exceeding an uploading threshold time, or downloading time exceeding a downloading threshold time. ([¶0040] In some example embodiments, the root cause manager 122 may aggregate data from one or more IT management software tools periodically or in response to a service-level performance issue being detected (e.g., a service is no longer available to an end user of the service). The aggregated data may include service-level data related to a service provided by the networked computing environment 100, such as the availability of the service and response times associated with the service. The service may require applications to be available (e.g., an online personal information manager may require a word processing application, an email application, and a database application to be available). The aggregated data may include application-level data related to the applications, such as a status of each of the applications (e.g., currently running, halted, or terminated) and an identification of a first set of servers which are running the applications. The aggregated data may include networking-level data associated with networks connected to the first set of servers, such as the resources available in the network and network utilization metrics. The aggregated data may include virtualization-level data associated with the performance of virtual machines on which applications are running. The aggregated data may include device-level data associated with device level performance metrics (e.g., computing device utilization or storage device utilization). From the aggregated data corresponding with the different perspectives offered by the IT management software tools, the root cause manager 122 may determine causal relationships between failures occurring at different layers within a hierarchy (e.g., represented as directed edges between failed nodes in a directed acyclic graph) and identify a root cause of a service-level performance issue based on the causal relationships.)
Regarding Claim 13:
Jividen discloses the limitations of parent claims.
Jividen discloses:
wherein the second set of performance data comprises one or more of: network strength data, radio unit function data, and distributed unit function data. ([¶0040] In some example embodiments, the root cause manager 122 may aggregate data from one or more IT management software tools periodically or in response to a service-level performance issue being detected (e.g., a service is no longer available to an end user of the service). The aggregated data may include service-level data related to a service provided by the networked computing environment 100, such as the availability of the service and response times associated with the service. The service may require applications to be available (e.g., an online personal information manager may require a word processing application, an email application, and a database application to be available). The aggregated data may include application-level data related to the applications, such as a status of each of the applications (e.g., currently running, halted, or terminated) and an identification of a first set of servers which are running the applications. The aggregated data may include networking-level data associated with networks connected to the first set of servers, such as the resources available in the network and network utilization metrics. The aggregated data may include virtualization-level data associated with the performance of virtual machines on which applications are running. The aggregated data may include device-level data associated with device level performance metrics (e.g., computing device utilization or storage device utilization). From the aggregated data corresponding with the different perspectives offered by the IT management software tools, the root cause manager 122 may determine causal relationships between failures occurring at different layers within a hierarchy (e.g., represented as directed edges between failed nodes in a directed acyclic graph) and identify a root cause of a service-level performance issue based on the causal relationships.)
Regarding Claim 14:
Jividen discloses the limitations of parent claims.
Jividen discloses:
further comprising: determining, by the one or more processing devices, based on the first and second sets of performance data that a root cause for the triggering event is not found; in response to determining that the root cause for the triggering event is not found, communicating, by the one or more processing devices, to an application server, the first and second sets of performance data; receiving, by the application server, a third set of performance data from one or more additional components within the RAN; accessing, by the application server, a machine learning model trained to determine a root cause for a triggering event based on performance; determining, by the application server, based on an output of the machine learning model, a root cause for the triggering event; and generating, by the application server, a signal configured to trigger a remedial action. ([¶0036] In one example embodiment, nodes in a causal relationship graph (not shown) may correspond with an individual alert or a collection of alerts aggregated by the alert aggregator 218. In another example embodiment, each node in the causal relationship graph may correspond with a particular type of alert at a particular level in a networked computing environment hierarchy (e.g., CPU utilization alerts associated with a particular server or application performance alerts associated with a particular application). In some example cases, a causal relationship graph may be generated for each alert generated. The causal relationship graph may include directed edges with a causal relationship between pairs of nodes in the graph. A directed edge in the graph may represent that a first failure is a direct consequence of another failure. For example, the first failure may correspond with a first node (e.g., a first component) in the graph with a directed edge to a second node (e.g., a second component) in the graph corresponding with a second failure that is a direct consequence of the first failure. In this case, the directed edge represents a causal relationship between the first failure and the second failure. In one example embodiment, the graph may be a directed acyclic graph (DAC). In another example embodiment, the graph may be a Bayesian network with causal relationship probabilities assigned to each of the directed edges. The causal relationship probabilities may be stored, for example, in database 112 or 120. In this case, the structure of the graph and the assigned probabilities may be learned from the aggregated data. In one further example, the graph structure of the Bayesian network may be determined using machine learning techniques based on the aggregated data and changes in the aggregated data over time (e.g., the aggregated data stored in the database may be used as training data for learning the causal relationships between the nodes over time). Additional example embodiments are discussed below. [¶0037] The causal relationship mapper 220 may also identify a chain of failures beginning from a first node in the failure graph (e.g., a leaf node) and ending at a root node of the graph. The root node of the graph may correspond with the highest-level alert and the leaf nodes of the graph may correspond with root causes of the highest-level alert. The leaf nodes may comprise nodes without any predecessor nodes or nodes without any incoming directed edges from another node in the graph. A chain of failures may comprise a set of nodes along a path from a leaf node in the graph to the root node of the graph. In one example embodiment, the causal relationship mapper 220 may identify a particular chain of failures based on a number of alerts that are a consequence of the leaf node of the particular chain of failures. For example, the particular chain of failures may include a leaf node in which fixing the failure associated with the leaf node will fix the greatest number of unresolved alerts. [¶0038] The incident ticket generator 222 may generate and transmit a report to a user of the report based on an identified chain of failures. In one example embodiment, the incident ticket generator 222 may identify a role associated with a user and output an incident report or ticket to the user based on the user's role. For example, the role of the user may be determined based on a username, an employee identification number, or an email address associated with the user. In one example, a person with a technical role within an insurance organization may receive a report with technical information (e.g., server utilization information). While a person with a non-technical role within the insurance organization may receive a report with business-focused information (e.g., the number of people who can currently connect to a particular application or the estimated downtime for the particular application). [¶0043] Any detected alerts may be stored in memory 118 or database 120. In one embodiment, the alerts may be stored with a timestamp or time value and information about the component or application and resource associated with the detected alert. The information may be gleaned, for example, by rules defined to monitor various resources within the networked computing environment 100 and to capture information relating to performance and other issues for those resources. In one example embodiment, the alerts may be grouped or organized into historical alerts for later use and retrieval. For example, the historical alerts may be used as input into a machine learning model in which to assist in categorizing future alerts as they are detected in the system. )
Regarding Claim 15:
Jividen discloses the limitations of parent claims.
Jividen discloses:
wherein generating a signal configured to trigger a remedial action comprises, generating a signal to instruct at least one component of the RAN to perform an action. ([¶0049] Once a root cause of the anomalous event has been identified, an incident (or support) ticket generated by the incident ticket generator 220 may be sent to the nodes identified as the root cause of the anomalous event,)
Regarding Claim 16:
Jividen discloses the limitations of parent claims.
Jividen discloses:
wherein generating a signal configured to trigger a remedial action comprises, generating a signal to instruct the one or more processing devices to instruct the UE to perform an action. ([¶0049] Once a root cause of the anomalous event has been identified, an incident (or support) ticket generated by the incident ticket generator 220 may be sent to the nodes identified as the root cause of the anomalous event,)
Regarding Claim 17:
Jividen discloses:
One or more non-transitory computer storage media encoded with computer program instructions that when executed by one or more computers cause the one or more computers to perform operations ([¶0077] The chipset 706 provides an interface between the CPUs 704 and the remainder of the components and devices on the baseboard 702. The chipset 706 can provide an interface to a RAM 708, used as the main memory in the computer 700. The chipset 706 can further provide an interface to a computer-readable storage medium such as a read-only memory (“ROM”) 710 or non-volatile RAM (“NVRAM”) for storing basic routines that help to startup the computer 700 and to transfer information between the various components and devices. The ROM 710 or NVRAM can also store other software components necessary for the operation of the computer 700 in accordance with the configurations described herein.[¶0083] computer-readable storage media can include volatile and non-volatile, removable and non-removable media implemented in any method or technology. Computer-readable storage media includes, but is not limited to, RAM, ROM, erasable programmable ROM (“EPROM”), electrically-erasable programmable ROM (“EEPROM”), flash memory or other solid-state memory technology, compact disc ROM (“CD-ROM”), digital versatile disk (“DVD”), high definition DVD (“HD-DVD”), BLU-RAY, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information in a non-transitory fashion. ) comprising: receiving, at one or more processing devices, a first set of performance data from a user equipment (UE) within a radio access network (RAN), the first set of performance data being associated with a triggering event and including a plurality of parameters associated with the UE connectivity to the RAN;([¶0035] The root cause manager 108 includes an alert aggregator 218, the alert aggregator 218 may acquire data from the network and aggregate the data. The aggregated data may include alarms or alerts generated by the components and applications being monitored, [¶0040] The aggregated data may include device-level data associated with device level performance metrics[¶0069] If another alert (e.g., “Alert 2”) is detected by the server 108 at operation 616, then process 602 proceeds to operation 618. As shown in the example, ) receiving, at the one or more processing devices, from one or more network components within the RAN, a second set of performance data associated with the triggering event, the second set of performance data representing performance of the RAN network; ([¶0035] The root cause manager 108 includes an alert aggregator 218, the alert aggregator 218 may acquire data from the network and aggregate the data. The aggregated data may include alarms or alerts generated by the components and applications being monitored, [¶0040] The aggregated data may include device-level data associated with device level performance metrics[¶0067] At operation 614, the server 108 detects an alert (“Alert 1”) that has been generated by component “A” 604. The alert may be detected, for example, by a sensor at the component “A” 604 that monitors the component for a variety of factors. ) identifying, by the one or more processing devices, based on the first and second sets of performance data, a root cause for the triggering event;([¶0072] the root cause of an anomalous event may be uncertain—e.g., a root cause may be identified but the likelihood of another root cause existing is probable. For example, and with reference to the topological relationship graph 600, suppose for purposes of discussion that component “A” 604 and component “E” 608 generate alerts related to an anomalous event. The server 108 will initially determine the indirect dependency between component “A” 604 and component “E” 608 and correlate any alerts that are detected. If the server 108 determines that the root cause of an anomalous event is component “E” 608) identifying an action to be performed by the UE to address the root cause; and transmitting, by the one or more processing devices, a signal configured to instruct an application on the UE to perform the action to address the identified root cause. ([¶0072] for example since it is the lowest dependent component in the topological relationship graph 600, an incident ticket will be generated and sent to the persons or entities responsible for handling the root cause of component “E” 608. A notification may also be sent to the persons or entities of component “A” 604 informing them that a performance issue exists within the dependency chain, and that component “E” is a potential root cause of the anomalous event. If, for example, the persons or entities handling resolution of the anomalous event for component “E” 608 determine that component “E” 608 is not the root cause of the anomalous event, the alert may be automatically or manually adjusted, and an updated incident ticket and notification may be sent to component “A” 604 informing them that the root cause has been updated to component “A” 604.))
Allowable Subject Matter
Claims 2 and 10 objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Prior Art not relied on
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. US 20230011452 A1.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HUGH MARK ASHLEY whose telephone number is (571)272-0199. The examiner can normally be reached M-F 8-430.
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, Asad Nawaz can be reached at (571) 272-3988. 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.
/HUGH MARK ASHLEY/Examiner, Art Unit 2463
/ASAD M NAWAZ/Supervisory Patent Examiner, Art Unit 2463
Prosecution Insights