Prosecution Insights
Last updated: April 19, 2026
Application No. 17/568,321

METHOD AND APPARATUS FOR TRACING FAULT OF COLLABORATIVE ROBOT

Final Rejection §103
Filed
Jan 04, 2022
Examiner
OSTROW, ALAN LINDSAY
Art Unit
3657
Tech Center
3600 — Transportation & Electronic Commerce
Assignee
Ajou University Industry-Academic Cooperation Foundation
OA Round
6 (Final)
74%
Grant Probability
Favorable
7-8
OA Rounds
2y 7m
To Grant
99%
With Interview

Examiner Intelligence

Grants 74% — above average
74%
Career Allow Rate
26 granted / 35 resolved
+22.3% vs TC avg
Strong +38% interview lift
Without
With
+37.7%
Interview Lift
resolved cases with interview
Typical timeline
2y 7m
Avg Prosecution
30 currently pending
Career history
65
Total Applications
across all art units

Statute-Specific Performance

§101
14.0%
-26.0% vs TC avg
§103
57.7%
+17.7% vs TC avg
§102
15.8%
-24.2% vs TC avg
§112
10.4%
-29.6% vs TC avg
Black line = Tech Center average estimate • Based on career data from 35 resolved cases

Office Action

§103
DETAILED ACTION Status of Claims Claims 15, 17-19, and 21-22 are currently pending and have been examined in this application. This Final Rejection is in response to the amendment submitted on 11/17/2025. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . Priority Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55. Response to Arguments and Amendments Applicant’s arguments, filed on 11/17/2025, with respect to the rejection of claims 15-22 under 35 USC 103 have been fully considered but they are not persuasive. The rejection has been maintained. Regarding 35 USC 103: Issue: Applicant asserts that Lee (US 20190196893 A1) does not teach a “hierarchical” data structure as presented in the instant claims 16 and 20. Applicant has cancelled claims 16 and 20 and incorporated these limitations into independent claims 15 and 19 respectively. Applicant Remarks: “According to the paragraph [0120] of Lee, the phrase "gathered operational data according to the degree of similarity with the normal data pattern" necessarily implies the existence of pre-generated normal data and means that the data detected from the appliance is merely compared with that normal data pattern. Therefore, the "hierarchical structure' of the present invention is not derivable from Lee. Furthermore, the subsequent phrase, "classified operational data... in order of higher chance of being classified as abnormal data," means that data with a low degree of similarity (i.e., less similarity to the normal data) is classified as abnormal data. Therefore, the 'hierarchical structure' of the present invention is also not derivable from Lee. “ Examiner Reply: Applicant asserts that Lee (US 20190196893 A1) does not teach a “hierarchical” data structure as presented in the instant claims 16 and 20. However the examiner notes that, under BRI, the plain meaning of a ”hierarchical structure” can be a ranked system where elements are organized in levels, and/or where ranks (positions/levels) are organized in a graded order. A citation form Lee paragraph [0120] reads,”… the appliance may classify the gathered operation data according to the degree of similarity…” and further describes, “ …transmit the classified operation data to the managing server in order of higher chance of being classified as abnormal data…”. Given the plain meaning of hierarchical, Lee does teach a hierarchy and since Lee was only cited to teach a hierarchy in combination with Inagaki and Ghose, Lee reads on claims 16 and 20 of the previous non-final office action. For at least the reasons mentioned above, the rejection has been maintained. Claim Rejections - 35 USC § 103 Claim(s) 15, 17-19, and 21-22 are rejected under 35 U.S.C. 103 as being unpatentable over Inagaki (US 20170031329 A1) as modified by Ghose (US 20190283254 A1) in view of Lee (US 20190196893 A1). Claim 15: Inagaki teaches the following limitations: A method for tracing a fault of a collaborative robot in a system for fault tracing, the system comprising the collaborative robot and an electronic device including a controller and a memory configured to store an operational data of the collaborative robot, the method comprising: (Inagaki - [0037] The robot 2 illustrated as FIG. 1 is implemented in a six-axis vertical articulated robot with its respective joints driven by motors. The robot 2 is connected to a robot controller 3 via a known communication means. The robot controller 3 generates a command for the robot 2 in accordance with a control program. [0063] As methods for sharing training data sets for a plurality of robots 2, three examples will be given below, but other methods may be applicable, as a matter of course. First, a method for sharing the same model for a neural network is available, in which, for example, the difference between respective robots 2 is sent and reflected using a communication means, for each weighting factor of a network. Second, the weight of the machine learning device 5 and the like may be shared by sharing a data set of the input and output of a neural network. Third, a given database is provided and accessed to load a more appropriate model for a neural network to share the state (use similar models).) generating, by the controller, basic indexes for the operational data of the collaborative robot, the basic indexes including a program ID indicating a type of program performed by the collaborative robot, (Inagaki - [0062] In an embodiment, the learning unit 53 may learn fault conditions in accordance with training data sets generated for a plurality of robots 2. The learning unit 53 may obtain training data sets from a plurality of robots 2 used in the same location or learn fault conditions using training data sets collected from a plurality of robots 2 independently operating in different locations..) detecting the fault of the collaborative robot; determining a second analysis index, among the second analysis indexes, corresponding to a point at which the fault is detected; determining a first analysis index among the first analysis indexes based on the second analysis index; (Inagaki – [0009] … a determination data obtaining unit that obtains determination data used to determine one of whether a fault has occurred in the industrial machine and a degree of fault; and a learning unit that learns the condition associated with the fault of the industrial machine … ; [0067] … (b) of FIG. 7. In, e.g., the third example, a plurality of thresholds (thresholds 1 to 3) may be set for the above-mentioned index value, and the fault information output unit 42 can output as fault information, threshold-specific levels (fault levels 1 to 4), as illustrated as (c) of FIG. 7.) determining a program and a motion performed by the collaborative robot (Inagaki – [0021] … obtaining determination data used to determine one of whether a fault has occurred in the industrial machine and a degree of fault; and learning the condition associated with the fault of the industrial machine in accordance with a training data set generated based on a combination of the state variable and the determination data.) Examiner Note: Training data sets corresponds to basic index Threshold Value corresponds to Target Inagaki does not explicitly teach the following limitations, however Ghose teaches: a motion ID indicating motion in each of the program, a program execution index indicating the number of times the program has been executed, and a motion execution index indicating the number of times the motion has been executed; (Ghose - [0006] In another aspect, a system for fault detection in robotic actuation is provided. The system includes a plurality of mobile robots, wherein each mobile robot from the plurality of mobile robots is associated with an actuation data gathering unit, wherein the actuation data gathering unit includes a plurality of sensors. A plurality of computing devices, wherein each computing device includes one or more memories comprising programmed instructions, a repository for storing the set of tasks associated with each mobile robot, ; [0032] The data repository 240 may include received set of tasks, a training database 244, a test database 246 and other data 248. Further, the other data 248 amongst other things, may serve as a repository for storing data that is processed, received, or generated as a result of the execution of one or more modules in the module(s) 220 and the modules associated with the DL analytics unit 250.; (0033) Although the data repository 240 is shown internal to the system 200, it will be noted that, in alternate embodiments, the data repository 240 can also be implemented external to the system 200,) wherein the program ID, the motion ID, the program execution index and the motion execution index (Ghose - [0006] In another aspect, a system for fault detection in robotic actuation is provided. The system includes a plurality of mobile robots, wherein each mobile robot from the plurality of mobile robots is associated with an actuation data gathering unit, wherein the actuation data gathering unit includes a plurality of sensors. A plurality of computing devices, wherein each computing device includes one or more memories comprising programmed instructions, a repository for storing the set of tasks associated with each mobile robot, ; [0032] The data repository 240 may include received set of tasks, a training database 244, a test database 246 and other data 248. Further, the other data 248 amongst other things, may serve as a repository for storing data that is processed, received, or generated as a result of the execution of one or more modules in the module(s) 220 and the modules associated with the DL analytics unit 250.; [0033] Although the data repository 240 is shown internal to the system 200, it will be noted that, in alternate embodiments, the data repository 240 can also be implemented external to the system 200,) generating, by the controller, analysis IDs by combining the program ID and the motion ID; generating, by the controller, first analysis indexes by combining the program execution index and the motion ID; (Ghose - [Abstract] A data driven approach for fault detection in robotic actuation is disclosed. Here, a set of robotic tasks are received and analyzed by a Deep Learning (DL) analytics. The DL analytics includes a stateful (Long Short Term Memory) LSTM. Initially, the stateful LSTM is trained to match a set of activities associated with the robots based on a set of tasks gathered from the robots in a multi robot environment. Here, the stateful LSTM utilizes a master slave framework based load distribution technique and a probabilistic trellis approach to predict a next activity associated with the robot with minimum latency and increased accuracy. Further, the predicted next activity is compared with an actual activity of the robot to identify any faults associated robotic actuation.; [0045] In an embodiment, pre-training the stateful LSTM includes (i) receiving the set of actuation data associated with the robot from a database (ii) detecting a plurality of action units using displacement and rotation values associated with the set of actuation data (iii) computing a prior probability associated with the plurality of action units and (iv) training the stateful LSTM network based on the prior probability.) generating, by the controller, second analysis indexes by combining the first analysis indexes and the motion execution index; (Ghose - [0006] In another aspect, a system for fault detection in robotic actuation is provided. The system includes a plurality of mobile robots, wherein each mobile robot from the plurality of mobile robots is associated with an actuation data gathering unit, wherein the actuation data gathering unit includes a plurality of sensors. …, a Deep Learning (DL) analytics, wherein the DL analytics unit is configured to receive, a set of tasks in the form of time series from the actuation data gathering unit associated with each mobile robot from the plurality of mobile robots, wherein the a set of tasks comprises a set of actuation data associated with each mobile robot from the plurality of mobile robots. … Furthermore, the DL analytics unit is configured to detect, a fault associated with each robot from the plurality of robots by comparing, the next activity with the actual activity associated with the robot.) determining an analysis ID among the analysis IDs based on-a the first analysis index; and (Ghose - [0045] In an embodiment, pre-training the stateful LSTM includes (i) receiving the set of actuation data associated with the robot from a database (ii) detecting a plurality of action units using displacement and rotation values associated with the set of actuation data (iii) computing a prior probability associated with the plurality of action units and (iv) training the stateful LSTM network based on the prior probability.) based on the analysis ID. (Ghose – [0034] The DL analytics unit 250 of the system 200 can be configured to receive, a set of tasks in the form of time series from a plurality of robots, wherein the set of tasks includes a set of actuation data associated with each robot from the plurality of robots. Wherein, the set of actuation data includes a set of displacement data and a set of rotation data. . ; [0035] Further, the DL analytics unit 250 of the system 200 can be configured to compute a next activity associated with each robot based on a Deep Learning (DL) analytics, wherein the DL analytics is a RNN based LSTM, trained based on an optimal resource allocation technique to minimize computation cost and learning time, … ) Examiner Note: set of tasks corresponds to program ID and motion ID data repository corresponds to execution index (which further comprises the program execution index and the motion index) actuation data corresponds to analysis ID stateful LSTM corresponds to analysis index Inagaki in combination with Ghose does not explicitly teach the following limitations, however Lee teaches: (wherein the respective data) are hierarchical in sequence. ( Lee - [0120] According to an embodiment, the appliance may classify the gathered operation data according to the degree of similarity with the normal data pattern given by the data pattern detection routine, and upon receipt of an additional data request signal from the managing server, transmit the classified operation data to the managing server in order of higher chance of being classified as abnormal data.) Therefore, prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to modify Inagaki to include a method of processing the state variables and determination data sets so that a robot can more effectively identify a fault utilizing the stateful LSTM, data repository, training database and Deep Learning Analytics as taught in Ghose. This would enable a method of effectively tracing faults by providing time series information, data bases, and various processors for the purpose of storing, training, and processing normal and abnormal data in real time for the Machine Learning Model. It would further be obvious to include a method of effectively identifying a fault by utilizing a managing server to place all operational data into a hierarchical structure, matching the existing abnormal data with the received abnormal data, and determine if the abnormal data exceeds a predetermined threshold, as taught by Lee. This procedure, as taught by Lee, would allow for more effectively tracing faults, identifying thresholds and processing abnormal data in real time for the Machine Learning Model. Claim 17: Inagaki teaches the following limitations: The method of claim 15, further comprising: determining a reason of the fault by tracing the program and the motion (Inagaki - [0039] The fault determination unit 31 determines a fault of the robot 2, using the known fault diagnosis method. The fault determination unit 31 determines whether a fault has occurred in the robot 2 or the degree of fault, independently of fault information generated by the fault prediction system 1. When, for example, a disturbance torque detected by a torque sensor or the amplitude of vibration of data output from a sensor exceeds a predetermined threshold, the fault determination unit 31 determines that a fault has occurred. Alternatively, the fault determination unit 31 may determine that a fault has occurred in the robot 2, based on internal data of control software stored in the robot controller 3. In this manner, the fault determination unit 31 determines faults based on various factors. The determination result obtained by the fault determination unit 31 is input to a determination data obtaining unit 51 of the machine learning device 5 (to be described later). ; [0051] In step S203, the learning unit 53 learns fault conditions in accordance with a training data set generated based on a combination of the state variable obtained in step S201 and the determination data obtained in step S202; [0066] A robot controller 3 can include a notifying unit (fault information notifying unit) 32, as depicted as FIG. 6. The notifying unit 32 notifies the operator of the fault information output from the fault information output unit 42. The mode in which the operator is notified of the fault information is not particularly limited as long as the fault information is identifiable to the operator. For example, information indicating whether a predicted fault has occurred or the degree of fault may be displayed on a display (not illustrated) or an alarm sound may be produced in accordance with the details of the fault information.) Inagaki does not explicitly teach the following limitations, however Ghose teaches: corresponding to the analysis ID. (Ghose – [0034] The DL analytics unit 250 of the system 200 can be configured to receive, a set of tasks in the form of time series from a plurality of robots, wherein the set of tasks includes a set of actuation data associated with each robot from the plurality of robots. Wherein, the set of actuation data includes a set of displacement data and a set of rotation data. . ; [0035] Further, the DL analytics unit 250 of the system 200 can be configured to compute a next activity associated with each robot based on a Deep Learning (DL) analytics, wherein the DL analytics is a RNN based LSTM, trained based on an optimal resource allocation technique to minimize computation cost and learning time, … ) Therefore, prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to modify Inagaki to include a method of processing actuation data, state variables and determination data sets so that a robot can more effectively identify a fault utilizing the stateful LSTM, data repository, training database and Deep Learning Analytics as taught in Ghose. This would enable a method of effectively tracing faults by providing time series information, data bases, and various processors for the purpose of storing, training, and processing normal and abnormal data in real time for the Machine Learning Model. Claim 18: Inagaki teaches the following limitations: The method of claim 15, further comprising: determining reason of the fault in a display of the system. (Inagaki - [0066] A robot controller 3 can include a notifying unit (fault information notifying unit) 32, as depicted as FIG. 6. The notifying unit 32 notifies the operator of the fault information output from the fault information output unit 42. The mode in which the operator is notified of the fault information is not particularly limited as long as the fault information is identifiable to the operator. For example, information indicating whether a predicted fault has occurred or the degree of fault may be displayed on a display (not illustrated) or an alarm sound may be produced in accordance with the details of the fault information.) Claim 19: Inagaki teaches the following limitations: An apparatus for tracing a fault of a collaborative robot, the apparatus comprising: a communicator configured to receive a plurality of operational data from the collaborative robot; a memory configured to store the operational data; and (Inagaki -[0037] The robot 2 illustrated as FIG. 1 is implemented in a six-axis vertical articulated robot with its respective joints driven by motors. The robot 2 is connected to a robot controller 3 via a known communication means. The robot controller 3 generates a command for the robot 2 in accordance with a control program. [0063] As methods for sharing training data sets for a plurality of robots 2, three examples will be given below, but other methods may be applicable, as a matter of course. First, a method for sharing the same model for a neural network is available, in which, for example, the difference between respective robots 2 is sent and reflected using a communication means, for each weighting factor of a network. Second, the weight of the machine learning device 5 and the like may be shared by sharing a data set of the input and output of a neural network. Third, a given database is provided and accessed to load a more appropriate model for a neural network to share the state (use similar models).) a controller configured to: generate basic indexes for the operational data of the collaborative robot, the basic index including a program ID indicating a type of program performed by the collaborative robot, (Inagaki - [0062] In an embodiment, the learning unit 53 may learn fault conditions in accordance with training data sets generated for a plurality of robots 2. The learning unit 53 may obtain training data sets from a plurality of robots 2 used in the same location or learn fault conditions using training data sets collected from a plurality of robots 2 independently operating in different locations..) detect the fault of the collaborative robot; determine a second analysis index, among the second analysis indexes, corresponding to a point at which the fault is detected; determine a first analysis index among the first analysis indexes based on the second analysis index; (Inagaki – [0009] … a determination data obtaining unit that obtains determination data used to determine one of whether a fault has occurred in the industrial machine and a degree of fault; and a learning unit that learns the condition associated with the fault of the industrial machine … ; [0067] … (b) of FIG. 7. In, e.g., the third example, a plurality of thresholds (thresholds 1 to 3) may be set for the above-mentioned index value, and the fault information output unit 42 can output as fault information, threshold-specific levels (fault levels 1 to 4), as illustrated as (c) of FIG. 7.) determine a program and a motion performed by the collaborative robot (Inagaki – [0021] … obtaining determination data used to determine one of whether a fault has occurred in the industrial machine and a degree of fault; and learning the condition associated with the fault of the industrial machine in accordance with a training data set generated based on a combination of the state variable and the determination data.) Inagaki does not explicitly teach the following limitations, however Ghose teaches: a motion ID indicating motion in each of the program, a program execution index indicating the number of times the program has been executed, and a motion execution index indicating the number of times the motion has been executed, (Ghose - [0006] In another aspect, a system for fault detection in robotic actuation is provided. The system includes a plurality of mobile robots, wherein each mobile robot from the plurality of mobile robots is associated with an actuation data gathering unit, wherein the actuation data gathering unit includes a plurality of sensors. A plurality of computing devices, wherein each computing device includes one or more memories comprising programmed instructions, a repository for storing the set of tasks associated with each mobile robot, ; [0032] The data repository 240 may include received set of tasks, a training database 244, a test database 246 and other data 248. Further, the other data 248 amongst other things, may serve as a repository for storing data that is processed, received, or generated as a result of the execution of one or more modules in the module(s) 220 and the modules associated with the DL analytics unit 250.; [0033] Although the data repository 240 is shown internal to the system 200, it will be noted that, in alternate embodiments, the data repository 240 can also be implemented external to the system 200,) wherein the program ID, the motion ID, the program execution index and the motion execution index (Ghose - [0006] In another aspect, a system for fault detection in robotic actuation is provided. The system includes a plurality of mobile robots, wherein each mobile robot from the plurality of mobile robots is associated with an actuation data gathering unit, wherein the actuation data gathering unit includes a plurality of sensors. A plurality of computing devices, wherein each computing device includes one or more memories comprising programmed instructions, a repository for storing the set of tasks associated with each mobile robot, ; [0032] The data repository 240 may include received set of tasks, a training database 244, a test database 246 and other data 248. Further, the other data 248 amongst other things, may serve as a repository for storing data that is processed, received, or generated as a result of the execution of one or more modules in the module(s) 220 and the modules associated with the DL analytics unit 250.; [0033] Although the data repository 240 is shown internal to the system 200, it will be noted that, in alternate embodiments, the data repository 240 can also be implemented external to the system 200,) generate analysis IDs by combining the program ID and the motion ID; generate first analysis indexes by combining the program execution index and the motion ID; (Ghose - [Abstract] A data driven approach for fault detection in robotic actuation is disclosed. Here, a set of robotic tasks are received and analyzed by a Deep Learning (DL) analytics. The DL analytics includes a stateful (Long Short Term Memory) LSTM. Initially, the stateful LSTM is trained to match a set of activities associated with the robots based on a set of tasks gathered from the robots in a multi robot environment. Here, the stateful LSTM utilizes a master slave framework based load distribution technique and a probabilistic trellis approach to predict a next activity associated with the robot with minimum latency and increased accuracy. Further, the predicted next activity is compared with an actual activity of the robot to identify any faults associated robotic actuation.; [0036] In an embodiment, pre-training the stateful LSTM includes (i) receiving the set of actuation data associated with the robot from a database (ii) detecting a plurality of action units using displacement and rotation values associated with the set of actuation data (iii) computing a prior probability associated with the plurality of action units and (iv) training the stateful LSTM network based on the prior probability.) generate second analysis indexes by combining the first analysis indexes and the motion execution index; (Ghose - [0006] In another aspect, a system for fault detection in robotic actuation is provided. The system includes a plurality of mobile robots, wherein each mobile robot from the plurality of mobile robots is associated with an actuation data gathering unit, wherein the actuation data gathering unit includes a plurality of sensors. …, a Deep Learning (DL) analytics, wherein the DL analytics unit is configured to receive, a set of tasks in the form of time series from the actuation data gathering unit associated with each mobile robot from the plurality of mobile robots, wherein the a set of tasks comprises a set of actuation data associated with each mobile robot from the plurality of mobile robots. … Furthermore, the DL analytics unit is configured to detect, a fault associated with each robot from the plurality of robots by comparing, the next activity with the actual activity associated with the robot.) determine an analysis ID among the analysis IDs based on the first analysis index; and (Ghose - [0045] In an embodiment, pre-training the stateful LSTM includes (i) receiving the set of actuation data associated with the robot from a database (ii) detecting a plurality of action units using displacement and rotation values associated with the set of actuation data (iii) computing a prior probability associated with the plurality of action units and (iv) training the stateful LSTM network based on the prior probability.) based on the analysis ID. (Ghose – [0034] The DL analytics unit 250 of the system 200 can be configured to receive, a set of tasks in the form of time series from a plurality of robots, wherein the set of tasks includes a set of actuation data associated with each robot from the plurality of robots. Wherein, the set of actuation data includes a set of displacement data and a set of rotation data. . ; [0035] Further, the DL analytics unit 250 of the system 200 can be configured to compute a next activity associated with each robot based on a Deep Learning (DL) analytics, wherein the DL analytics is a RNN based LSTM, trained based on an optimal resource allocation technique to minimize computation cost and learning time, … ) Examiner Note: set of tasks corresponds to program ID and motion ID data repository corresponds to execution index (which further comprises the program execution index and the motion index) actuation data corresponds to analysis ID stateful LSTM corresponds to analysis index Inagaki in combination with Ghose does not explicitly teach the following limitations, however Lee teaches: (wherein the respective data) are hierarchical in sequence. ( Lee - [0120] According to an embodiment, the appliance may classify the gathered operation data according to the degree of similarity with the normal data pattern given by the data pattern detection routine, and upon receipt of an additional data request signal from the managing server, transmit the classified operation data to the managing server in order of higher chance of being classified as abnormal data.) Therefore, prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to modify Inagaki to include a method of processing the state variables and determination data sets so that a robot can more effectively identify a fault utilizing the stateful LSTM, data repository, training database and Deep Learning Analytics as taught in Ghose. This would enable a method of effectively tracing faults by providing time series information, data bases, and various processors for the purpose of storing, training, and processing normal and abnormal data in real time for the Machine Learning Model. It would further be obvious to include a method of effectively identifying a fault by utilizing a managing server to place all operational data into a hierarchical structure, matching the existing abnormal data with the received abnormal data, and determine if the abnormal data exceeds a predetermined threshold, as taught by Lee. This procedure, as taught by Lee, would allow for more effectively tracing faults, identifying thresholds and processing abnormal data in real time for the Machine Learning Model. Claim 21: Inagaki teaches the following limitations: The apparatus of claim 19, wherein the controller is further configured to determine a reason of the fault by tracing the program and the motion (Inagaki - [0039] The fault determination unit 31 determines a fault of the robot 2, using the known fault diagnosis method. The fault determination unit 31 determines whether a fault has occurred in the robot 2 or the degree of fault, independently of fault information generated by the fault prediction system 1. When, for example, a disturbance torque detected by a torque sensor or the amplitude of vibration of data output from a sensor exceeds a predetermined threshold, the fault determination unit 31 determines that a fault has occurred. Alternatively, the fault determination unit 31 may determine that a fault has occurred in the robot 2, based on internal data of control software stored in the robot controller 3. In this manner, the fault determination unit 31 determines faults based on various factors. The determination result obtained by the fault determination unit 31 is input to a determination data obtaining unit 51 of the machine learning device 5 (to be described later). ; [0051] In step S203, the learning unit 53 learns fault conditions in accordance with a training data set generated based on a combination of the state variable obtained in step S201 and the determination data obtained in step S202; [0066] A robot controller 3 can include a notifying unit (fault information notifying unit) 32, as depicted as FIG. 6. The notifying unit 32 notifies the operator of the fault information output from the fault information output unit 42. The mode in which the operator is notified of the fault information is not particularly limited as long as the fault information is identifiable to the operator. For example, information indicating whether a predicted fault has occurred or the degree of fault may be displayed on a display (not illustrated) or an alarm sound may be produced in accordance with the details of the fault information.) Inagaki does not explicitly teach the following limitations, however Ghose teaches: corresponding to the analysis ID. (Ghose – [0034] The DL analytics unit 250 of the system 200 can be configured to receive, a set of tasks in the form of time series from a plurality of robots, wherein the set of tasks includes a set of actuation data associated with each robot from the plurality of robots. Wherein, the set of actuation data includes a set of displacement data and a set of rotation data. . ; [0035] Further, the DL analytics unit 250 of the system 200 can be configured to compute a next activity associated with each robot based on a Deep Learning (DL) analytics, wherein the DL analytics is a RNN based LSTM, trained based on an optimal resource allocation technique to minimize computation cost and learning time, … ) Therefore, prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to modify Inagaki to include a method of processing actuation data, state variables and determination data sets so that a robot can more effectively identify a fault utilizing the stateful LSTM, data repository, training database and Deep Learning Analytics as taught in Ghose. This would enable a method of effectively tracing faults by providing time series information, data bases, and various processors for the purpose of storing, training, and processing normal and abnormal data in real time for the Machine Learning Model. Claim 22: Inagaki teaches the following limitations: The apparatus of claim 19, further comprising: a display configured to display the fault. (Inagaki - [0066] A robot controller 3 can include a notifying unit (fault information notifying unit) 32, as depicted as FIG. 6. The notifying unit 32 notifies the operator of the fault information output from the fault information output unit 42. The mode in which the operator is notified of the fault information is not particularly limited as long as the fault information is identifiable to the operator. For example, information indicating whether a predicted fault has occurred or the degree of fault may be displayed on a display (not illustrated) or an alarm sound may be produced in accordance with the details of the fault information.) Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure or directed to the state of the art is listed on the enclosed PTO-892. The following is a brief description for relevant prior art that was cited but not applied: Hosek (US 20140201571 A1) describes a system for condition monitoring and fault diagnosis which includes a data collection function that acquires time histories of selected variables for one or more of the components, a pre-processing function that calculates specified characteristics of the time histories, an analysis function for evaluating the characteristics to produce one or more hypotheses of a condition of the one or more components, and a reasoning function for determining the condition of the one or more components from the one or more hypotheses. Kuno (US 20180147735 A1) describes a failure diagnosis device applicable to a mechanical device provided with motors independent of One another as sources to drive motion axes, respectively, and configured to acquire a moving position of each motion axis and a disturbance torque value applied to the motion axis during a predetermined period to diagnose a failure of the mechanical device. The device includes a failure diagnosis unit configured to diagnose the motion axis as a failure when the disturbance torque value is larger than a predetermined failure determination threshold. Gawlik (US 20190143521 A1) describes a method for assessing the health of a device system by registering predetermined operating data of dynamic performance variables output by the device and determining a base value characterized by a probability density function of each dynamic performance variable output. Comparing base values for each of the dynamic performance variable output by the device respectively corresponding to the predetermined motion base set and the other predetermined motion sets. 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 extension fee 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 date of this final action. Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALAN LINDSAY OSTROW whose telephone number is (703)756-1854. The examiner can normally be reached M-F 8 - 5. 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, Adam Mott can be reached on (571) 270 5376. 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. /ALAN LINDSAY OSTROW/ Examiner, Art Unit 3657 /ADAM R MOTT/Supervisory Patent Examiner, Art Unit 3657
Read full office action

