DETAILED ACTION
The applicant’s amendment filed on October 1, 2025 has been acknowledged. Claims 8, 9, 17 and 18 have been canceled. Claims 21-24 have been added. Claims 1-7, 10-16 and 19-24, as amended, are currently pending and have been considered below.
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 § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-7, 10-16 and 21-24 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
In claim 1, the term “most important” in claim line 9 of claim 1 is a relative term which renders the claim indefinite. The term “most important” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. The claims fail to establish how the APIs or KPIs are deemed to be more important or most important in relation to the other APIs or KPIs. As stated in the rejection the term is broad enough to allow for any relevant or necessary APIs or KPIs to identify anomalies.
In claim 10, the term “most important” in claim line 9 of claim 1 is a relative term which renders the claim indefinite. The term “most important” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. The claims fail to establish how the APIs or KPIs are deemed to be more important or most important in relation to the other APIs or KPIs. As stated in the rejection the term is broad enough to allow for any relevant or necessary APIs or KPIs to identify anomalies.
Claims 2-7, 21 and 22 depend from claim 1 and are therefore rejected upon the same rationale.
Claims 11-16, 23 and 24 depend from claim 10 and are therefore rejected upon the same rationale.
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.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 19 and 20 is/are rejected under 35 U.S.C. 102(a)(1)/102(a)(2) as being anticipated by Sharma et al. (US 2020/0084087 A1) hereafter Sharma.
As per claim 19, Sharma discloses a computer-readable storage medium (As defined by the applicant in paragraph [0066] of the originally filed specification “Computer readable storage media, which is tangible and non-transitory, may include random access memory (RAM), read only memory (ROM), programmable read only memory (PROM), erasable programmable read only memory (EPROM), electronically erasable programmable read only memory (EEPROM), flash memory, a hard disk, a CD-ROM, a floppy disk, a cassette, magnetic data, optical media or other computer-readable storage media. The term “computer-readable storage media” refers to physical storage media, and not signals, carrier waves, or other transient media. From this the applicant has defined the medium as a non-transitory computer-readable storage medium) having stored thereon instructions that (Sharma Abstract; discloses that the method is for automated root cause analysis in a mobile radio access network. Sharma, paragraph [0024] establishes that the network comprises multiple network devices and that the system receives usage data from multiple network devices. Sharma, paragraph [0087]; discloses that the system includes a computer-readable medium storing the instruction which are executed by the processor), when executed, cause a processor to:
receive telemetry data from the plurality of network devices (Sharma paragraph [0044]; discloses that the system receives telemetry data from a plurality of sources including cell towers and other infrastructure as well as devices within the network. Specifically Sharma states “using telemetry data from cell towers and other infrastructure elements within the mobile network, system 100 prompts, requests, or commands one of more users, operators, or devices within the mobile network and/or network analysis platform 105 to collect data and/or report measurements relating to the mobile network. In some embodiments, this includes "polling" or pinging devices and requesting the devices to report data and responses back to the network analysis platform. The data or responses relate to how users or devices are experiencing anomalous behavior. In various embodiments, this can improve the collected data set upon which data is generated, root cause classification of anomalous behavior is performed, and/or other aspects of anomaly detection and analysis.”);
apply an artificial intelligence (AI) anomaly detection model, trained on historical telemetry data to detect anomalies in the historical telemetry data, to the received telemetry data to detect one or more anomalies in the received telemetry data (Sharma paragraph [0028]; discloses an Artificial Intelligence (AI) mode in the form of a machine learning model. The Machine learning model is trained using a training set which includes received and/or collected network usage data including historical, subsequent data collected after new configuration deployment. Which establishes that the it can be trained based on the historical data or updated based on subsequent data collection after a new configuration is deployed allowing for further refinement. Sharma specifically states “the machine learning engine 140 trains the machine learning models by feeding training set data into the models. The training set data can include: the received and/or collected network usage data (e.g., historic, subsequent data collected after new configuration deployment), profile information or customized preferences for the mobile operator (such as through an account the operator has within the network analysis platform), operator-labeled training data, historical data used for past training of models, heuristics, rules, statistical techniques, and any other data that would be useful in training the machine learning models for anomaly detection and/or analysis purposes.” Sharma paragraph [0031]; discloses that the anomaly detector detects using the one or more trained machine learning models anomalies); and
apply an AI root cause analysis, trained on historical data, to the anomalies in order to determine a root cause of an issue causing the one or more anomalies (Sharma paragraph [0026]; discloses that the machine learning models are applied to identify anomalies, the models are trained using historical data. Sharma states, “the input network usage data can include historical data, new data, and/or one or more standard sets of data. In one example, the network model engine quantifies the deviation of the metrics associated with the user session or network element from their expected joint and marginal distributions. In another example, the network model engine continuously or periodically updates the input network usage data to include new pieces of data that have been generated and output from the network model engine, such that the system is continuously evolving. In some embodiments, this updating is performed automatically and without any human input”. As shown in paragraph [0027] this data is then used by root cause classifiers to determine the root causes of the detected anomalies. Sharma states “the system includes one or more anomaly detection models (anomaly detection engines 150) that detect and/or classify an anomaly in the base station data, cell data, and/or user session data. In a third variation, the system includes one or more root cause classifiers ( e.g., a single classifier that classifies multiple root causes; multiple classifiers, each specific to a root cause, etc.; e.g., classification engine 160)”. Sharma [0042]; discloses that the anomalies are fed into a root cause analysis model, which uses the trained data to identify the impact or impacts caused by a particular network or device property which can be the root causes of the anomaly. Sharma states “the detected anomalous behavior, associated data or metrics for the anomaly ( e.g., features from before the anomalous event, features from when the anomalous event was occurring, and/or features from after the anomalous event), and/or user session data relating to the anomaly are fed into one or more machine learning models related to analysis of the model, such as root cause analysis (RCA). In one example, the classification engine 160 receives as input all user sessions flagged by the anomaly detector 150 where the session KPis are much different than expected, and then the classification engine is trained on that set of data. In some embodiments, root-cause specific KPis are fed into the one or more machine learning models”).
As per claim 20, Sharma discloses the computer-readable storage medium of claim 19, Sharma further discloses further comprising instructions that cause the processor to update the AI model using the received telemetry data (Sharma paragraph [0026]; establishes that the baseline for the model and the model itself can be updated with new data as it is received. Sharma paragraph [0044]; establishes that the data which is collected includes telemetry data).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 2, 4, 5, 10, 11, 13, 14, 21 and 23 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sharma et al. (US 2020/0084087 A1) hereafter Sharma, in view of Parker et al. (US 2022/0156123 A1) hereafter Parker.
As per claim 1, Sharma discloses a method of performing root cause analysis for a plurality of network devices (Sharma Abstract; discloses that the method is for automated root cause analysis in a mobile radio access network. Sharma, paragraph [0024] establishes that the network comprises multiple network devices and that the system receives usage data from multiple network devices), the method comprising:
receiving telemetry data from the plurality of network devices (Sharma paragraph [0044]; discloses that the system receives telemetry data from a plurality of sources including cell towers and other infrastructure as well as devices within the network. Specifically Sharma states “using telemetry data from cell towers and other infrastructure elements within the mobile network, system 100 prompts, requests, or commands one of more users, operators, or devices within the mobile network and/or network analysis platform 105 to collect data and/or report measurements relating to the mobile network. In some embodiments, this includes "polling" or pinging devices and requesting the devices to report data and responses back to the network analysis platform. The data or responses relate to how users or devices are experiencing anomalous behavior. In various embodiments, this can improve the collected data set upon which data is generated, root cause classification of anomalous behavior is performed, and/or other aspects of anomaly detection and analysis.”);
applying an artificial intelligence (AI) anomaly detection model, trained on historical telemetry data to detect anomalies in the historical telemetry data, to the received telemetry data to detect one or more anomalies in the received telemetry data (Sharma paragraph [0028]; discloses an Artificial Intelligence (AI) mode in the form of a machine learning model. The Machine learning model is trained using a training set which includes received and/or collected network usage data including historical, subsequent data collected after new configuration deployment. Which establishes that the it can be trained based on the historical data or updated based on subsequent data collection after a new configuration is deployed allowing for further refinement. Sharma specifically states “the machine learning engine 140 trains the machine learning models by feeding training set data into the models. The training set data can include: the received and/or collected network usage data (e.g., historic, subsequent data collected after new configuration deployment), profile information or customized preferences for the mobile operator (such as through an account the operator has within the network analysis platform), operator-labeled training data, historical data used for past training of models, heuristics, rules, statistical techniques, and any other data that would be useful in training the machine learning models for anomaly detection and/or analysis purposes.” Sharma paragraph [0031]; discloses that the anomaly detector detects using the one or more trained machine learning models anomalies); and
applying an AI root cause analysis model, trained on historical data, to the anomalies to determine a root cause of an issue causing the one or more anomalies (Sharma paragraph [0026]; discloses that the machine learning models are applied to identify anomalies, the models are trained using historical data. Sharma states, “the input network usage data can include historical data, new data, and/or one or more standard sets of data. In one example, the network model engine quantifies the deviation of the metrics associated with the user session or network element from their expected joint and marginal distributions. In another example, the network model engine continuously or periodically updates the input network usage data to include new pieces of data that have been generated and output from the network model engine, such that the system is continuously evolving. In some embodiments, this updating is performed automatically and without any human input”. As shown in paragraph [0027] this data is then used by root cause classifiers to determine the root causes of the detected anomalies. Sharma states “the system includes one or more anomaly detection models (anomaly detection engines 150) that detect and/or classify an anomaly in the base station data, cell data, and/or user session data. In a third variation, the system includes one or more root cause classifiers ( e.g., a single classifier that classifies multiple root causes; multiple classifiers, each specific to a root cause, etc.; e.g., classification engine 160)”. Sharma [0042]; discloses that the anomalies are fed into a root cause analysis model, which uses the trained data to identify the impact or impacts caused by a particular network or device property which can be the root causes of the anomaly. Sharma states “the detected anomalous behavior, associated data or metrics for the anomaly ( e.g., features from before the anomalous event, features from when the anomalous event was occurring, and/or features from after the anomalous event), and/or user session data relating to the anomaly are fed into one or more machine learning models related to analysis of the model, such as root cause analysis (RCA). In one example, the classification engine 160 receives as input all user sessions flagged by the anomaly detector 150 where the session KPis are much different than expected, and then the classification engine is trained on that set of data. In some embodiments, root-cause specific KPis are fed into the one or more machine learning models”).
While Sharma establishes receiving telemetry data and the use of both APIs and KPIs it is not explicit that the telemetry data includes application programming interface (API) data for one or more APIs of the plurality of network devices and key performance indicator (KPI) data for one or more KPIs for a network including the plurality of network devices and the detecting of anomalies is based on trained determination of which of the one or more APIs and the one or more KPIs are most important for anomaly detection.
Parker, which like Sharma talks about using telemetry data to detect errors, teaches it is known that the telemetry data includes application programming interface (API) data for one or more APIs of the plurality of network devices and key performance indicator (KPI) data for one or more KPIs for a network including the plurality of network devices and the detecting of anomalies is based on trained determination of which of the one or more APIs and the one or more KPIs are most important for anomaly detection (Parker paragraph [0014]; publishing telemetry data through specific APIs and use this data to create specific KPIs. Paragraph [0015]; teaches the specific KPIs for the telemetry data can be used to debug the data, make predictions. The telemetry data is used to create a KPI dashboard. Paragraph [0055]; teaches that the telemetry data is collected for specific nodes for devices. This identifies the APIs and KPIs for that node. These are considered the most important as they are the necessary APIs and KPIs for raising the red flags and indicating the problem. The Examiner notes that the term “most important” is relative as there is no indication of what makes something more important than another. The Examiner is interpreting this to be the APIs and KPIs necessary to indicate the anomaly. Since Sharma already discusses detecting anomalies it would have been obvious to detect the anomaly by identifying which APIs and KPIs are necessary to indicate the fault as shown in Parker).
Sharma establishes a method of performing root cause analysis where the system receives telemetry data form a plurality of network devices. The system applies an machine learning anomaly detection model which is a form of artificial intelligence. The machine learning model in Sharma is trained using historical telemetry data and is used to detect anomalies. Sharma applies a root cause analysis model, also trained on historical data, to determine the root cause of an issue which causes one of the anomalies which is detected. However, Sharma while discussing the identification of anomalies it fails to explicitly disclose that the telemetry data includes application programming interface (API) data for one or more APIs of the plurality of network devices and key performance indicator (KPI) data for one or more KPIs for a network including the plurality of network devices and the detecting of anomalies is based on trained determination of which of the one or more APIs and the one or more KPIs are most important for anomaly detection.
Parker, which like Sharma discusses modeling anomalies, teaches that it is known for the telemetry data includes application programming interface (API) data for one or more APIs of the plurality of network devices and key performance indicator (KPI) data for one or more KPIs for a network including the plurality of network devices and the detecting of anomalies is based on trained determination of which of the one or more APIs and the one or more KPIs are most important for anomaly detection.
It would have been obvious to one of ordinary skill in the art to include in the root cause analysis performed by Sharma, the ability for the telemetry data to include application programming interface (API) data for one or more APIs of the plurality of network devices and key performance indicator (KPI) data for one or more KPIs for a network including the plurality of network devices and the detecting of anomalies is based on trained determination of which of the one or more APIs and the one or more KPIs are most important for anomaly detection as taught by Parker since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Therefore, from this teaching of Parker, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method of performing root cause analysis provided by Sharma, with the telemetry data includes application programming interface (API) data for one or more APIs of the plurality of network devices and key performance indicator (KPI) data for one or more KPIs for a network including the plurality of network devices and the detecting of anomalies is based on trained determination of which of the one or more APIs and the one or more KPIs are most important for anomaly detection as taught by Parker, for the purposes of identifying which elements are effected by the anomaly. Since Sharma already discusses detecting anomalies it would have been obvious to detect the anomaly by identifying which APIs and KPIs are necessary to indicate the fault as shown in Parker.
As per claim 2, the combination of Sharma and Parker teaches the method of claim 1, Sharma further discloses further comprising, prior to receiving the telemetry data, training the AI anomaly detection model and the AI root cause analysis model on the historical telemetry data (Sharma, paragraphs [0026]; disclose that the prior to receiving the telemetry data, the anomaly detection model specifically the machine learning model which is a form of AI is trained using historical data. Sharma paragraph [0044]; establishes that the data which is collected includes telemetry data. Sharma paragraph [0028]; discloses that the machine learning model is trained by feeding training set data into the models and this data includes historical data. Sharma paragraph [0042]; discloses that the root cause analysis model is also trained prior. Sharma paragraphs [0043]-[0044]; disclose that the data includes historical or prior data and include telemetry data).
As per claim 4, the combination of Sharma and Parker teaches the method of claim 1, Sharma further discloses further comprising updating the AI models using the received telemetry data (Sharma paragraph [0026]; establishes that the baseline for the model and the model itself can be updated with new data as it is received. Sharma paragraph [0044]; establishes that the data which is collected includes telemetry data).
As per claim 5, the combination of Sharma and Parker teaches the method of claim 1, Sharma further discloses wherein the plurality of network devices include one or more control nodes and one or more computer nodes (Sharma, paragraph [0026]; establishes that the data can come from administrators, Sharma paragraph [0034]; discloses that the administrator device is part of the network. Based on the applicant’s originally filed specification paragraph [0006] control nodes are administrator devices. Sharma paragraph [0075]; discloses the network comprises a series of devices which are nodes and those nodes can comprise computers as shown in paragraph [0087]).
As per claim 10, Sharma discloses a system for performing root cause analysis for a plurality of network devices, the system comprising a processing system including one or more processors implemented in circuitry (Sharma Abstract; discloses that the method is for automated root cause analysis in a mobile radio access network. Sharma, paragraph [0024] establishes that the network comprises multiple network devices and that the system receives usage data from multiple network devices. Sharma, paragraph [0087]; discloses that the system comprises at least one hardware processor which is used to execute instructions), the processing system being configured to:
receive telemetry data from the plurality of network devices (Sharma paragraph [0044]; discloses that the system receives telemetry data from a plurality of sources including cell towers and other infrastructure as well as devices within the network. Specifically Sharma states “using telemetry data from cell towers and other infrastructure elements within the mobile network, system 100 prompts, requests, or commands one of more users, operators, or devices within the mobile network and/or network analysis platform 105 to collect data and/or report measurements relating to the mobile network. In some embodiments, this includes "polling" or pinging devices and requesting the devices to report data and responses back to the network analysis platform. The data or responses relate to how users or devices are experiencing anomalous behavior. In various embodiments, this can improve the collected data set upon which data is generated, root cause classification of anomalous behavior is performed, and/or other aspects of anomaly detection and analysis.”);
apply an artificial intelligence (AI) anomaly detection model, trained on historical telemetry data to detect anomalies in the historical telemetry data, to the received telemetry data to detect one or more anomalies in the received telemetry data (Sharma paragraph [0028]; discloses an Artificial Intelligence (AI) mode in the form of a machine learning model. The Machine learning model is trained using a training set which includes received and/or collected network usage data including historical, subsequent data collected after new configuration deployment. Which establishes that the it can be trained based on the historical data or updated based on subsequent data collection after a new configuration is deployed allowing for further refinement. Sharma specifically states “the machine learning engine 140 trains the machine learning models by feeding training set data into the models. The training set data can include: the received and/or collected network usage data (e.g., historic, subsequent data collected after new configuration deployment), profile information or customized preferences for the mobile operator (such as through an account the operator has within the network analysis platform), operator-labeled training data, historical data used for past training of models, heuristics, rules, statistical techniques, and any other data that would be useful in training the machine learning models for anomaly detection and/or analysis purposes.” Sharma paragraph [0031]; discloses that the anomaly detector detects using the one or more trained machine learning models anomalies); and
apply an AI root cause analysis model, trained on historical data, to the anomalies to determine a root cause of an issue causing the one or more anomalies (Sharma paragraph [0026]; discloses that the machine learning models are applied to identify anomalies, the models are trained using historical data. Sharma states, “the input network usage data can include historical data, new data, and/or one or more standard sets of data. In one example, the network model engine quantifies the deviation of the metrics associated with the user session or network element from their expected joint and marginal distributions. In another example, the network model engine continuously or periodically updates the input network usage data to include new pieces of data that have been generated and output from the network model engine, such that the system is continuously evolving. In some embodiments, this updating is performed automatically and without any human input”. As shown in paragraph [0027] this data is then used by root cause classifiers to determine the root causes of the detected anomalies. Sharma states “the system includes one or more anomaly detection models (anomaly detection engines 150) that detect and/or classify an anomaly in the base station data, cell data, and/or user session data. In a third variation, the system includes one or more root cause classifiers ( e.g., a single classifier that classifies multiple root causes; multiple classifiers, each specific to a root cause, etc.; e.g., classification engine 160)”. Sharma [0042]; discloses that the anomalies are fed into a root cause analysis model, which uses the trained data to identify the impact or impacts caused by a particular network or device property which can be the root causes of the anomaly. Sharma states “the detected anomalous behavior, associated data or metrics for the anomaly ( e.g., features from before the anomalous event, features from when the anomalous event was occurring, and/or features from after the anomalous event), and/or user session data relating to the anomaly are fed into one or more machine learning models related to analysis of the model, such as root cause analysis (RCA). In one example, the classification engine 160 receives as input all user sessions flagged by the anomaly detector 150 where the session KPis are much different than expected, and then the classification engine is trained on that set of data. In some embodiments, root-cause specific KPis are fed into the one or more machine learning models”).
While Sharma establishes receiving telemetry data and the use of both APIs and KPIs it is not explicit that the telemetry data includes application programming interface (API) data for one or more APIs of the plurality of network devices and key performance indicator (KPI) data for one or more KPIs for a network including the plurality of network devices and the detecting of anomalies is based on trained determination of which of the one or more APIs and the one or more KPIs are most important for anomaly detection.
Parker, which like Sharma talks about using telemetry data to detect errors, teaches it is known that the telemetry data includes application programming interface (API) data for one or more APIs of the plurality of network devices and key performance indicator (KPI) data for one or more KPIs for a network including the plurality of network devices and the detecting of anomalies is based on trained determination of which of the one or more APIs and the one or more KPIs are most important for anomaly detection (Parker paragraph [0014]; publishing telemetry data through specific APIs and use this data to create specific KPIs. Paragraph [0015]; teaches the specific KPIs for the telemetry data can be used to debug the data, make predictions. The telemetry data is used to create a KPI dashboard. Paragraph [0055]; teaches that the telemetry data is collected for specific nodes for devices. This identifies the APIs and KPIs for that node. These are considered the most important as they are the necessary APIs and KPIs for raising the red flags and indicating the problem. The Examiner notes that the term “most important” is relative as there is no indication of what makes something more important than another. The Examiner is interpreting this to be the APIs and KPIs necessary to indicate the anomaly. Since Sharma already discusses detecting anomalies it would have been obvious to detect the anomaly by identifying which APIs and KPIs are necessary to indicate the fault as shown in Parker).
Sharma establishes a method of performing root cause analysis where the system receives telemetry data form a plurality of network devices. The system applies an machine learning anomaly detection model which is a form of artificial intelligence. The machine learning model in Sharma is trained using historical telemetry data and is used to detect anomalies. Sharma applies a root cause analysis model, also trained on historical data, to determine the root cause of an issue which causes one of the anomalies which is detected. However, Sharma while discussing the identification of anomalies it fails to explicitly disclose that the telemetry data includes application programming interface (API) data for one or more APIs of the plurality of network devices and key performance indicator (KPI) data for one or more KPIs for a network including the plurality of network devices and the detecting of anomalies is based on trained determination of which of the one or more APIs and the one or more KPIs are most important for anomaly detection.
Parker, which like Sharma discusses modeling anomalies, teaches that it is known for the telemetry data includes application programming interface (API) data for one or more APIs of the plurality of network devices and key performance indicator (KPI) data for one or more KPIs for a network including the plurality of network devices and the detecting of anomalies is based on trained determination of which of the one or more APIs and the one or more KPIs are most important for anomaly detection.
It would have been obvious to one of ordinary skill in the art to include in the root cause analysis performed by Sharma, the ability for the telemetry data to include application programming interface (API) data for one or more APIs of the plurality of network devices and key performance indicator (KPI) data for one or more KPIs for a network including the plurality of network devices and the detecting of anomalies is based on trained determination of which of the one or more APIs and the one or more KPIs are most important for anomaly detection as taught by Parker since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Therefore, from this teaching of Parker, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method of performing root cause analysis provided by Sharma, with the telemetry data includes application programming interface (API) data for one or more APIs of the plurality of network devices and key performance indicator (KPI) data for one or more KPIs for a network including the plurality of network devices and the detecting of anomalies is based on trained determination of which of the one or more APIs and the one or more KPIs are most important for anomaly detection as taught by Parker, for the purposes of identifying which elements are effected by the anomaly. Since Sharma already discusses detecting anomalies it would have been obvious to detect the anomaly by identifying which APIs and KPIs are necessary to indicate the fault as shown in Parker.
As per claim 11, the combination of Sharma and Parker teaches the system of claim 10, Sharma further discloses wherein the one or more processors are further configured to, prior to receiving the telemetry data, train the AI anomaly detection model and the AI root cause analysis model on the historical telemetry data (Sharma, paragraphs [0026]; disclose that the prior to receiving the telemetry data, the anomaly detection model specifically the machine learning model which is a form of AI is trained using historical data. Sharma paragraph [0044]; establishes that the data which is collected includes telemetry data. Sharma paragraph [0028]; discloses that the machine learning model is trained by feeding training set data into the models and this data includes historical data. Sharma paragraph [0042]; discloses that the root cause analysis model is also trained prior. Sharma paragraphs [0043]-[0044]; disclose that the data includes historical or prior data and include telemetry data).
As per claim 13, the combination of Sharma and Parker teaches the system of claim 10, Sharma further discloses wherein the one or more processors are further configured to update the AI models using the received telemetry data (Sharma paragraph [0026]; establishes that the baseline for the model and the model itself can be updated with new data as it is received. Sharma paragraph [0044]; establishes that the data which is collected includes telemetry data).
As per claim 14, the combination of Sharma and Parker teaches the system of claim 10, Sharma further discloses wherein the plurality of network devices include one or more control nodes and one or more compute nodes (Sharma, paragraph [0026]; establishes that the data can come from administrators, Sharma paragraph [0034]; discloses that the administrator device is part of the network. Based on the applicant’s originally filed specification paragraph [0006] control nodes are administrator devices. Sharma paragraph [0075]; discloses the network comprises a series of devices which are nodes and those nodes can comprise computers as shown in paragraph [0087]).
As per claim 21, the combination of Sharma and Parker teaches the method of claim 1, Parker further teaches using the trained determination to determine which of the one or more APIs and the one or more KPIs are most important for anomaly detection; and configuring the plurality of network devices to deliver the telemetry data for the one or more APIs and the KPI data are most important for anomaly detection (Paragraph [0055]; teaches that the telemetry data is collected for specific nodes for devices. This identifies the APIs and KPIs for that node. These are considered the most important as they are the necessary APIs and KPIs for raising the red flags and indicating the problem. From this they are configured to deliver the telemetry data indicating the error or anomaly. The Examiner notes that the term “most important” is relative as there is no indication of what makes something more important than another. The Examiner is interpreting this to be the APIs and KPIs necessary to indicate the anomaly).
As per claim 23, the combination of Sharma and Parker teaches the system of claim 10, Parker further teaches use the trained determination to determine which of the one or more APIs and the one or more KPIs are most important for anomaly detection; and configure the plurality of network devices to deliver the telemetry data for the one or more APIs and the KPI data are most important for anomaly detection (Paragraph [0055]; teaches that the telemetry data is collected for specific nodes for devices. This identifies the APIs and KPIs for that node. These are considered the most important as they are the necessary APIs and KPIs for raising the red flags and indicating the problem. From this they are configured to deliver the telemetry data indicating the error or anomaly. The Examiner notes that the term “most important” is relative as there is no indication of what makes something more important than another. The Examiner is interpreting this to be the APIs and KPIs necessary to indicate the anomaly).
Claim(s) 3, 6, 12 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sharma et al. (US 2020/0084087 A1) hereafter Sharma, in view of Parker et al. (US 2022/0156123 A1) hereafter Parker, further in view of Kim et al. (US 2019/0236456 A1) hereafter Kim.
As per claim 3, the combination of Sharma and Parker teaches the method of claim 1, While Sharma discloses that the data can include a number of metrics or attributes (Sharma paragraph [0062]) it is not explicit wherein the AI models comprise multivariate AI models.
Kim, which like Sharma discusses modeling anomalies in a network, teaches it is known wherein the AI models comprise multivariate AI models (Kim , paragraph [0074]; teaches receiving historical data regarding a number of devices. This includes sensor data over a length of time. Kim, paragraph [0077]; teaches it is known to run and rerun multivariate anomaly models to set a baseline to perform the machine learning, specifically primary unsupervised learning. The system will then store the multivariate timeseries data along with the anomaly status for a predetermined period of time as part of excluding failures. Kim, paragraph [0079]; teaches that the multivariate anomaly model is trained to set a baseline for the learning process. Kim, paragraph [0080]; teaches that the system can combine previous features and to identify top factors, such as the most significant factors that contribute into the historical failure data. This is used to create weighing vector. As discussed in paragraph [0082] this is done to build a predictive model. Since Sharma already collects data from various sources and the data contains a number of metrics, it would have been obvious to utilize this multiple data points to generate a multivariate model. Sharma establishes a baseline is established for determining anomalies. As shown in Kim by run the multivariate data in a time series the initial baseline for the machine learn model can be established and built off of. Since Sharma already creates a baseline using machine learning to determine anomalies based on historical data it would have been obvious to use multivariate timeseries data to establish that base as shown in Kim).
Sharma establishes a method of performing root cause analysis where the system receives telemetry data form a plurality of network devices. The system applies an machine learning anomaly detection model which is a form of artificial intelligence. The machine learning model in Sharma is trained using historical telemetry data and is used to detect anomalies. Sharma applies a root cause analysis model, also trained on historical data, to determine the root cause of an issue which causes one of the anomalies which is detected. Parker teaches that it is known for the telemetry data includes application programming interface (API) data for one or more APIs of the plurality of network devices and key performance indicator (KPI) data for one or more KPIs for a network including the plurality of network devices and the detecting of anomalies is based on trained determination of which of the one or more APIs and the one or more KPIs are most important for anomaly detection. However, Sharma while discussing having a number of metrics is not explicit that the model comprises multivariate AI models.
Kim, which like Sharma discusses modeling anomalies in a network, teaches that it is known for the models for detecting anomalies to comprise multivariate AI models. Kim establishes this is known to establish a baseline for detecting the anomalies.
It would have been obvious to one of ordinary skill in the art to include in the root cause analysis performed by Sharma and Parker, the ability for the AI models to comprise multivariate AI models as taught by Kim since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Therefore, from this teaching of Kim, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method of performing root cause analysis provided by Sharma and Parker, with the ability for the AI models to comprise multivariate AI models as taught by Kim, for the purposes of building a baseline for the model to build off of. Since Sharma already creates a baseline using machine learning to determine anomalies based on historical data it would have been obvious to use multivariate timeseries data to establish that base as shown in Kim.
As per claim 6, the combination of Sharma and Parker teaches the method of claim 1, While Sharma discloses that the data can include a number of metrics or attributes including telemetry data (Sharma paragraph [0062] and [0044]) and the data can be found in timeseries (Sharma paragraph [0072]) it is not explicit wherein the received telemetry data is for a multivariate timeseries.`
Kim, which like Sharma discusses modeling anomalies in a network, teaches it is known wherein the received telemetry data is for a multivariate timeseries (Kim , paragraph [0074]; teaches receiving historical data regarding a number of devices. This includes sensor data over a length of time. Kim, paragraph [0077]; teaches it is known to run and rerun multivariate anomaly models to set a baseline to perform the machine learning, specifically primary unsupervised learning. The system will then store the multivariate timeseries data along with the anomaly status for a predetermined period of time as part of excluding failures. Kim, paragraph [0079]; teaches that the multivariate anomaly model is trained to set a baseline for the learning process. Kim, paragraph [0080]; teaches that the system can combine previous features and to identify top factors, such as the most significant factors that contribute into the historical failure data. This is used to create weighing vector. As discussed in paragraph [0082] this is done to build a predictive model. Since Sharma already collects data from various sources and the data contains a number of metrics including telemetry data, it would have been obvious to utilize this multiple data points to generate a multivariate timeseries model. Sharma establishes a baseline is established for determining anomalies. As shown in Kim by run the multivariate data in a time series the initial baseline for the machine learn model can be established and built off of. Since Sharma already creates a baseline using machine learning to determine anomalies based on historical data it would have been obvious to use multivariate timeseries data to establish that base as shown in Kim).
Sharma establishes a method of performing root cause analysis where the system receives telemetry data form a plurality of network devices. The system applies an machine learning anomaly detection model which is a form of artificial intelligence. The machine learning model in Sharma is trained using historical telemetry data and is used to detect anomalies. Sharma applies a root cause analysis model, also trained on historical data, to determine the root cause of an issue which causes one of the anomalies which is detected. Parker teaches that it is known for the telemetry data includes application programming interface (API) data for one or more APIs of the plurality of network devices and key performance indicator (KPI) data for one or more KPIs for a network including the plurality of network devices and the detecting of anomalies is based on trained determination of which of the one or more APIs and the one or more KPIs are most important for anomaly detection. However, Sharma while discussing having a number of metrics is not explicit that the received telemetry data is for a multivariate timeseries.
Kim, which like Sharma discusses modeling anomalies in a network, teaches that it is known for the models for detecting anomalies to comprise multivariate timeseries models. Kim establishes this is known to establish a baseline for detecting the anomalies.
It would have been obvious to one of ordinary skill in the art to include in the root cause analysis performed by Sharma and Parker, the ability for the models to comprise multivariate timeseries data as taught by Kim since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Therefore, from this teaching of Kim, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method of performing root cause analysis provided by Sharma and Parker, with the ability for the models to comprise multivariate timeseries data as taught by Kim, for the purposes of building a baseline for the model to build off of. Since Sharma already creates a baseline using machine learning to determine anomalies based on historical data it would have been obvious to use multivariate timeseries data to establish that base as shown in Kim.
As per claim 12, the combination of Sharma and Parker teaches the system of claim 10, While Sharma discloses that the data can include a number of metrics or attributes (Sharma paragraph [0062]) it is not explicit wherein the AI models comprise multivariate AI models.
Kim, which like Sharma discusses modeling anomalies in a network, teaches it is known wherein the AI models comprise multivariate AI models (Kim , paragraph [0074]; teaches receiving historical data regarding a number of devices. This includes sensor data over a length of time. Kim, paragraph [0077]; teaches it is known to run and rerun multivariate anomaly models to set a baseline to perform the machine learning, specifically primary unsupervised learning. The system will then store the multivariate timeseries data along with the anomaly status for a predetermined period of time as part of excluding failures. Kim, paragraph [0079]; teaches that the multivariate anomaly model is trained to set a baseline for the learning process. Kim, paragraph [0080]; teaches that the system can combine previous features and to identify top factors, such as the most significant factors that contribute into the historical failure data. This is used to create weighing vector. As discussed in paragraph [0082] this is done to build a predictive model. Since Sharma already collects data from various sources and the data contains a number of metrics, it would have been obvious to utilize this multiple data points to generate a multivariate model. Sharma establishes a baseline is established for determining anomalies. As shown in Kim by run the multivariate data in a time series the initial baseline for the machine learn model can be established and built off of. Since Sharma already creates a baseline using machine learning to determine anomalies based on historical data it would have been obvious to use multivariate timeseries data to establish that base as shown in Kim).
Sharma establishes a method of performing root cause analysis where the system receives telemetry data form a plurality of network devices. The system applies an machine learning anomaly detection model which is a form of artificial intelligence. The machine learning model in Sharma is trained using historical telemetry data and is used to detect anomalies. Sharma applies a root cause analysis model, also trained on historical data, to determine the root cause of an issue which causes one of the anomalies which is detected. Parker teaches that it is known for the telemetry data includes application programming interface (API) data for one or more APIs of the plurality of network devices and key performance indicator (KPI) data for one or more KPIs for a network including the plurality of network devices and the detecting of anomalies is based on trained determination of which of the one or more APIs and the one or more KPIs are most important for anomaly detection. However, Sharma while discussing having a number of metrics is not explicit that the model comprises multivariate AI models.
Kim, which like Sharma discusses modeling anomalies in a network, teaches that it is known for the models for detecting anomalies to comprise multivariate AI models. Kim establishes this is known to establish a baseline for detecting the anomalies.
It would have been obvious to one of ordinary skill in the art to include in the root cause analysis performed by Sharma and Parker, the ability for the AI models to comprise multivariate AI models as taught by Kim since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Therefore, from this teaching of Kim, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method of performing root cause analysis provided by Sharma and Parker, with the ability for the AI models to comprise multivariate AI models as taught by Kim, for the purposes of building a baseline for the model to build off of. Since Sharma already creates a baseline using machine learning to determine anomalies based on historical data it would have been obvious to use multivariate timeseries data to establish that base as shown in Kim.
As per claim 15, the combination of Sharma and Parker teaches the system of claim 10, Sharma discloses the method of claim 1, While Sharma discloses that the data can include a number of metrics or attributes including telemetry data (Sharma paragraph [0062] and [0044]) and the data can be found in timeseries (Sharma paragraph [0072]) it is not explicit wherein the received telemetry data is for a multivariate timeseries.`
Kim, which like Sharma discusses modeling anomalies in a network, teaches it is known wherein the received telemetry data is for a multivariate timeseries (Kim , paragraph [0074]; teaches receiving historical data regarding a number of devices. This includes sensor data over a length of time. Kim, paragraph [0077]; teaches it is known to run and rerun multivariate anomaly models to set a baseline to perform the machine learning, specifically primary unsupervised learning. The system will then store the multivariate timeseries data along with the anomaly status for a predetermined period of time as part of excluding failures. Kim, paragraph [0079]; teaches that the multivariate anomaly model is trained to set a baseline for the learning process. Kim, paragraph [0080]; teaches that the system can combine previous features and to identify top factors, such as the most significant factors that contribute into the historical failure data. This is used to create weighing vector. As discussed in paragraph [0082] this is done to build a predictive model. Since Sharma already collects data from various sources and the data contains a number of metrics including telemetry data, it would have been obvious to utilize this multiple data points to generate a multivariate timeseries model. Sharma establishes a baseline is established for determining anomalies. As shown in Kim by run the multivariate data in a time series the initial baseline for the machine learn model can be established and built off of. Since Sharma already creates a baseline using machine learning to determine anomalies based on historical data it would have been obvious to use multivariate timeseries data to establish that base as shown in Kim).
Sharma establishes a method of performing root cause analysis where the system receives telemetry data form a plurality of network devices. The system applies an machine learning anomaly detection model which is a form of artificial intelligence. The machine learning model in Sharma is trained using historical telemetry data and is used to detect anomalies. Sharma applies a root cause analysis model, also trained on historical data, to determine the root cause of an issue which causes one of the anomalies which is detected. Parker teaches that it is known for the telemetry data includes application programming interface (API) data for one or more APIs of the plurality of network devices and key performance indicator (KPI) data for one or more KPIs for a network including the plurality of network devices and the detecting of anomalies is based on trained determination of which of the one or more APIs and the one or more KPIs are most important for anomaly detection. However, Sharma while discussing having a number of metrics is not explicit that the received telemetry data is for a multivariate timeseries.
Kim, which like Sharma discusses modeling anomalies in a network, teaches that it is known for the models for detecting anomalies to comprise multivariate timeseries models. Kim establishes this is known to establish a baseline for detecting the anomalies.
It would have been obvious to one of ordinary skill in the art to include in the root cause analysis performed by Sharma and Parker, the ability for the models to comprise multivariate timeseries data as taught by Kim since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Therefore, from this teaching of Kim, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method of performing root cause analysis provided by Sharma and Parker, with the ability for the models to comprise multivariate timeseries data as taught by Kim, for the purposes of building a baseline for the model to build off of. Since Sharma already creates a baseline using machine learning to determine anomalies based on historical data it would have been obvious to use multivariate timeseries data to establish that base as shown in Kim.
Claim(s) 7 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sharma et al. (US 2020/0084087 A1) hereafter Sharma, in view of Parker et al. (US 2022/0156123 A1) hereafter Parker, further in view of Jilani (US 2017/0031742 A1) hereafter Jilani.
As per claim 7, the combination of Sharma and Parker teaches the method of claim 1, Sharma however fails to explicitly disclose wherein performing the root cause analysis comprises performing the root cause analysis using causal AI algorithms.
Jilani, which like Sharma talks about performing a root cause analysis, teaches wherein performing the root cause analysis comprises performing the root cause analysis using causal AI algorithms (Jilani, paragraph [0024]; teaches it is known to use causal analysis to determine the root cause of an issue with the network. Specifically an example of this can be a causal engine which uses unsupervised learning such as Granger causal tests, cluster analysis etc. Jilani, paragraph [0031]; teaches that the causal analysis is performed on the subset of data logs to determine the root cause for an issue. The Examiner notes that this is consistent with the applicant’s originally filed specification paragraph [0031] which explicitly lists Granger as one possible way for performing the root cause analysis. Since Sharma already performs root cause analysis it would have been obvious to use known methods such as Granger to achieve the expected results as highlighted in Jilani).
Sharma establishes a method of performing root cause analysis where the system receives telemetry data form a plurality of network devices. The system applies an machine learning anomaly detection model which is a form of artificial intelligence. The machine learning model in Sharma is trained using historical telemetry data and is used to detect anomalies. Sharma applies a root cause analysis model, also trained on historical data, to determine the root cause of an issue which causes one of the anomalies which is detected. Parker teaches that it is known for the telemetry data includes application programming interface (API) data for one or more APIs of the plurality of network devices and key performance indicator (KPI) data for one or more KPIs for a network including the plurality of network devices and the detecting of anomalies is based on trained determination of which of the one or more APIs and the one or more KPIs are most important for anomaly detection. Sharma however fails to explicitly disclose wherein performing the root cause analysis comprises performing the root cause analysis using causal AI algorithms.
The sole difference between the Sharma reference and the claimed subject matter is the type of root cause analysis which is performed. That is Sharma establishes performing a root cause analysis but is not specific that the root cause analysis is Granger a known form of root cause analysis using casual AI algorithms.
The Jilani reference teaches it is known to perform root cause analysis as done in Sharma and to use Granger which is a known form of root cause analysis using casual AI algorithms. Jilani establishes this type of root cause analysis was known in the prior art at the time of the invention.
Since each individual element and its function are shown in the prior art, albeit shown in separate references, the difference between the claimed subject matter and the prior art rests not on any individual element or function but in the very combination itself- that is in the substitution of the root cause analysis model used in Sharma and Parker with the root cause analysis model being Granger which is a form of casual AI algorithms as taught by Jilani.
Therefore, from this teaching of Jilani, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method of performing root cause analysis provided by Sharma and Parker, with using the Granger casual model to determine the root cause analysis as taught by Jilani, for the purposes of using known techniques to achieve the desired result. Since Sharma already performs root cause analysis it would have been obvious to use known methods such as Granger to achieve the expected results as highlighted in Jilani.
As per claim 16, the combination of Sharma and Parker teaches the system of claim 10, Sharma however fails to explicitly disclose wherein to perform the root cause analysis, the one or more processors are configured to perform the root cause analysis using causal AI algorithm.
Jilani, which like Sharma talks about performing a root cause analysis, teaches wherein performing the root cause analysis comprises performing the root cause analysis using causal AI algorithms (Jilani, paragraph [0024]; teaches it is known to use causal analysis to determine the root cause of an issue with the network. Specifically an example of this can be a causal engine which uses unsupervised learning such as Granger causal tests, cluster analysis etc. Jilani, paragraph [0031]; teaches that the causal analysis is performed on the subset of data logs to determine the root cause for an issue. The Examiner notes that this is consistent with the applicant’s originally filed specification paragraph [0031] which explicitly lists Granger as one possible way for performing the root cause analysis. Since Sharma already performs root cause analysis it would have been obvious to use known methods such as Granger to achieve the expected results as highlighted in Jilani).
Sharma establishes a method of performing root cause analysis where the system receives telemetry data form a plurality of network devices. The system applies an machine learning anomaly detection model which is a form of artificial intelligence. The machine learning model in Sharma is trained using historical telemetry data and is used to detect anomalies. Sharma applies a root cause analysis model, also trained on historical data, to determine the root cause of an issue which causes one of the anomalies which is detected. Parker teaches that it is known for the telemetry data includes application programming interface (API) data for one or more APIs of the plurality of network devices and key performance indicator (KPI) data for one or more KPIs for a network including the plurality of network devices and the detecting of anomalies is based on trained determination of which of the one or more APIs and the one or more KPIs are most important for anomaly detection. Sharma however fails to explicitly disclose wherein performing the root cause analysis comprises performing the root cause analysis using causal AI algorithms.
The sole difference between the Sharma reference and the claimed subject matter is the type of root cause analysis which is performed. That is Sharma establishes performing a root cause analysis but is not specific that the root cause analysis is Granger a known form of root cause analysis using casual AI algorithms.
The Jilani reference teaches it is known to perform root cause analysis as done in Sharma and to use Granger which is a known form of root cause analysis using casual AI algorithms. Jilani establishes this type of root cause analysis was known in the prior art at the time of the invention.
Since each individual element and its function are shown in the prior art, albeit shown in separate references, the difference between the claimed subject matter and the prior art rests not on any individual element or function but in the very combination itself- that is in the substitution of the root cause analysis model used in Sharma and Parker with the root cause analysis model being Granger which is a form of casual AI algorithms as taught by Jilani.
Therefore, from this teaching of Jilani, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method of performing root cause analysis provided by Sharma and Parker, with using the Granger casual model to determine the root cause analysis as taught by Jilani, for the purposes of using known techniques to achieve the desired result. Since Sharma already performs root cause analysis it would have been obvious to use known methods such as Granger to achieve the expected results as highlighted in Jilani.
Claim(s) 22 and 24 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sharma et al. (US 2020/0084087 A1) hereafter Sharma, in view of Parker et al. (US 2022/0156123 A1) hereafter Parker, further in view of Ferreira et al. (US 2021/0124510 A1) hereafter Ferreira.
As per claim 22, the combination of Sharma and Parker teaches the method of claim 21, the combination fails to explicitly disclose wherein configuring the plurality of network devices comprises configuring the plurality of network devices to omit data from APIs and KPIs other than the one or more APIs and the one or more KPIs that are most important for anomaly detection from the telemetry data.
Ferreira, which like the combination talks about monitoring telemetry data, teaches it is known to configure the plurality of network devices comprises configuring the plurality of network devices to omit data from APIs and KPIs other than the one or more APIs and the one or more KPIs that are most important for anomaly detection from the telemetry data (Ferreira paragraphs [0006] and [0025]; teaches it is known to omit or remove telemetry data which is part of irrelevant or outlier data. Ferreira establishes it is known to remove data to get more accurate results).
Sharma establishes a method of performing root cause analysis where the system receives telemetry data form a plurality of network devices. The system applies an machine learning anomaly detection model which is a form of artificial intelligence. The machine learning model in Sharma is trained using historical telemetry data and is used to detect anomalies. Sharma applies a root cause analysis model, also trained on historical data, to determine the root cause of an issue which causes one of the anomalies which is detected. Parker teaches that it is known for the telemetry data includes application programming interface (API) data for one or more APIs of the plurality of network devices and key performance indicator (KPI) data for one or more KPIs for a network including the plurality of network devices and the detecting of anomalies is based on trained determination of which of the one or more APIs and the one or more KPIs are most important for anomaly detection. The combination however fails to explicitly disclose configuring the plurality of network devices comprises configuring the plurality of network devices to omit data from APIs and KPIs other than the one or more APIs and the one or more KPIs that are most important for anomaly detection from the telemetry data.
Ferreira, which like Sharma discusses monitoring telemetry data, teaches that it is known to configure the plurality of network devices comprises configuring the plurality of network devices to omit data from APIs and KPIs other than the one or more APIs and the one or more KPIs that are most important for anomaly detection from the telemetry data.
It would have been obvious to one of ordinary skill in the art to include in the root cause analysis performed by Sharma and Parker, the ability to configure the plurality of network devices comprises configuring the plurality of network devices to omit data from APIs and KPIs other than the one or more APIs and the one or more KPIs that are most important for anomaly detection from the telemetry data as taught by Ferreira since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Therefore, from this teaching of Ferreira, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method of performing root cause analysis provided by Sharma and Parker, with the ability to configure the plurality of network devices comprises configuring the plurality of network devices to omit data from APIs and KPIs other than the one or more APIs and the one or more KPIs that are most important for anomaly detection from the telemetry data as taught by Ferreira, for the purposes of removing irrelevant data. Ferreira establishes it is known to remove data to get more accurate results.
As per claim 24, the combination of Sharma and Parker teaches the system of claim 23, the combination fails to explicitly disclose wherein to configure the plurality of network devices, the processing system is configured to configure the plurality of network devices to omit data for APIs and KPIs other than the one or more APIs and the one or more KPIs that are most important for anomaly detection from the telemetry data.
Ferreira, which like the combination talks about monitoring telemetry data, teaches it is known to configure the plurality of network devices, the processing system is configured to configure the plurality of network devices to omit data for APIs and KPIs other than the one or more APIs and the one or more KPIs that are most important for anomaly detection from the telemetry data (Ferreira paragraphs [0006] and [0025]; teaches it is known to omit or remove telemetry data which is part of irrelevant or outlier data. Ferreira establishes it is known to remove data to get more accurate results).
Sharma establishes a method of performing root cause analysis where the system receives telemetry data form a plurality of network devices. The system applies an machine learning anomaly detection model which is a form of artificial intelligence. The machine learning model in Sharma is trained using historical telemetry data and is used to detect anomalies. Sharma applies a root cause analysis model, also trained on historical data, to determine the root cause of an issue which causes one of the anomalies which is detected. Parker teaches that it is known for the telemetry data includes application programming interface (API) data for one or more APIs of the plurality of network devices and key performance indicator (KPI) data for one or more KPIs for a network including the plurality of network devices and the detecting of anomalies is based on trained determination of which of the one or more APIs and the one or more KPIs are most important for anomaly detection. The combination however fails to explicitly disclose configuring the plurality of network devices comprises configuring the plurality of network devices, the processing system is configured to configure the plurality of network devices to omit data for APIs and KPIs other than the one or more APIs and the one or more KPIs that are most important for anomaly detection from the telemetry data.
Ferreira, which like Sharma discusses monitoring telemetry data, teaches that it is known to configure the plurality of network devices, the processing system is configured to configure the plurality of network devices to omit data for APIs and KPIs other than the one or more APIs and the one or more KPIs that are most important for anomaly detection from the telemetry data.
It would have been obvious to one of ordinary skill in the art to include in the root cause analysis performed by Sharma and Parker, the ability to configure the plurality of network devices, the processing system is configured to configure the plurality of network devices to omit data for APIs and KPIs other than the one or more APIs and the one or more KPIs that are most important for anomaly detection from the telemetry data as taught by Ferreira since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Therefore, from this teaching of Ferreira, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method of performing root cause analysis provided by Sharma and Parker, with the ability to configure the plurality of network devices comprises configuring the plurality of network devices to omit data from APIs and KPIs other than the one or more APIs and the one or more KPIs that are most important for anomaly detection from the telemetry data as taught by Ferreira, for the purposes of removing irrelevant data. Ferreira establishes it is known to remove data to get more accurate results.
Response to Arguments
Applicant's arguments filed October 1, 2025 have been fully considered but they are not persuasive.
The Examiner notes that while the applicant has stated the claims have been similarly amended, claims 19 and 20 have not been amended and are indicated as originally. As such lacking any arguing or amendments, the Examiner has not been persuaded and the rejections have been maintained.
Applicant's arguments with respect to claims 1-7, 10-16, 19 and 20 have been considered but are moot in view of the new ground(s) of rejection. Specifically the arguments regarding the newly amended material that "the telemetry data including application programming interface (API) data for one or more APIs of the plurality of network devices and key performance indicator (KPI) data for one or more KPIs for a network including the plurality of network devices" and “based on a trained determination of which of the one or more APIs and the one or more KPIs are most important for anomaly detection” are moot in view of the new grounds of rejection. Specifically the Examiner has cited the Parker reference to address these newly amended limitations.
All rejections made towards the dependent claims are maintained due to the lack of a reply by the applicant in regards to distinctly and specifically point out the supposed errors in the Examiner’s action in the prior Office Action (37 CFR 1.111). The Examiner asserts that the applicant only argues that the dependent claims should be allowable because the independent claims are unobvious and patentable over Sharma, and, where appropriate, in further view of Kim and Jilani.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PAUL R FISHER whose telephone number is (571)270-5097. The examiner can normally be reached Monday - Friday 9 am to 5:30 pm.
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, Yin-Chen Shaw can be reached at (571)272-8878. 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.
PAUL R. FISHER
Primary Examiner
Art Unit 2498
/PAUL R FISHER/Primary Examiner, Art Unit 2498 1/10/2026