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 .
Drawings
The drawings are objected to under 37 CFR 1.83(a). The drawings must show every feature of the invention specified in the claims. Therefore, the claimed method must be shown or the feature(s) canceled from the claim(s). The examiner suggests adding a flowchart with corresponding text and reference numbers to show the claimed method. No new matter should be entered.
Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
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.
Claim 14 is 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 14 recites “A manipulator control program for a robot system, the manipulator control program comprising action instructions executable by an operation controller to control a manipulator of the robot system to carry out an action instruction, the manipulator control program comprising constraint instructions from which a constraint to be observed while executing the action instruction is adapted to be extracted by a safety controller; wherein the manipulator control program further includes instructions for: a) reading the action instruction … b) reading at least one constraint instruction.” Particularly, the manipulator control program comprises action instructions and constraint instructions, and includes instructions for reading those action instructions and constraint instructions. The program having instructions for reading the instructions from the program is unclear and seems like unintentional wording by the applicant. According to the specification, action/constraint instructions are read from the manipulator control program (Abstract and [0004-0006]), however, there is no mention of the program further including instructions for reading the action/constraint instructions and it would be unclear to one of ordinary skill in the art how to interpret the program’s instructions to read instructions from the program. For examination purposes, claim 14 is interpreted such that steps a), b), and c) describe how the manipulator control program is executable.
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.
Claim 14 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because “a manipulator control program” is a computer program per se. Products that do not have a physical or tangible form, such as information (often referred to as "data per se") or a computer program per se (often referred to as "software per se") when claimed as a product without any structural recitations are not directed to any of the statutory categories (See MPEP 2106.03). As claimed, the control program comprises instructions executable by an operation controller to control a manipulator. However, the operation controller and manipulator are not positively claimed as a structural element of the claim.
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)(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) 1-4, 6-7, 9, 11, and 13-14 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Beck (US 20220184810 A1).
Regarding Claim 1,
Beck teaches
A method for implementing a safety configuration for a manipulator comprising an end effector, (“The present invention relates to a safety system for a robot arm where the safety system during operation of the robot arm is configured to monitor the robot arm and bring the robot arm into a safe state if the robot arm is brought into an unsafe mode of operation.” See at least [0001]; See at least [0033-0041] for the method.; “a robot arm comprising a plurality of robot joints connecting a robot base and a robot tool flange.” See at least [0007])
the method comprising: a) reading an action instruction from a manipulator control program, (“the robot process controller control the operation of the robot arm based on a combination of the basic control software and the process control software.” See at least [0039]; “the process control software, whether it is a set of parameters or a program enabling integration and control of a robot tool (including a sensor) attached to the robot arm, is developed external to the robot controller and when uploaded to a robot system memory associated with the robot process controller or robot safety controller it is accessible by these controllers and can thereby be used at least partly to control the robot arm and tool hereof.” See at least [0042]; “The robot controller 202 also referred to as robot process controller comprises a controller processer 220 and controller memory 221 and is configured to control the joint motors of the robot joints by providing motor control signals 223a, 223b, 223f to the joint motors.” See at least [0058]; Examiner Interpretation: The control software is equivalent to the manipulator control program.)
the instruction defining at least one of a path to be followed by the end effector, a target position to be reached by the end effector, a target pose to be assumed by the end effector and an action to be carried out by a tool wielded by the end effector; (“the basic operation of the robot arm 301 is controlled by means of basic control software. This means that a user can provide waypoints and move commands to the robot controller 302 (e.g. via the interface device 104) and then based on this input, the robot controller is able to, based on the basic control software, control the joints of the robot arm to move between the waypoints according to the provided instructions. Since the basic control software is developed to facilitate generic operation of the robot, it is not able e.g. to control a robot tool 315 connected to the robot tool flange 104. It can move such robot tool 315, but not operate it. Hence, if the robot tool 314 is a gripper, the gripping operation cannot be controlled by the basic control software. To be able to control such tool operation additional software is required and this additional software is in this document referred to as process control software. The process control software can be any addition to the basic control software from waypoint coordinates to complicated software programs including software to optimize e.g. precision of operation of the robot arm 301 performed according to the basic control software. The process control software can be developed at an external data processing unit 324 and then uploaded to the robot control system 334 comprising both the robot controller 202 and the safety system 325 for being executed together with the basic control software. Typically, the process control software is an additional software layer provided which is making use of functions available in the basic control software or as mentioned operations parameters such as waypoint coordinates or limits for the operation of the robot arm 301.” See at least [0066-0067])
b) reading at least one constraint instruction from the manipulator control program, the constraint instruction defining a constraint to be observed while carrying out an action instruction; (“the basic control software is associated with a set of safety limits each having normal values limiting operation of the robot arm when controlled by the robot process controller according to the basic control software, wherein the process control software is associated with at least one safety limit of the set of safety limits having a process value which is different from the normal value.” See at least [0010]; “when uploading process control software to the robot controller, the safety limits associated therewith is used in combination with the basic control software to control the robot arm.” See at least [0083])
and c) carrying out the action instruction read in a) while respecting the constraint defined in the at least one constraint instruction, (“the robot controller will do its best to obey the safety limits” See at least [0076]; “In step 4 S4, the robot arm is as indicated integrated and prepared to operate in its local environment and after the integration, it is able to be controlled according to a combination of the basic and process control software including normal and process value of several safety limits to perform a dedicated operation task. In step 5 S5, during operation of the robot arm, the robot controller establishes real-time values of operation parameters. The operation parameters can be provided directly from sensors of the robot arm or derived from sensor input.” See at least [0111-0112]; “The robot arm starts in normal mode having a process value that is higher than the normal value and therefore initially in the sequence illustrated on FIG. 4 the process controller controls the robot arm according to an active safety limit value 456a defined by the normal value.” See at least [0091])
or transferring the manipulator into a safety mode when violation of the at least one constraint is detected while carrying out the action instruction. (“If it actually violates one of the safety limits (because the protective stop failed or e.g. an external force moved the robot faster than expected) then the robot safety controller will bring the robot arm into violation stop mode.” See at least [0076])
Regarding Claim 2,
Beck further teaches
wherein the manipulator is part of a robot system further comprising an operation controller adapted to control the manipulator to carry out an action instruction, (“Robot process controller should be understood as the controller controlling the operation of the robot arm.” See at least [0011]; “a user can provide waypoints and move commands to the robot controller 302 (e.g. via the interface device 104) and then based on this input, the robot controller is able to, based on the basic control software, control the joints of the robot arm to move between the waypoints according to the provided instructions.” See at least [0066])
and a safety controller adapted to detect whether a constraint is respected or not, (“Robot safety controller should be understood as a controller monitoring the operation of the robot arm and if the value of a defined monitored operation parameters exceeds a defined threshold values such as a safety limit, the robot safety controller brings the robot arm in the violation stop mode.” See at least [0012])
and wherein step a) is carried out by the operation controller but not by the safety controller, (“The process control software could be developed directly by use of the robot controller 202 and hence stored on the controller memory 221. Alternatively, at least part of the process control software is developed external to the robot controller and then uploaded to the controller memory 221, from where it is accessible for the robot controller” See at least [0108], wherein the controller memory 221 is associated with the robot (operation) controller.; “the robot controller is able to, based on the basic control software, control the joints of the robot arm to move between the waypoints according to the provided instructions.” See at least [0066]; Examiner Interpretation: The safety controller does not carry out step a) because it is merely for enforcing safety limits (See at least [0012]).)
and step b) is carried out at least by the safety controller. (“the safety controller also has access to at least the safety limits. It should be mentioned that the robot safety controller also has access to the nonbinary limits for being able to bring the robot arm in safe mode if the process controller fails to do so.” See at least [0084])
Regarding Claim 3,
Beck further teaches
wherein instructions of the manipulator control program are grouped into functions, the functions comprising a main function and functions invoked directly by the main function or indirectly via one or more intermediate functions, (“the basic operation of the robot arm 301 is controlled by means of basic control software. This means that a user can provide waypoints and move commands to the robot controller 302 (e.g. via the interface device 104) and then based on this input, the robot controller is able to, based on the basic control software, control the joints of the robot arm to move between the waypoints according to the provided instructions. Since the basic control software is developed to facilitate generic operation of the robot, it is not able e.g. to control a robot tool 315 connected to the robot tool flange 104. It can move such robot tool 315, but not operate it. Hence, if the robot tool 314 is a gripper, the gripping operation cannot be controlled by the basic control software. To be able to control such tool operation additional software is required and this additional software is in this document referred to as process control software. The process control software can be any addition to the basic control software from waypoint coordinates to complicated software programs including software to optimize e.g. precision of operation of the robot arm 301 performed according to the basic control software. … the process control software is an additional software layer provided which is making use of functions available in the basic control software or as mentioned operations parameters such as waypoint coordinates or limits for the operation of the robot arm 301.” See at least [0066-0067]; Examiner Interpretation: The basic control software comprises the main functions and the process control software comprises the functions invoked by the main functions.)
wherein by default: a constraint instruction of an invoking function is valid during execution of a function invoked by it, and/or a constraint instruction of an invoked function becomes void when the invoked function terminates. (“the basic control software is associated with a set of safety limits each having normal values limiting operation of the robot arm when controlled by the robot process controller according to the basic control software, wherein the process control software is associated with at least one safety limit of the set of safety limits having a process value which is different from the normal value, wherein the process value of at least one safety limit is configured to be changed while the robot system is in run-time mode, and wherein the robot safety controller is configured to bring the robot arm into a violation stop mode if an evaluation of one or more operation parameter made results in a violation of the more restrictive of the normal value and the process value of the at least one safety limit.” See at least [0010]; “that during one operation cycle of the robot arm, a plurality of different process control software each having their own process values for the safety limits may run simultaneously and/or following each other. To illustrate this, table 1 below illustrates a several safety limits having different values for the basic control software and different process control software.” See at least [0105])
Regarding Claim 4,
Beck further teaches
wherein when the constraint instructions of an invoking function and of a function invoked by it are contradictive, a stricter one of the constraint instructions prevails. (“the basic control software is associated with a set of safety limits each having normal values limiting operation of the robot arm when controlled by the robot process controller according to the basic control software, wherein the process control software is associated with at least one safety limit of the set of safety limits having a process value which is different from the normal value, wherein the process value of at least one safety limit is configured to be changed while the robot system is in run-time mode, and wherein the robot safety controller is configured to bring the robot arm into a violation stop mode if an evaluation of one or more operation parameter made results in a violation of the more restrictive of the normal value and the process value of the at least one safety limit.” See at least [0010]; Also see at least [0086])
Regarding Claim 6,
Beck further teaches
wherein when the constraint instructions of an invoking function and of a function invoked by it are contradictive, the constraint instruction of the invoked function prevails. (“the basic control software is associated with a set of safety limits each having normal values limiting operation of the robot arm when controlled by the robot process controller according to the basic control software, wherein the process control software is associated with at least one safety limit of the set of safety limits having a process value which is different from the normal value, wherein the process value of at least one safety limit is configured to be changed while the robot system is in run-time mode, and wherein the robot safety controller is configured to bring the robot arm into a violation stop mode if an evaluation of one or more operation parameter made results in a violation of the more restrictive of the normal value and the process value of the at least one safety limit.” See at least [0010]; Also see at least [0086] and TABLE 1 (provided below); Examiner Interpretation: The safety limit of the process value from the process control software (invoked function) prevails when it is more restrictive as exemplified in TABLE 1, process value #1.)
PNG
media_image1.png
422
390
media_image1.png
Greyscale
Regarding Claim 7,
Beck further teaches
wherein the constraint instruction defines at least one of: an allowed operating region of the manipulator; an allowed maximum speed of the manipulator; an allowed maximum momentum of the manipulator; an allowed maximum force applied by the manipulator to an outside object; and a required minimum distance of the manipulator from an object within reach of the manipulator. (“Examples of a safety limits could be the robot joint speed which could be a value in an operation window starting at 0 and ending at 400 degrees/s, typically a maximum value (safety limit) between 15-360 degrees/s for wrist joints of and 15-120 degrees for base/shoulder/elbow joints; tool flange speed, which could be a value in an operation window starting at 0 and ending at 5 m/s, typically a maximum value (safety limit) between 1-2 m/s; power consumption of the robot arm which could be a value in an operation window starting at 10 w and ending at 1000 w; stopping time which could be a value in an operation window starting at ¼ s and ending at 1 s; stopping distance which could be a value in an operation window starting at 1 cm and ending at 2 m.” See at least [0016]; Also see at least [0072])
Regarding Claim 9,
Beck further teaches
wherein in c) the action instruction is carried out by physically moving the manipulator. (“by the robot process controller control the operation of the robot arm based on a combination of the basic control software and the process control software, during operation of the robot arm, establish a real-time value of at least one operation parameter, and by the robot safety controller, bring the robot arm into a violation stop mode if an evaluation of the real-time value of the at least one operation parameter violates the more restrictive of the normal value and the process value of the safety limit of the at least one operation parameter.” See at least [0039-0041])
Regarding Claim 11,
Beck further teaches
wherein in safety mode, a choice between at least two of the following options is made based on a setting defined before entering safety mode: stopping the manipulator; reducing an allowed maximum speed of the manipulator; reducing an allowed maximum momentum of the manipulator; resuming normal operation of the manipulator; and querying a supervisor’s decision whether to stop or to resume operation. (“When a person crosses the first virtual wall, the values of the safety limits are changed from normal to reduced normal values and when the person crosses the second virtual wall, the robot arm should stop. Hence, the process control software operates the robot arm according to normal values for the safety limits when the person is outside the first virtual wall. Between the first and the second virtual walls the robot arm is operated according to the most restrictive of the reduced normal value and a process value and when the user crosses the second virtual wall the process controller activates the emergency stop.” See at least [0069])
Regarding Claim 13,
Beck teaches
A robot system, comprising: a manipulator; (“The present invention relates to a safety system for a robot arm where the safety system during operation of the robot arm is configured to monitor the robot arm and bring the robot arm into a safe state if the robot arm is brought into an unsafe mode of operation.” See at least [0001]; “a robot arm comprising a plurality of robot joints connecting a robot base and a robot tool flange.” See at least [0007])
an operation controller adapted to control the manipulator to carry out an action instruction from a manipulator control program; (“Robot process controller should be understood as the controller controlling the operation of the robot arm.” See at least [0011]; “a user can provide waypoints and move commands to the robot controller 302 (e.g. via the interface device 104) and then based on this input, the robot controller is able to, based on the basic control software, control the joints of the robot arm to move between the waypoints according to the provided instructions.” See at least [0066])
and a safety controller adapted to detect whether a constraint is respected or not when carrying out the action instruction; (“Robot safety controller should be understood as a controller monitoring the operation of the robot arm and if the value of a defined monitored operation parameters exceeds a defined threshold values such as a safety limit, the robot safety controller brings the robot arm in the violation stop mode.” See at least [0012])
wherein the safety controller is adapted to extract the constraint from a constraint instruction of the manipulator control program. (“the safety controller also has access to at least the safety limits. It should be mentioned that the robot safety controller also has access to the nonbinary limits for being able to bring the robot arm in safe mode if the process controller fails to do so.” See at least [0084])
Regarding Claim 14,
Beck teaches
A manipulator control program for a robot system, the manipulator control program comprising action instructions executable by an operation controller to control a manipulator of the robot system to carry out an action instruction, the manipulator control program comprising constraint instructions from which a constraint to be observed while executing the action instruction is adapted to be extracted by a safety controller; (“basic control software is associated with a set of safety limits each having normal values limiting operation of the robot arm when controlled by the robot process controller according to the basic control software, wherein the process control software is associated with at least one safety limit of the set of safety limits having a process value which is different from the normal value … the safety limits can be changed and evaluated while the robot process and robot safety controllers are in run-time mode i.e. during operation of the robot arm.” See at least [0010]; “Basic control software should be understood as software which is used by the process controller to control movement of the robot arm i.e. of the individual joints and thereby of the robot flange and any robot tool attached thereto. The basic control software is typically developed based on a mathematical model of the robot arm and is delivered together with the robot arm. … Process control software can be simple coordinates in a three-dimensional Cartesian coordinate system defining waypoints for movement of the robot arm, program code defining the operation of a robot tool attached to the robot flange, advanced math for determine points in the Cartesian coordinate system, optimize precision e.g. in movements, sensors systems, etc. Hence, the process controller controls the movement of the robot arm and tool based on a combination of process and basic control software, where the process control software provides process values to at least one safety limit defined by the basic control software.” See at least [0013-0014])
wherein the manipulator control program further includes instructions for: a) reading the action instruction, (“the robot process controller control the operation of the robot arm based on a combination of the basic control software and the process control software.” See at least [0039]; “the process control software, whether it is a set of parameters or a program enabling integration and control of a robot tool (including a sensor) attached to the robot arm, is developed external to the robot controller and when uploaded to a robot system memory associated with the robot process controller or robot safety controller it is accessible by these controllers and can thereby be used at least partly to control the robot arm and tool hereof.” See at least [0042]; “The robot controller 202 also referred to as robot process controller comprises a controller processer 220 and controller memory 221 and is configured to control the joint motors of the robot joints by providing motor control signals 223a, 223b, 223f to the joint motors.” See at least [0058]; Examiner Interpretation: The control software is equivalent to the manipulator control program.)
the instruction defining at least one of a path to be followed by an end effector, a target position to be reached by the end effector, a target pose to be assumed by the end effector and an action to be carried out by a tool wielded by the end effector; (“the basic operation of the robot arm 301 is controlled by means of basic control software. This means that a user can provide waypoints and move commands to the robot controller 302 (e.g. via the interface device 104) and then based on this input, the robot controller is able to, based on the basic control software, control the joints of the robot arm to move between the waypoints according to the provided instructions. Since the basic control software is developed to facilitate generic operation of the robot, it is not able e.g. to control a robot tool 315 connected to the robot tool flange 104. It can move such robot tool 315, but not operate it. Hence, if the robot tool 314 is a gripper, the gripping operation cannot be controlled by the basic control software. To be able to control such tool operation additional software is required and this additional software is in this document referred to as process control software. The process control software can be any addition to the basic control software from waypoint coordinates to complicated software programs including software to optimize e.g. precision of operation of the robot arm 301 performed according to the basic control software. The process control software can be developed at an external data processing unit 324 and then uploaded to the robot control system 334 comprising both the robot controller 202 and the safety system 325 for being executed together with the basic control software. Typically, the process control software is an additional software layer provided which is making use of functions available in the basic control software or as mentioned operations parameters such as waypoint coordinates or limits for the operation of the robot arm 301.” See at least [0066-0067])
b) reading at least one constraint instruction, the constraint instruction defining a constraint to be observed while carrying out an action instruction; (“the basic control software is associated with a set of safety limits each having normal values limiting operation of the robot arm when controlled by the robot process controller according to the basic control software, wherein the process control software is associated with at least one safety limit of the set of safety limits having a process value which is different from the normal value.” See at least [0010]; “when uploading process control software to the robot controller, the safety limits associated therewith is used in combination with the basic control software to control the robot arm.” See at least [0083])
and c) carrying out the action instruction read in a) while respecting the constraint defined in the at least one constraint instruction, (“the robot controller will do its best to obey the safety limits” See at least [0076]; “In step 4 S4, the robot arm is as indicated integrated and prepared to operate in its local environment and after the integration, it is able to be controlled according to a combination of the basic and process control software including normal and process value of several safety limits to perform a dedicated operation task. In step 5 S5, during operation of the robot arm, the robot controller establishes real-time values of operation parameters. The operation parameters can be provided directly from sensors of the robot arm or derived from sensor input.” See at least [0111-0112]; “The robot arm starts in normal mode having a process value that is higher than the normal value and therefore initially in the sequence illustrated on FIG. 4 the process controller controls the robot arm according to an active safety limit value 456a defined by the normal value.” See at least [0091])
or transferring the manipulator into a safety mode if violation of the at least one constraint is detected while carrying out the action instruction. (“If it actually violates one of the safety limits (because the protective stop failed or e.g. an external force moved the robot faster than expected) then the robot safety controller will bring the robot arm into violation stop mode.” See at least [0076])
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.
The factual inquiries 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.
Claim(s) 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Beck (US 20220184810 A1) in view of Nishitani (US 20170274532 A1).
Regarding Claim 8,
Beck does not explicitly teach, but Nishitani teaches
wherein in c) the action instruction is carried out by simulation. (“A simulation device according to an aspect of the invention is a simulation device that performs a simulation of operation of a virtual robot on a virtual space. In the simulation, a first region and a second region located on an inside of the first region can be set on the virtual space. In the case where the virtual robot operates, when a specific portion of the virtual robot intrudes into the first region, operating speed of the virtual robot is limited. When the specific portion of the virtual robot intrudes into the second region, the operation of the virtual robot stops or the virtual robot retracts from the second region.” See at least [0040])
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the teachings of Beck to further include the teachings of Nishitani with a reasonable expectation of success to improve safety and performance of the actual robot by first verifying operation of the robot in a simulation. (See at least [0233])
Claim(s) 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Beck (US 20220184810 A1) in view of Arora (US 20210178595 A1).
Regarding Claim 10,
Beck does not explicitly teach, but Arora teaches
wherein after entry into safety mode, details of the violation are recorded. (“The robot further comprises an alarm module configured to take action upon receipt of a trigger notifying the alarm module that the critical condition has occurred. If the critical condition detector detects a critical condition, the robot triggers the alarm module. Upon receiving the trigger, the alarm module performs one or more of sending a stop command to the server stream, sending an error code to the robots, and streaming to the cloud the data describing the critical condition. The stop command orders the server to stop the critical condition. The error code corresponds to the critical condition.” See at least [0019]; “the robot 110 again uses a server stream module (not shown) to upload the data 140 to the cloud 120. The streamed data, presented to a user (not shown) through the UI (not shown), enables the user (not shown) to detect and investigate problems. The robot 110 further comprises a data recording module 180 configured to record the data 140.” See at least [0071])
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the teachings of Beck to further include the teachings of Arora with a reasonable expectation of success to facilitate “monitoring and reporting to improve safety.” (See at least [0002])
Claim(s) 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Beck (US 20220184810 A1) in view of Monacelli (IDS: “Programming assistance over distributed systems: MAPES”).
Regarding Claim 12,
Beck does not explicitly teach, but Monacelli teaches
further comprising d) reading from the manipulator control program an instruction specifying code to be executed in case of a violation, and e) entering safety mode by executing the specified code. (“The IAda sub-system is a robotics. task manager language developed for distributed applications: … It performs executing constraints required by robotics: distributed application, real-time execution and executing control. IAda is an interpreter build around IAda compiled primitives, which are elementary actions of the robot, and also a set of basic instructions to manipulate, activate or deactivate those primitives. … Moreover. in order to build robust applications. IAda has constraint schemes included directly on the main program design. It allows to express properties during the execution of the program. As soon as those properties are transgressed, a sequence of IAda orders is activate concurrently to the main execution with a high priority. In the above example, a condition could survey interactions between robots:
PNG
media_image2.png
92
282
media_image2.png
Greyscale
Where Distance is a function able to detect a close proximity of the robots: the treatment could be first for instance, the stop before a readjustment of the respectively trajectories.” See at least pgs. 631-632, B. IAda)
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the teachings of Beck to further include the teachings of Monacelli with a reasonable expectation of success to facilitate managing robot tasks and ensures global coherency and flexibility. (See at least pg. 630, I. INTRODUCTION, A. The system MAPES/IAda)
Allowable Subject Matter
Claim 5 is 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.
The relevant prior art does not disclose the method wherein when a constraint instruction of an invoking function is stricter than a constraint instruction of function invoked by it, a notice is output.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Beardsworth (US 20220395979 A1) is pertinent because it discusses a method including obtaining a definition of the motion plan, obtaining data specifying a safety footprint volume for a first robot in the operating environment, obtaining one or more safety constraints for the motion plan according to the safety footprint volume for the first robot, determining whether a first safety constraint of the one or more safety constraints is satisfied, in response to determining that the first safety constraint is not satisfied, generating information indicating a violation of a safety constraint..
Hoshiyama (US 20190030721 A1) is pertinent because it discusses a controller that reads a safety stop program and monitoring force of the robot and when the force exceeds a predetermined reference range, the controller executes a safety stop function.
Naitou (US 20230211496 A1) is pertinent because it discusses reading threshold values to be set as safety thresholds to stop the robot.
The above mentioned art, evaluated separately and in combination, does not disclose the entirety of limitations of the dependent claim 5 since they do not describe the method wherein when a constraint instruction of an invoking function is stricter than a constraint instruction of function invoked by it, a notice is output. No prior art has been found at the time of writing this office action to reject the pending claim 5 under 35 U.S.C. 102 or 103.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Karston G Evans whose telephone number is (571)272-8480. The examiner can normally be reached Mon-Fri 9:00-5:00.
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, Abby Lin can be reached at (571)270-3976. 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.
/KARSTON G. EVANS/Examiner, Art Unit 3657