DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This is a response to U.S. Patent Application No. 18/652,571 filed on 05/01/2024 in which Claims 1 – 20 were filed for examination.
Status of the Claims
Claims 6 and 17 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, Claims 12 – 20 are rejected under 35 U.S.C. 101 and Claims 1, 4 – 12 and 15 – 20 are rejected under 35 U.S.C. 103.
Examiner Note
The Examiner cites particular columns, line numbers and/or paragraph numbers in the references as applied to the claims below for the convenience of the Applicant(s). Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the Applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
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 6 and 17 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.
Claim 6 recites the limitation "wherein: the target anomaly context includes a pre-anomaly state of the IAS, wherein a pre-anomaly state of the IAS includes one or more precent…” in lines 2 – 3 of claim 6 (emphasis added).
There is insufficient antecedent basis for this limitation in the claim.
Claim 17 recites the same language, thus claim 17 is also rejected for the same reason.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 12 – 20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
In summary, Claim 12 recites an “anomaly detection and resolution system” that comprises an “anomaly detection engine” and “an anomaly solution engine.”
The specification of the present application recites “anomaly detection and resolution system 102 may be implemented as any one or combination of hardware, firmware, or software (See par 0041). Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system (See Par 0092)”.
Accordingly, the Specification of the present application fails to expressly limit any of the recited components to a computer hardware embodiment.
For purposes of examination, the examiner will interpret each of these elements merely as computer software elements. Thus, the recited “anomaly detection and resolution system” is software per se.
Accordingly, the “anomaly detection and resolution system” is not a “process,” a “machine,” a “manufacture” or a “composition of matter,” and Claim 12 fails to recite statutory subject matter, as defined in 35 U.S.C. 101.
Claims 13 – 20 merely recite either electronic data or functions performed by the software. Thus, Claims 13 – 20 do not further define the recited “anomaly detection and resolution system” as being within a statutory process, machine, manufacture or composition of matter.
Accordingly, Claims 12 – 20 fail to recite statutory subject matter as defined in 35 U.S.C. 101.
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.
Claims 1, 4 – 12 and 15 – 20 are rejected under 35 U.S.C. 103 as being unpatentable over Thimmanaik et al. (US 2022/0066435) (hereinafter, Thimmanaik) in view of COBB et al. (US 2022/0321585) (hereinafter, Cobb).
Regarding Claim 1, Thimmanaik teaches a method of anomaly detection and resolution (See Thimmanaik’s Abstract), the method comprising:
detecting, by an anomaly detection engine, a target anomaly in an industrial automation system (IAS) (Thimmanaik in par 0033, teaches detecting anomalies in industrial processes based on audio and/or visual artifacts. Detect porosity during welding operation based on audio and/or video captured during the welds), wherein the detecting comprises detecting a target anomaly description (Thimmanaik in par 0060, further teaches that data streams generated during welding operations may be used to detect faulty welds. As an example, audio and/or video streams captured during a weld may be analyzed to determine whether (and when) the weld becomes contaminated by porosity), a target anomaly context, and a code block source of the target anomaly, and wherein the IAS comprises one or more industrial devices controlled by one or more industrial controllers (Thimmanaik in par 0047, teaches that anomaly detection is performed based on data streams that are generated whenever a particular industrial process—such as welding—is performed on the production line 102. Moreover, the data stream may include values for a collection of parameters, or “features,” relating to the performance of that industrial process. For example, the data stream may include a collection of data and/or metadata associated with the performance of the industrial process, such as reference or configuration parameters (e.g., parameters used to configure a robot or tool to perform the industrial process), audio and/or video captured during the industrial process, voltage and current readings for equipment/tools used to perform the industrial process, and/or any other parameters or data captured or measured during the industrial process (e.g., by sensors, controllers, and/or other devices and equipment). Thimmanaik in par 0061, further teaches that in this manner real-time quality control or anomaly detection can be performed on the production line, such as detecting faulty production tasks (e.g., faulty welds), detecting faulty parts used or produced on the production line (e.g., parts produced with faulty welds), performing appropriate remedial measures to minimize the impact of detected faults (e.g., aborting, reworking, and/or scrapping parts with faulty welds), proactively performing certain preventive measures to prevent or minimize future faults during production (e.g., performing configuration changes and/or maintenance tasks), and so forth);
identifying, by an anomaly solution engine, a reference anomaly solution (Thimmanaik in par 0083 – 0084, teaches that to avoid false positives, the inference results for a particular stream may be averaged over a rolling time window, and an anomaly may only be detected if the average for the rolling window exceeds some threshold. For example, with respect to a video stream captured during a weld operation, the likelihood of an anomaly may be averaged for a rolling number of frames in the video stream—such as the most recent 16-18 frames—and an anomaly may be detected if the average exceeds a threshold (e.g., 95% likelihood of an anomaly). The compute device may then trigger an appropriate action upon detecting an anomaly, such as sending a command to the corresponding robot/tool controller to abort the weld operation);
generating, at the anomaly solution engine, a target anomaly solution (Thimmanaik in par 0084, further teaches that the compute device may then trigger an appropriate action upon detecting an anomaly, such as sending a command to the corresponding robot/tool controller to abort the weld operation); and
deploying the target anomaly solution to the IAS (Thimmanaik in par 0084, further teaches that the compute device may then trigger an appropriate action upon detecting an anomaly, such as sending a command to the corresponding robot/tool controller to abort the weld operation. Thimmanaik in par 0094, further teaches that if porosity is detected, however, then at step 516, an appropriate action is triggered in response. For example, a command may be sent to a robot controller to cause the robotic welding arm to abort the weld, repeat part of the weld, etc.).
However, Thimmanaik does not specifically disclose wherein generating the target anomaly solution comprises modifying the reference anomaly solution based at least in part on the target anomaly context to tailor the reference anomaly solution for application to the target anomaly.
Cobb teaches a method for detecting an anomalous state in a machine (See Cobb’s Abstract).
Cobb in par 0037, teaches that the anomaly detection server learns all trained combinations of data (i.e., all relevant combinations of states, sequences, and timing data) and categorizes such trained combination data for rapid checking. Such categorized data may be used to create the signature or boundary conditions. The patterns for normal states, sequences, and timing may be stored in any suitable database that is included within or in connection with the anomaly detection server.
Cobb in par 0039 - 0040, further teaches that if the anomaly detection server determines that a discrepancy exists between the monitoring analysis vectors and normal patterns, it transmits an alert indicating an anomaly or a potential anomaly. Upon each alert of an anomaly, the ADS may capture information for resolution of the detected anomaly. The captured information may allow a user to input at the ADI that the anomaly was a false positive. Such false positive information is used by the anomaly detection server to retrain the models for normal states, sequences, and timing and avoid a future false positive that is the same or similar. In a second example, the captured information may allow a user to enter input at the ADI identifying the diagnosis of the anomaly, the applied solution, and any result information. The anomaly detection server uses such input to provide more sophisticated diagnostic and analytic recommendations when future anomalies are detected.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to utilize the teachings as in Cobb with the teachings as in Thimmanaik to select possible solutions to an anomaly un Thimmanaik as disclosed in in Cobb. The motivation for doing so would have been to detect anomalies in industrial machines to reduce time to investigate machine performance, reduce mean time to repair (“MTTR”) machinery, reduce downtime, and improve industrial stability (See Cobb’s par 0021).
Regarding Claim 4, Thimmanaik in view of Cobb teaches the limitations contained in parent Claim 1. Cobb further teaches:
wherein detecting the target anomaly further includes a logging of the target anomaly in an anomaly logger (Cobb in par 0040, further teaches that anomalous data is used to train the machine learning model of the anomaly detection server, the analysis vectors for such anomalies may also be associated with details identifying components or parts that are anomalous and possible solutions to resolve the anomaly. In other examples, upon each alert of an anomaly, the ADS may capture information for resolution of the detected anomaly. In a second example, the captured information may allow a user to enter input at the ADI identifying the diagnosis of the anomaly, the applied solution, and any result information. The anomaly detection server uses such input to provide more sophisticated diagnostic and analytic recommendations when future anomalies are detected).
Regarding Claim 5, Thimmanaik in view of Cobb teaches the limitations contained in parent Claim 1. Thimmanaik further teaches:
wherein the target anomaly comprises a nonconforming data entry in the IAS, an unexpected behavior in the IAS, a nonconforming output in the IAS, a logic fault in the IAS, or a combination thereof (Thimmanaik in par 0060, further teaches that data streams generated during welding operations may be used to detect faulty welds. As an example, audio and/or video streams captured during a weld may be analyzed to determine whether (and when) the weld becomes contaminated by porosity).
Regarding Claim 6, Thimmanaik in view of Cobb teaches the limitations contained in parent Claim 1. Thimmanaik further teaches:
wherein: the target anomaly context includes a pre-anomaly state of the IAS (Thimmanaik in par 0047, further teaches that a corresponding data stream may be generated each time the particular industrial process is performed. Moreover, the data stream may include values for a collection of parameters, or “features,” relating to the performance of that industrial process. For example, the data stream may include a collection of data and/or metadata associated with the performance of the industrial process, such as reference or configuration parameters (e.g., parameters used to configure a robot or tool to perform the industrial process),wherein a pre-anomaly state of the IAS includes one or more precedent logical states of the IAS, one or more precedent register values of a processor in the IAS, one or more precedent actions of a device or controller of the IAS, one or more precedent anomalies in the IAS, or a combination thereof (Thimmanaik in par 0070, teaches that supervised learning techniques can be used to train a machine learning model to detect porosity based on a labeled training dataset (e.g., audio or video samples captured during past welds that have been manually labeled with an indication of whether porosity occurred. Thimmanaik in par 0047, further teaches that a corresponding data stream may be generated each time the particular industrial process is performed. Moreover, the data stream may include values for a collection of parameters, or “features,” relating to the performance of that industrial process. For example, the data stream may include a collection of data and/or metadata associated with the performance of the industrial process, such as reference or configuration parameters (e.g., parameters used to configure a robot or tool to perform the industrial process), and
the target anomaly comprises one or more precedent conditions that induce a nonconforming data entry in the IAS, an unexpected behavior in the IAS, a nonconforming output in the IAS, a logic fault in the IAS, or a combination thereof (Thimmanaik in par 0084, further teaches that the compute device may then trigger an appropriate action upon detecting an anomaly, such as sending a command to the corresponding robot/tool controller to abort the weld operation. Thimmanaik in par 0094, further teaches that if porosity is detected, however, then at step 516, an appropriate action is triggered in response. For example, a command may be sent to a robot controller to cause the robotic welding arm to abort the weld, repeat part of the weld, etc.).
Regarding Claim 7, Thimmanaik in view of Cobb teaches the limitations contained in parent Claim 1. Thimmanaik further teaches:
wherein detecting the target anomaly comprises:
polling the IAS based on: an automated analysis of a codebase underlying the IAS; a user-initiated analysis of a codebase underlying the IAS; or a combination thereof (Thimmanaik in par 0026, teaches Predictive analytics could potentially be leveraged to automate quality control on the production line, such that defects and anomalies that occur during product manufacturing are detected in real time based on data generated by equipment on the manufacturing floor (e.g., machines, robots, tools, sensors). Thimmanaik in par 0048 – 0059, further teaches that a corresponding data stream may be generated every time a welding operation is performed on the production line 102. The data stream for a welding operation may include an identifier of the particular robot, robot arm, and welding fun that performed the weld, the voltage curve, current curve, force, and torque for the welding gun and/or other equipment/tools used to perform the weld. The data streams generated for these industrial processes can be ingested and analyzed—at the edge (e.g., by compute servers 110a-e) or in the cloud—to perform quality control or anomaly detection).
Regarding Claim 8, Thimmanaik in view of Cobb teaches the limitations contained in parent Claim 1. Cobb further teaches:
wherein generating a target anomaly solution further comprises: replicating, at a central anomaly index, a topology of the IAS (Cobb in par 0027 – 0028, further teaches that the anomaly detection server is configured to receive registration input defining machines within a production environment. Each machine is capable of performing one or more steps reflecting physical actions that a machine may take. In most examples, the registration input defines physical attributes of each machine including the input that may be provided by each machine with respect to its performance. The registration input may also define the sequence of steps performed by each machine. The registration input may also define the steps of multiple machines with respect to one another in a process and allow the anomaly detection server to therefore identify anomalies within the sequenced process across machines. The registration input may also include purpose information defining the purpose of each machine. Thus, the anomaly detection server is configured to receive registration input defining each machine including purpose definitions, phase definitions, and step definitions. The anomaly detection server applies the registration input to create a first map configured to convert condition data into an analysis vector for the machine. Specifically, the first map allows the anomaly detection server to generate the analysis vector based on condition data received, directly or indirectly, from each machine. The anomaly detection server similarly may be configured to map each machine with respect to sequence and timing and to learn normal operating states, sequences, and timings (“SQT”) based on the corresponding data. In so doing, the anomaly detection server is configured to essentially reverse engineer a finite-state machine (“FSM”) model for each machine as the anomaly detection server learns all (or nearly all) possible normal patterns for each of SQT).
Regarding Claim 9, Thimmanaik in view of Cobb teaches the limitations contained in parent Claim 1. Thimmanaik further teaches:
wherein training data for the anomaly solution engine includes one of safety standards data, industry standards data, industry best practices data, internal procedures data, internal documentation data, device documentation data, or a combination thereof (Thimmanaik in par 0070, teaches that supervised learning techniques can be used to train a machine learning model to detect porosity based on a labeled training dataset (e.g., audio or video samples captured during past welds that have been manually labeled with an indication of whether porosity occurred). Thimmanaik in par 0080 – 0081, further teaches that each video/audio stream for a weld operation contaminated by porosity may be labeled with the start time at which the porosity occurs. This labeled dataset is referred to as the training data, which is used to train the anomaly detection model. The AI model development system uses the training data to identify the problem area and train the anomaly detection model using the appropriate supervised learning techniques).
Regarding Claim 10, Thimmanaik in view of Cobb teaches the limitations contained in parent Claim 1. Thimmanaik further teaches:
further comprising: training the anomaly detection engine using data from a central anomaly index (Thimmanaik in par 0070, teaches that supervised learning techniques can be used to train a machine learning model to detect porosity based on a labeled training dataset (e.g., audio or video samples captured during past welds that have been manually labeled with an indication of whether porosity occurred). Thimmanaik in par 0080 – 0081, further teaches that each video/audio stream for a weld operation contaminated by porosity may be labeled with the start time at which the porosity occurs. This labeled dataset is referred to as the training data, which is used to train the anomaly detection model. The AI model development system uses the training data to identify the problem area and train the anomaly detection model using the appropriate supervised learning techniques).
Regarding Claim 11, Thimmanaik in view of Cobb teaches the limitations contained in parent Claim 1. Cobb further teaches:
further comprising:
logging the target anomaly and solution; determining the target anomaly solution resolves the target anomaly; and feeding the log of the target anomaly and solution back to a central anomaly index (Cobb in par 0040, further teaches that anomalous data is used to train the machine learning model of the anomaly detection server, the analysis vectors for such anomalies may also be associated with details identifying components or parts that are anomalous and possible solutions to resolve the anomaly. In other examples, upon each alert of an anomaly, the ADS may capture information for resolution of the detected anomaly. In a second example, the captured information may allow a user to enter input at the ADI identifying the diagnosis of the anomaly, the applied solution, and any result information. The anomaly detection server uses such input to provide more sophisticated diagnostic and analytic recommendations when future anomalies are detected).
Regarding Claim 12, this Claim merely recites an anomaly detection and resolution system executing the steps as similarly recited in Claim 1. Accordingly, Thimmanaik in view of Cobb discloses/teaches every limitation of Claim 12, as indicated in the above rejection of Claim 1.
Regarding Claim 15, this Claim merely recites an anomaly detection and resolution system executing the steps as similarly recited in Claim 4. Accordingly, Thimmanaik in view of Cobb discloses/teaches every limitation of Claim 15, as indicated in the above rejection of Claim 4.
Regarding Claim 16, this Claim merely recites an anomaly detection and resolution system executing the steps as similarly recited in Claim 5. Accordingly, Thimmanaik in view of Cobb discloses/teaches every limitation of Claim 16, as indicated in the above rejection of Claim 5.
Regarding Claim 17, this Claim merely recites an anomaly detection and resolution system executing the steps as similarly recited in Claim 6. Accordingly, Thimmanaik in view of Cobb discloses/teaches every limitation of Claim 17, as indicated in the above rejection of Claim 6.
Regarding Claim 18, this Claim merely recites an anomaly detection and resolution system executing the steps as similarly recited in Claim 7. Accordingly, Thimmanaik in view of Cobb discloses/teaches every limitation of Claim 18, as indicated in the above rejection of Claim 7.
Regarding Claim 19, this Claim merely recites an anomaly detection and resolution system executing the steps as similarly recited in Claim 8. Accordingly, Thimmanaik in view of Cobb discloses/teaches every limitation of Claim 19, as indicated in the above rejection of Claim 8.
Regarding Claim 20, this Claim merely recites an anomaly detection and resolution system executing the steps as similarly recited in Claim 9. Accordingly, Thimmanaik in view of Cobb discloses/teaches every limitation of Claim 20, as indicated in the above rejection of Claim 9.
Allowable Subject Matter
Claims 2, 3, 13 and 14 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ARIEL MERCADO VARGAS whose telephone number is (571)270-1701. The examiner can normally be reached M-F 8:00am - 4:00pm.
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, Scott Baderman can be reached at 571-272-3644. 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.
/ARIEL MERCADO-VARGAS/Primary Examiner, Art Unit 2118
Prosecution Insights