Prosecution Timeline

Jan 04, 2022
Application Filed
Feb 22, 2024
Non-Final Rejection — §103
May 28, 2024
Response Filed
Aug 05, 2024
Final Rejection — §103
Nov 08, 2024
Response after Non-Final Action
Nov 12, 2024
Response after Non-Final Action
Dec 04, 2024
Request for Continued Examination
Dec 05, 2024
Response after Non-Final Action
Jan 02, 2025
Non-Final Rejection — §103
Apr 07, 2025
Response Filed
May 02, 2025
Final Rejection — §103
Jun 30, 2025
Response after Non-Final Action
Aug 11, 2025
Request for Continued Examination
Aug 13, 2025
Response after Non-Final Action
Aug 21, 2025
Non-Final Rejection — §103
Nov 17, 2025
Response Filed
Dec 17, 2025
Final Rejection — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12583119
TRANSFER SYSTEM AND TRANSFER METHOD
2y 5m to grant Granted Mar 24, 2026
Patent 12576525
ROBOT SYSTEM
2y 5m to grant Granted Mar 17, 2026
Patent 12569989
ESTIMATION DEVICE, ESTIMATION METHOD, ESTIMATION PROGRAM, AND ROBOT SYSTEM
2y 5m to grant Granted Mar 10, 2026
Patent 12539611
ROBOT CONTROL APPARATUS, ROBOT CONTROL SYSTEM, AND ROBOT CONTROL METHOD
2y 5m to grant Granted Feb 03, 2026
Patent 12491627
INFORMATION PROCESSING APPARATUS AND COOKING SYSTEM
2y 5m to grant Granted Dec 09, 2025
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

7-8
Expected OA Rounds
74%
Grant Probability
99%
With Interview (+37.7%)
2y 7m
Median Time to Grant
High
PTA Risk
Based on 35 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month