DETAILED ACTION
This office action is in response to the filed application 18/376,378 on October 3, 2023.
Claims 1-12 are presented for examination.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hatonen et al. (US 2004/0039968) in further view of Vijayan et al. (US 2022/0303169).
In regard to claim 1, Hatonen et al. teach a computer-implemented process for troubleshooting and resolving problems with objects of a cloud infrastructure, the process comprising:
monitoring a key performance indicator ("KPI") of an object running in the cloud infrastructure for abnormal behavior of the object (collecting data from an observable object where anomalies are detected based on user-definable key performance indicators (KPIs) of the observable objects, para. 28);
displaying a graphical user interface ("GUI") in a display device that enables a user to select KPIs of components of the object for generating rules to detect the problem (KPIs can be defined by the user, para. 32);
for each of the components, executing a separate rule learning engine that generates rules for detecting a problem with the component based on the KPI of the object and the KPIs of the component (monitor the behavior of the object where at least one parameter of the observable object is detected, the parameter is checked with regard to a predetermined criteria, a vector is formed based on the monitored parameter, Key Performance Indicators (KPIs) which are computed and monitored measure the quality of service, para. 14-25);
using the rules to detect a runtime problem with the object (anomalies are detected, para. 28-31).
Hatonen et al. does not explicitly teach display at least one remedial measure for resolving the problem in the GUI based on runtime metric values of the KPIs of the components; and executing at least one of the remedial measures to resolve the problem with the object via the GUI.
Vijayan et al. teach of the remedial action can also include visually identifying the problem to an operator (para. 86), the GUI can include a notification log and also instructions can be available to guide the operator in manually fixing the problem (para. 87), and clicking on the log provided information can launch performance reports and remediation workflows (para. 88).
It would have been obvious to modify the process of Hatonen et al. by adding Vijayan et al. network function virtualization cloud. A person of ordinary skill in the art before the effective filing date of the claimed invention would have been motivated to make the modification because it would aid in providing remedial actions to users (para. 83-88).
In regard to claim 2, Hatonen et al. teach the process of claim 1 wherein monitoring the KPI of the object comprises:
displaying the KPI of the object in a user selected time interval in the GUI (provide anomaly information reports and heartbeat reports and send these reports to a network element TS 13, para. 98, provides visibility to the network status in real-time at anytime and anywhere, para. 99); and
selecting the KPI for rule generating the rules via the GUI (the KPI definitions may be changeable on the fly, para. 92).
In regard to claim 3, Hatonen et al. teach the process of claim 1 wherein executing the separate rule learning engine that generates rules for detecting the problem with the component comprises:
applying min-max smoothing to time synchronize the KPI of the object and each of the KPIs of the component to the same time indices (finding best mapping nodes or cluster centroids for incoming vectors, counting distance between new incoming vectors and the best mapping node or cluster centroid, para. 51-56);
for each time index, forming a class-based tuple of metric values of the KPIs and a class label of the KPI of the object (RTT reports is a structured report of an event in the network that consisting of fixed-width fields in a predefined order, para. 59); and
using rule induction to generate the rules based on the class-based tuples (KPI definitions are created based on the information sent by Network Element 1, and may be changeable on the fly and can be given as rules or formulas or in any format, para. 92).
In regard to claim 4, Hatonen et al. teach the process of claim 1 wherein executing the separate rule learning engine that generates rules for detecting the problem with the component comprises storing the rules for each component in a knowledge base of a data storage device (the learning process is forming a reference, based on the input vector and a previous value of the reference or at least one previous input vector, for describing the behavior of the observable object, para. 21-25).
In regard to claim 5, Hatonen et al. teach a computer system for troubleshooting and resolving problems with objects of a cloud infrastructure, the computer system comprising:
a display screen (monitoring/reporting device, para. 96);
one or more processors (a computer, para. 96);
one or more data-storage devices (database, para. 150); and
machine-readable instructions stored in the one or more data-storage devices that when executed using the one or more processors control the system to perform operations (rules or formulas that can be executed by a computer, para. 92) comprising:
monitoring a key performance indicator ("KPI") of an object running in the cloud infrastructure for abnormal behavior of the object (collecting data from an observable object where anomalies are detected based on user-definable key performance indicators (KPIs) of the observable objects, para. 28);
displaying a graphical user interface ("GUI") in a display device that enables a user to select KPIs of components of the object for generating rules to detect the problem (KPIs can be defined by the user, para. 32);
for each of the components, executing a separate rule learning engine that generates rules for detecting a problem with the component based on the KPI of the object and the KPIs of the component (monitor the behavior of the object where at least one parameter of the observable object is detected, the parameter is checked with regard to a predetermined criteria, a vector is formed based on the monitored parameter, Key Performance Indicators (KPIs) which are computed and monitored measure the quality of service, para. 14-25);
using the rules to detect a runtime problem with the object (anomalies are detected, para. 28-31).
Hatonen et al. does not explicitly teach display at least one remedial measure for resolving the problem in the GUI based on runtime metric values of the KPIs of the components; and executing at least one of the remedial measures to resolve the problem with the object via the GUI.
Vijayan et al. teach of the remedial action can also include visually identifying the problem to an operator (para. 86), the GUI can include a notification log and also instructions can be available to guide the operator in manually fixing the problem (para. 87), and clicking on the log provided information can launch performance reports and remediation workflows (para. 88).
Refer to claim 1 for motivational statement.
In regard to claim 6, Hatonen et al. teach the system of claim 5 wherein monitoring the KPI of the object comprises:
displaying the KPI of the object in a user selected time interval in the GUI (provide anomaly information reports and heartbeat reports and send these reports to a network element TS 13, para. 98, provides visibility to the network status in real-time at anytime and anywhere, para. 99); and
selecting the KPI for rule generating the rules via the GUI (the KPI definitions may be changeable on the fly, para. 92).
In regard to claim 7, Hatonen et al. teach the system of claim 5 wherein executing the separate rule learning engine that generates rules for detecting the problem with the component comprises:
applying min-max smoothing to time synchronize the KPI of the object and each of the KPIs of the component to the same time indices (finding best mapping nodes or cluster centroids for incoming vectors, counting distance between new incoming vectors and the best mapping node or cluster centroid, para. 51-56);
for each time index, forming a class-based tuple of metric values of the KPIs and a class label of the KPI of the object (RTT reports is a structured report of an event in the network that consisting of fixed-width fields in a predefined order, para. 59); and
using rule induction to generate the rules based on the class-based tuples (KPI definitions are created based on the information sent by Network Element 1, and may be changeable on the fly and can be given as rules or formulas or in any format, para. 92).
In regard to claim 8, Hatonen et al. teach the system of claim 5 wherein executing the separate rule learning engine that generates rules for detecting the problem with the component comprises storing the rules for each component in a knowledge base of a data storage device (the learning process is forming a reference, based on the input vector and a previous value of the reference or at least one previous input vector, for describing the behavior of the observable object, para. 21-25).
In regard to claim 9, Hatonen et al. teach a non-transitory computer-readable medium having instructions encoded thereon for enabling one or more processors of a computer system to perform operations comprising:
monitoring a key performance indicator ("KPI") of an object running in the cloud infrastructure for abnormal behavior of the object (collecting data from an observable object where anomalies are detected based on user-definable key performance indicators (KPIs) of the observable objects, para. 28);
displaying a graphical user interface ("GUI") in a display device that enables a user to select KPIs of components of the object for generating rules to detect the problem (KPIs can be defined by the user, para. 32);
for each of the components, executing a separate rule learning engine that generates rules for detecting a problem with the component based on the KPI of the object and the KPIs of the component (monitor the behavior of the object where at least one parameter of the observable object is detected, the parameter is checked with regard to a predetermined criteria, a vector is formed based on the monitored parameter, Key Performance Indicators (KPIs) which are computed and monitored measure the quality of service, para. 14-25);
using the rules to detect a runtime problem with the object (anomalies are detected, para. 28-31).
Hatonen et al. does not explicitly teach display at least one remedial measure for resolving the problem in the GUI based on runtime metric values of the KPIs of the components; and executing at least one of the remedial measures to resolve the problem with the object via the GUI.
Vijayan et al. teach of the remedial action can also include visually identifying the problem to an operator (para. 86), the GUI can include a notification log and also instructions can be available to guide the operator in manually fixing the problem (para. 87), and clicking on the log provided information can launch performance reports and remediation workflows (para. 88).
Refer to claim 1 for motivational statement.
In regard to claim 10, Hatonen et al. teach the medium of claim 9 wherein monitoring the KPI of the object comprises:
displaying the KPI of the object in a user selected time interval in the GUI (provide anomaly information reports and heartbeat reports and send these reports to a network element TS 13, para. 98, provides visibility to the network status in real-time at anytime and anywhere, para. 99); and
selecting the KPI for rule generating the rules via the GUI (the KPI definitions may be changeable on the fly, para. 92).
In regard to claim 11, Hatonen et al. teach the medium of claim 9 wherein executing the separate rule learning engine that generates rules for detecting the problem with the component comprises:
applying min-max smoothing to time synchronize the KPI of the object and each of the KPIs of the component to the same time indices (finding best mapping nodes or cluster centroids for incoming vectors, counting distance between new incoming vectors and the best mapping node or cluster centroid, para. 51-56);
for each time index, forming a class-based tuple of metric values of the KPIs and a class label of the KPI of the object (RTT reports is a structured report of an event in the network that consisting of fixed-width fields in a predefined order, para. 59); and
using rule induction to generate the rules based on the class-based tuples (KPI definitions are created based on the information sent by Network Element 1, and may be changeable on the fly and can be given as rules or formulas or in any format, para. 92).
In regard to claim 12, Hatonen et al. teach the medium of claim 9 wherein executing the separate rule learning engine that generates rules for detecting the problem with the component comprises storing the rules for each component in a knowledge base of a data storage device (the learning process is forming a reference, based on the input vector and a previous value of the reference or at least one previous input vector, for describing the behavior of the observable object, para. 21-25).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See PTO 892.
Harutyunyan et al. (US 12,056,002) VMware, remedial measure for KPI values monitored
Sipple (US 2014/0095425) predicting events
Kimotho et al. (US 9,069,737) machine learning for troubleshooting and remedy
Osuala et al. (US 11,748,384) determining an association rule
Ben Ami et al. (US 2025/0168183) detecting anomalous events
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Loan Truong whose telephone number is 408-918-7552. The examiner can normally be reached on 10AM-6PM PST M-F.
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, Ashish Thomas can be reached on 571-272-0631. 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.
/Loan L.T. Truong/Primary Examiner, Art Unit 2114 HYPERLINK "mailto:Loan.truong@uspto.gov" Loan.truong@uspto.gov
Prosecution Insights