DETAILED ACTION
Claims 1-14 are presented for examination. This office action is response to the submission on 11/15/2023.
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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 11/15/2023 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Drawings
The drawings filed on 11/15/2023 are acceptable for examination proceedings.
Specification
The disclosure is objected to because of the following informalities:
Page 13 lines 20-21 read “deduce new information. The” Examiner believes this should read “deduce new information. [[The]]” (Typo).
Page 13 lines 23-24 read “The control apparatus 20 comprises a control processing unit 27” Examiner believes this should read “The control apparatus 20 comprises a control processing unit [[27]] 25” (Typo).
Appropriate correction is required.
Claim Objections
Claims 3, 5, and 6 are objected to because of the following informalities:
Claim 3 reads “The computer-implemented method according to claim 2, wherein the control programming language is structured according to a finite state machine, a workflow diagram or a behavior tree.” (Emphasis added) There is a lack of antecedent basis for “the control programming language”.
Claim 5 lines 1-3 reads “The computer-implemented method according to claim 4, wherein transferring data between the data processing unit and the control processing unit only indirectly via a data storage unit.” Examiner believes this should read “The computer-implemented method according to claim 4, wherein transferring data between the data processing unit and the control processing unit occurs only indirectly via a data storage unit.” For the sake of clarity.
Claim 6 lines 1-2 reads “The computer-implemented method according to claim 5, wherein input data from the machine received only in the data storage unit.” Examiner believes this should read “The computer-implemented method according to claim 5, wherein input data from the machine is received only in the data storage unit.” For the sake of clarity.
Appropriate correction is required.
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.
Claims 1-2, 4, 7-8, 11, and 14 are rejected under 35 U.S.C. 103 as being unpatentable over FICHERA LORIS ET AL: "A Python framework for programming autonomous robots using a declarative approach", SCIENCE OF COMPUTER PROGRAMMING, vol. 139, 1 June 2017 (2017-06-01), pages 36-55) (hereinafter referred to as “Fichera”), in view of ADAM SORIN ET AL: "Towards Rule-Based Dynamic Safety Monitoring for Mobile Robots", 20 October 2014 (2014-10-20), SAT 2015 18TH INTERNATIONAL CONFERENCE, AUSTIN, TX, USA, SEPTEMBER 24-27, 2015; [LECTURE NOTES IN COMPUTER SCIENCE; LECT.NOTES COMPUTER], SPRINGER, BERLIN, HEIDELBERG, PAGE(S) 207 (hereinafter referred to as “Larsen”).
Claim 1:
Fichera teaches “A computer-implemented method for controlling a machine by executing program steps which verifiably execute predefined control tasks,” (Fichera teaches that the control system described involves beliefs, goals, and intentions and that a plan becomes an intention after selecting the most appropriate plan i.e. it executes predefined control tasks in Fichera [Pages 37-38, Section 2] "This section presents a brief overview of the Belief–Desire–Intention (BDI) model, which constitutes the foundation of PROFETA. For an exhaustive description of the BDI model, the reader is referred to [15], [14].The BDI paradigm is derived from a philosophical theory of human practical reasoning, and assumes that the mental state of an intelligent system (an agent or robot2) consists of three fundamental attitudes: Beliefs, Desires and Intentions.Beliefs represent the informational state of the agent, which includes the information about its own internal state and the knowledge about the external world. An agent's beliefs are subject to changes due to the data received through sensors, which monitor the external world, and as a result of a reasoning process, which is capable of inferring new knowledge. Beliefs are stored in a knowledge base, which can be queried to check if a specific information is known to the robot, or to determine if the robot/environment is in a certain state.Desires, or more commonly Goals, represent the motivational state of the robot, i.e. a set of objectives it wants to achieve; for instance, picking an object, avoiding an obstacle, searching for an item, reaching a certain position, etc. In practice, in order to achieve its objectives as it operates in its environment, a robot can be endowed with several plans specifying the sequence of actions to be carried out. A plan becomes an Intention after a deliberation process that entails the selection of the “most appropriate plan” to achieve a given goal.A plan representing a goal is selected only if it is consistent with the current set of beliefs of the agent. Thus, the knowledge possessed by the agent becomes a precondition in determining the proper goal to be achieved. The execution of a plan may cause the knowledge base to be updated, due to either an explicit revision of current beliefs, or modifications of the environment state detected through the sensors. The new state of the knowledge base can, in turn, trigger the achievement of a new goal, thus making the reasoning process proceed."; Fichera teaches controlling a robot in Fichera [Page 40, Section 4.2, third paragraph] "Beside goals and beliefs, the basic building blocks of PROFETA code are actions, i.e., operations that are executed atomically to make the robot “do something” by controlling its actuators. Examples of actions include driving an arm to pick an object, or moving the robot to a new position. Actions have the same syntax of goals and beliefs; thus, expressions like move to(100,200), move to("X","Y") or go home() are all valid action representations."),
“comprising: manipulating data based on input data received from the machine and resulting in reference data by data programming steps structured according to a declarative programming paradigm in a data processing unit;” (Fichera teaches that data received through sensors i.e. input data received from the machine may result in a change in beliefs in Fichera [Page 37, Section 2, third paragraph] "Beliefs represent the informational state of the agent, which includes the information about its own internal state and the knowledge about the external world. An agent's beliefs are subject to changes due to the data received through sensors, which monitor the external world, and as a result of a reasoning process, which is capable of inferring new knowledge. Beliefs are stored in a knowledge base, which can be queried to check if a specific information is known to the robot, or to determine if the robot/environment is in a certain state."; Fichera teaches that PROFETA, the framework described, allows use of declarative constructs in Fichera [Page 37, fourth paragraph] "In this work, we tackle the noted issues, proposing as a solution a novel, unified programming environment that smoothly and elegantly integrates imperative and declarative constructs, thereby enabling developers to rapidly create and combine the different parts of a robotic software architecture. Specifically, we propose a framework, called PROFETA (Python Robotic Framework for designing strategies), which builds on the Python programming language and extends it to implement the operational semantics required to define and run BDI agents. PROFETA runs on the Python virtual machine, and extends Python with a set of declarative constructs inspired by AgentSpeak(L), a well-known BDI kernel language [14], [15]. Such constructs were defined through Python's operator overloading, and enable the description of a robot's behavior, while Python's object-oriented/imperative constructs can be used for the implementation of middle and low-level tasks. This paper describes the current state of development of PROFETA, presenting its basics, syntax and architecture, and including a case-study illustrating how to design and develop a robotic application within PROFETA."),
“performing control program steps verifying the reference data with respect to explicit conditions in a control processing unit;” (Fichera teaches context conditions that require a belief be present in the knowledge base in order to execute a plan i.e. verifying the reference data with respect to explicit conditions in Fichera [Page 39, Section 4.1 paragraphs 1-4] "Like other implementations of the BDI paradigm (cf. Section 2), PROFETA involves the following basic entities: beliefs, goals and plans. In particular, PROFETA supports two kinds of plans: Goal Plans, describing the necessary steps to achieve a certain goal; and Reactive Plans, which are executed upon the occurrence of a certain event, e.g. a change in the knowledge base or failure of another plan. A plan is composed of three basic parts:The Head, which for goal plans consists of the goal name and a list of parameters; for reactive plans, this is the specification of the triggering event.The Context Condition (or simply the Context), i.e. a first-order logic predicate specifying the beliefs that must be present in the knowledge base in order to allow the execution of the plan; if the condition is false, the plan cannot be selected for execution.The Body, i.e. the code of the plan, containing a list of actions which are executed in sequence; actions may include changes to the knowledge base, requests to achieve a goal, or specific actions to be performed onto the environment."),
“and providing instructions resulting from the performed control program steps to the machine for execution of the instructions by the machine;” (Fichera teaches providing the code of the plan which is a list of actions to be executed in sequence e.g. to the robot in Fichera [Page 39, Section 4.1 paragraphs 1-4] "Like other implementations of the BDI paradigm (cf. Section 2), PROFETA involves the following basic entities: beliefs, goals and plans. In particular, PROFETA supports two kinds of plans: Goal Plans, describing the necessary steps to achieve a certain goal; and Reactive Plans, which are executed upon the occurrence of a certain event, e.g. a change in the knowledge base or failure of another plan. A plan is composed of three basic parts:The Head, which for goal plans consists of the goal name and a list of parameters; for reactive plans, this is the specification of the triggering event.The Context Condition (or simply the Context), i.e. a first-order logic predicate specifying the beliefs that must be present in the knowledge base in order to allow the execution of the plan; if the condition is false, the plan cannot be selected for execution.The Body, i.e. the code of the plan, containing a list of actions which are executed in sequence; actions may include changes to the knowledge base, requests to achieve a goal, or specific actions to be performed onto the environment."),
“wherein conditions are explicitly stated rules applied to reference data,” (Fichera teaches context conditions that require a belief be present in the knowledge base in order to execute a plan i.e. they are explicitly stated rules applied to the reference data in Fichera [Page 39, Section 4.1 paragraphs 1-4] "Like other implementations of the BDI paradigm (cf. Section 2), PROFETA involves the following basic entities: beliefs, goals and plans. In particular, PROFETA supports two kinds of plans: Goal Plans, describing the necessary steps to achieve a certain goal; and Reactive Plans, which are executed upon the occurrence of a certain event, e.g. a change in the knowledge base or failure of another plan. A plan is composed of three basic parts:The Head, which for goal plans consists of the goal name and a list of parameters; for reactive plans, this is the specification of the triggering event.The Context Condition (or simply the Context), i.e. a first-order logic predicate specifying the beliefs that must be present in the knowledge base in order to allow the execution of the plan; if the condition is false, the plan cannot be selected for execution.The Body, i.e. the code of the plan, containing a list of actions which are executed in sequence; actions may include changes to the knowledge base, requests to achieve a goal, or specific actions to be performed onto the environment."), and
“and any violation of the rule results in a specified action.” (Fichera teaches context conditions that require a belief be present in the knowledge base in order to execute a plan i.e a violation in a rule results in the plan not being eligible for execution, meaning the violation will cause a different plan to be executed in Fichera [Page 39, Section 4.1 paragraphs 1-4] "Like other implementations of the BDI paradigm (cf. Section 2), PROFETA involves the following basic entities: beliefs, goals and plans. In particular, PROFETA supports two kinds of plans: Goal Plans, describing the necessary steps to achieve a certain goal; and Reactive Plans, which are executed upon the occurrence of a certain event, e.g. a change in the knowledge base or failure of another plan. A plan is composed of three basic parts:The Head, which for goal plans consists of the goal name and a list of parameters; for reactive plans, this is the specification of the triggering event.The Context Condition (or simply the Context), i.e. a first-order logic predicate specifying the beliefs that must be present in the knowledge base in order to allow the execution of the plan; if the condition is false, the plan cannot be selected for execution.The Body, i.e. the code of the plan, containing a list of actions which are executed in sequence; actions may include changes to the knowledge base, requests to achieve a goal, or specific actions to be performed onto the environment.").
Fichera does not appear to explicitly teach “the rule is continuously monitored by the control processing unit” However, Larsen does teach this claim limitation (teaches implementing a loop in order to monitor a rule i.e. the rule is continuously monitored in Larsen [Page 213, paragraph 2] "In order to ease the code generation, a Python library implementing classes for representing rules, entities, topic and node monitoring has been developed. A rule object stores the result of each rule evaluation in a timestamped buffer, making the result of the rule accessible for a given time interval. The topic monitoring class also stores the received ROS messages in a timestamped buffer. Each of the classes implement a loop method allowing the rule to be evaluated, and in the case of a topic, the average frequency to be calculated. The loop method is called on each object at a specific interval, currently 0.1 seconds (10 Hz), but can be set as high as the computer performance allows.").
Fichera and Larsen are analogous art because they are from the same field of endeavor of robot control. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having teachings of Fichera and Larsen before him/her, to modify the teachings of an A Python framework for programming autonomous robots using a declarative approach of Fichera to include the monitoring of a rule in a loop of Larsen because adding the Rule-Based Dynamic Safety Monitoring for Mobile Robots of Larsen would ease code generation and allow for a specified loop frequency, increasing functionality as described in Larsen [Page 213, paragraph 2] "In order to ease the code generation, a Python library implementing classes for representing rules, entities, topic and node monitoring has been developed. A rule object stores the result of each rule evaluation in a timestamped buffer, making the result of the rule accessible for a given time interval. The topic monitoring class also stores the received ROS messages in a timestamped buffer. Each of the classes implement a loop method allowing the rule to be evaluated, and in the case of a topic, the average frequency to be calculated. The loop method is called on each object at a specific interval, currently 0.1 seconds (10 Hz), but can be set as high as the computer performance allows.")."
Claim 2:
Fichera in view of Larsen teaches “The computer-implemented method according to claim 1, wherein control program steps are performed by a control programming paradigm without comprising any data manipulation functionality.” (Fichera teaches goal plans which describe the steps to achieve a goal i.e. they may be executed without data manipulation in Fichera [Page 39, Section 4.1 paragraphs 1-4] "Like other implementations of the BDI paradigm (cf. Section 2), PROFETA involves the following basic entities: beliefs, goals and plans. In particular, PROFETA supports two kinds of plans: Goal Plans, describing the necessary steps to achieve a certain goal; and Reactive Plans, which are executed upon the occurrence of a certain event, e.g. a change in the knowledge base or failure of another plan. A plan is composed of three basic parts:The Head, which for goal plans consists of the goal name and a list of parameters; for reactive plans, this is the specification of the triggering event.The Context Condition (or simply the Context), i.e. a first-order logic predicate specifying the beliefs that must be present in the knowledge base in order to allow the execution of the plan; if the condition is false, the plan cannot be selected for execution.The Body, i.e. the code of the plan, containing a list of actions which are executed in sequence; actions may include changes to the knowledge base, requests to achieve a goal, or specific actions to be performed onto the environment.").
Claim 4:
Fichera in view of Larsen teaches “The computer-implemented method according to claim 1, wherein the reference data is re-processed based on updated input data received in the data processing unit from the machine according to reactive programming steps and the re-processed reference data is provided from the data processing unit to the control processing unit.” (Fichera teaches that the control system described that a new state of the knowledge base caused by modification of the environment state detected through sensors can trigger achievement of a new goal, making a reasoning process proceed i.e. the data is re-processed based on updated data in Fichera [Page 38, First paragraph] "A plan representing a goal is selected only if it is consistent with the current set of beliefs of the agent. Thus, the knowledge possessed by the agent becomes a precondition in determining the proper goal to be achieved. The execution of a plan may cause the knowledge base to be updated, due to either an explicit revision of current beliefs, or modifications of the environment state detected through the sensors. The new state of the knowledge base can, in turn, trigger the achievement of a new goal, thus making the reasoning process proceed.").
Claim 7:
Fichera in view of Larsen teaches “The computer-implemented method according to claim 1, wherein data program steps are structured according to logical programming.” (Fichera teaches that the syntax of PROFETA is a logical-declarative paradigm i.e. logical programming in Fichera [Page 40, Section 4.2 paragraph 1] "The syntax of PROFETA is illustrated in Fig. 1. The language implements a logical-declarative paradigm, and its semantics is defined through the operator overloading mechanism of Python [67], [68]. PROFETA code is therefore made up of valid Python instructions that are ultimately processed by the PROFETA reasoning engine. As an example, the expression +my_position(0,0) causes the addition of a belief (my_position) to the knowledge base; the operator + was overloaded to produce such a behavior. These aspects will be covered in greater detail in the next section.").
Claim 8:
Fichera teaches “A control apparatus for controlling a machine by executing program steps which verifiably execute predefined control tasks comprising:” (Fichera teaches that the control system described involves beliefs, goals, and intentions and that a plan becomes an intention after selecting the most appropriate plan i.e. it executes predefined control tasks in Fichera [Pages 37-38, Section 2] "This section presents a brief overview of the Belief–Desire–Intention (BDI) model, which constitutes the foundation of PROFETA. For an exhaustive description of the BDI model, the reader is referred to [15], [14].The BDI paradigm is derived from a philosophical theory of human practical reasoning, and assumes that the mental state of an intelligent system (an agent or robot2) consists of three fundamental attitudes: Beliefs, Desires and Intentions.Beliefs represent the informational state of the agent, which includes the information about its own internal state and the knowledge about the external world. An agent's beliefs are subject to changes due to the data received through sensors, which monitor the external world, and as a result of a reasoning process, which is capable of inferring new knowledge. Beliefs are stored in a knowledge base, which can be queried to check if a specific information is known to the robot, or to determine if the robot/environment is in a certain state.Desires, or more commonly Goals, represent the motivational state of the robot, i.e. a set of objectives it wants to achieve; for instance, picking an object, avoiding an obstacle, searching for an item, reaching a certain position, etc. In practice, in order to achieve its objectives as it operates in its environment, a robot can be endowed with several plans specifying the sequence of actions to be carried out. A plan becomes an Intention after a deliberation process that entails the selection of the “most appropriate plan” to achieve a given goal.A plan representing a goal is selected only if it is consistent with the current set of beliefs of the agent. Thus, the knowledge possessed by the agent becomes a precondition in determining the proper goal to be achieved. The execution of a plan may cause the knowledge base to be updated, due to either an explicit revision of current beliefs, or modifications of the environment state detected through the sensors. The new state of the knowledge base can, in turn, trigger the achievement of a new goal, thus making the reasoning process proceed."; Fichera teaches controlling a robot in Fichera [Page 40, Section 4.2, third paragraph] "Beside goals and beliefs, the basic building blocks of PROFETA code are actions, i.e., operations that are executed atomically to make the robot “do something” by controlling its actuators. Examples of actions include driving an arm to pick an object, or moving the robot to a new position. Actions have the same syntax of goals and beliefs; thus, expressions like move to(100,200), move to("X","Y") or go home() are all valid action representations."),
“a data processing unit configured to manipulate data based on input data received from the machine and resulting in reference data by data program steps structured according to a declarative programming paradigm;” (Fichera teaches that data received through sensors i.e. input data received from the machine may result in a change in beliefs in Fichera [Page 37, Section 2, third paragraph] "Beliefs represent the informational state of the agent, which includes the information about its own internal state and the knowledge about the external world. An agent's beliefs are subject to changes due to the data received through sensors, which monitor the external world, and as a result of a reasoning process, which is capable of inferring new knowledge. Beliefs are stored in a knowledge base, which can be queried to check if a specific information is known to the robot, or to determine if the robot/environment is in a certain state."; Fichera teaches that PROFETA, the framework described, allows use of declarative constructs in Fichera [Page 37, fourth paragraph] "In this work, we tackle the noted issues, proposing as a solution a novel, unified programming environment that smoothly and elegantly integrates imperative and declarative constructs, thereby enabling developers to rapidly create and combine the different parts of a robotic software architecture. Specifically, we propose a framework, called PROFETA (Python Robotic Framework for designing strategies), which builds on the Python programming language and extends it to implement the operational semantics required to define and run BDI agents. PROFETA runs on the Python virtual machine, and extends Python with a set of declarative constructs inspired by AgentSpeak(L), a well-known BDI kernel language [14], [15]. Such constructs were defined through Python's operator overloading, and enable the description of a robot's behavior, while Python's object-oriented/imperative constructs can be used for the implementation of middle and low-level tasks. This paper describes the current state of development of PROFETA, presenting its basics, syntax and architecture, and including a case-study illustrating how to design and develop a robotic application within PROFETA."),
“and a control processing unit configured to perform control program steps verifying the reference data with respect to explicit conditions” (Fichera teaches context conditions that require a belief be present in the knowledge base in order to execute a plan i.e. verifying the reference data with respect to explicit conditions in Fichera [Page 39, Section 4.1 paragraphs 1-4] "Like other implementations of the BDI paradigm (cf. Section 2), PROFETA involves the following basic entities: beliefs, goals and plans. In particular, PROFETA supports two kinds of plans: Goal Plans, describing the necessary steps to achieve a certain goal; and Reactive Plans, which are executed upon the occurrence of a certain event, e.g. a change in the knowledge base or failure of another plan. A plan is composed of three basic parts:The Head, which for goal plans consists of the goal name and a list of parameters; for reactive plans, this is the specification of the triggering event.The Context Condition (or simply the Context), i.e. a first-order logic predicate specifying the beliefs that must be present in the knowledge base in order to allow the execution of the plan; if the condition is false, the plan cannot be selected for execution.The Body, i.e. the code of the plan, containing a list of actions which are executed in sequence; actions may include changes to the knowledge base, requests to achieve a goal, or specific actions to be performed onto the environment."),
“and providing instructions resulting from the performed control program steps to the machine for execution of instructions by the machine,” (Fichera teaches providing the code of the plan which is a list of actions to be executed in sequence e.g. to the robot in Fichera [Page 39, Section 4.1 paragraphs 1-4] "Like other implementations of the BDI paradigm (cf. Section 2), PROFETA involves the following basic entities: beliefs, goals and plans. In particular, PROFETA supports two kinds of plans: Goal Plans, describing the necessary steps to achieve a certain goal; and Reactive Plans, which are executed upon the occurrence of a certain event, e.g. a change in the knowledge base or failure of another plan. A plan is composed of three basic parts:The Head, which for goal plans consists of the goal name and a list of parameters; for reactive plans, this is the specification of the triggering event.The Context Condition (or simply the Context), i.e. a first-order logic predicate specifying the beliefs that must be present in the knowledge base in order to allow the execution of the plan; if the condition is false, the plan cannot be selected for execution.The Body, i.e. the code of the plan, containing a list of actions which are executed in sequence; actions may include changes to the knowledge base, requests to achieve a goal, or specific actions to be performed onto the environment."),
“wherein conditions are explicitly stated rules applied to reference data,” (Fichera teaches context conditions that require a belief be present in the knowledge base in order to execute a plan i.e. they are explicitly stated rules applied to the reference data in Fichera [Page 39, Section 4.1 paragraphs 1-4] "Like other implementations of the BDI paradigm (cf. Section 2), PROFETA involves the following basic entities: beliefs, goals and plans. In particular, PROFETA supports two kinds of plans: Goal Plans, describing the necessary steps to achieve a certain goal; and Reactive Plans, which are executed upon the occurrence of a certain event, e.g. a change in the knowledge base or failure of another plan. A plan is composed of three basic parts:The Head, which for goal plans consists of the goal name and a list of parameters; for reactive plans, this is the specification of the triggering event.The Context Condition (or simply the Context), i.e. a first-order logic predicate specifying the beliefs that must be present in the knowledge base in order to allow the execution of the plan; if the condition is false, the plan cannot be selected for execution.The Body, i.e. the code of the plan, containing a list of actions which are executed in sequence; actions may include changes to the knowledge base, requests to achieve a goal, or specific actions to be performed onto the environment."), and
“and any violation of the rule results in a specified action.” (Fichera teaches context conditions that require a belief be present in the knowledge base in order to execute a plan i.e a violation in a rule results in the plan not being eligible for execution, meaning the violation will cause a different plan to be executed in Fichera [Page 39, Section 4.1 paragraphs 1-4] "Like other implementations of the BDI paradigm (cf. Section 2), PROFETA involves the following basic entities: beliefs, goals and plans. In particular, PROFETA supports two kinds of plans: Goal Plans, describing the necessary steps to achieve a certain goal; and Reactive Plans, which are executed upon the occurrence of a certain event, e.g. a change in the knowledge base or failure of another plan. A plan is composed of three basic parts:The Head, which for goal plans consists of the goal name and a list of parameters; for reactive plans, this is the specification of the triggering event.The Context Condition (or simply the Context), i.e. a first-order logic predicate specifying the beliefs that must be present in the knowledge base in order to allow the execution of the plan; if the condition is false, the plan cannot be selected for execution.The Body, i.e. the code of the plan, containing a list of actions which are executed in sequence; actions may include changes to the knowledge base, requests to achieve a goal, or specific actions to be performed onto the environment.").
Fichera does not appear to explicitly teach “the rule is continuously monitored by the control processing unit” However, Larsen does teach this claim limitation (teaches implementing a loop in order to monitor a rule i.e. the rule is continuously monitored in Larsen [Page 213, paragraph 2] "In order to ease the code generation, a Python library implementing classes for representing rules, entities, topic and node monitoring has been developed. A rule object stores the result of each rule evaluation in a timestamped buffer, making the result of the rule accessible for a given time interval. The topic monitoring class also stores the received ROS messages in a timestamped buffer. Each of the classes implement a loop method allowing the rule to be evaluated, and in the case of a topic, the average frequency to be calculated. The loop method is called on each object at a specific interval, currently 0.1 seconds (10 Hz), but can be set as high as the computer performance allows.").
Fichera and Larsen are analogous art because they are from the same field of endeavor of robot control. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having teachings of Fichera and Larsen before him/her, to modify the teachings of an A Python framework for programming autonomous robots using a declarative approach of Fichera to include the monitoring of a rule in a loop of Larsen because adding the Rule-Based Dynamic Safety Monitoring for Mobile Robots of Larsen would ease code generation and allow for a specified loop frequency, increasing functionality as described in Larsen [Page 213, paragraph 2] "In order to ease the code generation, a Python library implementing classes for representing rules, entities, topic and node monitoring has been developed. A rule object stores the result of each rule evaluation in a timestamped buffer, making the result of the rule accessible for a given time interval. The topic monitoring class also stores the received ROS messages in a timestamped buffer. Each of the classes implement a loop method allowing the rule to be evaluated, and in the case of a topic, the average frequency to be calculated. The loop method is called on each object at a specific interval, currently 0.1 seconds (10 Hz), but can be set as high as the computer performance allows.")."
Claim 11:
Fichera in view of Larsen teaches “The control apparatus according to claim 8, wherein the data processing unit comprises an inference engine.” (Fichera teaches a reasoning process which is capable of inferring new knowledge in Fichera [Page 37, Section 2, third paragraph] "Beliefs represent the informational state of the agent, which includes the information about its own internal state and the knowledge about the external world. An agent's beliefs are subject to changes due to the data received through sensors, which monitor the external world, and as a result of a reasoning process, which is capable of inferring new knowledge. Beliefs are stored in a knowledge base, which can be queried to check if a specific information is known to the robot, or to determine if the robot/environment is in a certain state.").
Claim 14:
Fichera teaches “A computer program product comprising a computer readable hardware storage device having computer readable program code stored therein,” (Fichera teaches that PROFETA code may be executed in Fichera [Page 42, first paragraph] "Plans are defined in section F, organized in stages when needed. As mentioned earlier, like all PROFETA code, they are also valid Python expressions. This fact, which is obvious for PROFETA entities occurring in previous program sections, also holds for plans, for PROFETA exploits operator overloading to redefine the following operators of its basic classes: “+”, “-”, “/”, “&” and “>>”, i.e., those used to construct plans. The execution of these overloaded operators results, at runtime, in the execution of code that builds structures which represent the plans. This enables the Python virtual machine to interpret these structures as expected according to PROFETA semantics. Further details on how they are handled by the PROFETA core are provided in the following section."), and
“said program code executable by a processor of a computer system” (Fichera teaches that PROFETA runs on a python virtual machine i.e. it is executable by a processor of a computer system in Fichera [Page 37 Section 1 paragraph] "In this work, we tackle the noted issues, proposing as a solution a novel, unified programming environment that smoothly and elegantly integrates imperative and declarative constructs, thereby enabling developers to rapidly create and combine the different parts of a robotic software architecture. Specifically, we propose a framework, called PROFETA (Python Robotic Framework for designing strategies), which builds on the Python programming language and extends it to implement the operational semantics required to define and run BDI agents. PROFETA runs on the Python virtual machine, and extends Python with a set of declarative constructs inspired by AgentSpeak(L), a well-known BDI kernel language [14], [15]. Such constructs were defined through Python's operator overloading, and enable the description of a robot's behavior, while Python's object-oriented/imperative constructs can be used for the implementation of middle and low-level tasks. This paper describes the current state of development of PROFETA, presenting its basics, syntax and architecture, and including a case-study illustrating how to design and develop a robotic application within PROFETA.").
Fichera in view of Larsen teaches “said program code executable by a processor of a computer system to implement a method of claim 1 when the product is run on digital computer.” As described above in claim 1 rejection.
Claims 3, 10, and 12-13 are rejected under 35 U.S.C. 103 as being unpatentable over FICHERA LORIS ET AL: "A Python framework for programming autonomous robots using a declarative approach", SCIENCE OF COMPUTER PROGRAMMING, vol. 139, 1 June 2017 (2017-06-01), pages 36-55) (hereinafter referred to as “Fichera”), in view of ADAM SORIN ET AL: "Towards Rule-Based Dynamic Safety Monitoring for Mobile Robots", 20 October 2014 (2014-10-20), SAT 2015 18TH INTERNATIONAL CONFERENCE, AUSTIN, TX, USA, SEPTEMBER 24-27, 2015; [LECTURE NOTES IN COMPUTER SCIENCE; LECT.NOTES COMPUTER], SPRINGER, BERLIN, HEIDELBERG, PAGE(S) 207 (hereinafter referred to as “Larsen”), further in view of French kevin et al: "Learning behavior trees from demonstration", 2019 international conference on Robotics and automation (icra), IEEE, 20 May 2019 (2019-05-20) (hereinafter referred to as “French”).
Claim 3:
Fichera in view of Larsen teaches “The computer-implemented method according to claim 2,” as described above. Neither Fichera or Larsen appear to explicitly teach “wherein the control programming language is structured according to However, French does teach this claim limitation (French teaches a graphical user interface that allows generation and editing of behavior trees i.e. the control programming language may be structured according to a behavior tree for control of robots in French [Page 7792, Section B, second paragraph] "CoSTAR [15] is an industrial robotics research project designed to make low cost industrial robots like Universal Robots UR5 robot usable in small manufacturing entities. CoSTAR uses behavior trees as the core task representation. The capabilities of the robot are expressed as individual behaviors of the robot. Task predicates are expressed as behavior conditions. By exposing the behavior tree through a graphical user interface that allows generation and editing of behavior trees, CoSTAR allows for transparent analysis, general structure, and classification of execution traces relative to a dictionary of known task [15]").
Fichera, Larsen, and French are analogous art because they are from the same field of endeavor of robot control. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having teachings of Fichera, Larsen, and French before him/her, to modify the teachings of an A Python framework for programming autonomous robots using a declarative approach of Fichera modified to include the monitoring of a rule in a loop of Larsen to include the graphical user interface to allow generation and editing of behavior trees of French because adding the Learning behavior trees from demonstration of French would allow for transparent analysis relative to a dictionary of known tasks as described in in French [Page 7792, Section B, second paragraph] "CoSTAR [15] is an industrial robotics research project designed to make low cost industrial robots like Universal Robots UR5 robot usable in small manufacturing entities. CoSTAR uses behavior trees as the core task representation. The capabilities of the robot are expressed as individual behaviors of the robot. Task predicates are expressed as behavior conditions. By exposing the behavior tree through a graphical user interface that allows generation and editing of behavior trees, CoSTAR allows for transparent analysis, general structure, and classification of execution traces relative to a dictionary of known task [15]"
Claim 10:
Fichera in view of Larsen, further in view of French teaches “The control apparatus according to claim 8, comprising a data programming interface configured to input data rules according to the declarative program paradigm to the data processing unit.” (French teaches a graphical user interface that allows generation and editing of behavior trees i.e. data rules according to a declarative program paradigm for robotics in French [Page 7792, Section B, second paragraph] "CoSTAR [15] is an industrial robotics research project designed to make low cost industrial robots like Universal Robots UR5 robot usable in small manufacturing entities. CoSTAR uses behavior trees as the core task representation. The capabilities of the robot are expressed as individual behaviors of the robot. Task predicates are expressed as behavior conditions. By exposing the behavior tree through a graphical user interface that allows generation and editing of behavior trees, CoSTAR allows for transparent analysis, general structure, and classification of execution traces relative to a dictionary of known task [15]").
Claim 12:
Fichera in view of Larsen, further in view of French teaches “The control apparatus according to claim 8, comprising a graphical control programming interface configured to input explicit guarantees according to the control program steps to the control processing unit.” (French teaches a graphical user interface that allows generation and editing of behavior trees i.e. a graphical control programming interface configured to input guarantees for robotics in French [Page 7792, Section B, second paragraph] "CoSTAR [15] is an industrial robotics research project designed to make low cost industrial robots like Universal Robots UR5 robot usable in small manufacturing entities. CoSTAR uses behavior trees as the core task representation. The capabilities of the robot are expressed as individual behaviors of the robot. Task predicates are expressed as behavior conditions. By exposing the behavior tree through a graphical user interface that allows generation and editing of behavior trees, CoSTAR allows for transparent analysis, general structure, and classification of execution traces relative to a dictionary of known task [15]").
Claim 13:
Fichera in view of Larsen, further in view of French teaches “The control apparatus according to claim 8, wherein the control processing unit comprises an interpreter for interpreting the data program steps structured according to (French teaches a graphical user interface that allows generation and editing of behavior trees i.e. it interprets the behavior tree inputted by the user for robotics in French [Page 7792, Section B, second paragraph] "CoSTAR [15] is an industrial robotics research project designed to make low cost industrial robots like Universal Robots UR5 robot usable in small manufacturing entities. CoSTAR uses behavior trees as the core task representation. The capabilities of the robot are expressed as individual behaviors of the robot. Task predicates are expressed as behavior conditions. By exposing the behavior tree through a graphical user interface that allows generation and editing of behavior trees, CoSTAR allows for transparent analysis, general structure, and classification of execution traces relative to a dictionary of known task [15]").
Claims 5-6 and 9 are rejected under 35 U.S.C. 103 as being unpatentable over FICHERA LORIS ET AL: "A Python framework for programming autonomous robots using a declarative approach", SCIENCE OF COMPUTER PROGRAMMING, vol. 139, 1 June 2017 (2017-06-01), pages 36-55) (hereinafter referred to as “Fichera”), in view of ADAM SORIN ET AL: "Towards Rule-Based Dynamic Safety Monitoring for Mobile Robots", 20 October 2014 (2014-10-20), SAT 2015 18TH INTERNATIONAL CONFERENCE, AUSTIN, TX, USA, SEPTEMBER 24-27, 2015; [LECTURE NOTES IN COMPUTER SCIENCE; LECT.NOTES COMPUTER], SPRINGER, BERLIN, HEIDELBERG, PAGE(S) 207 (hereinafter referred to as “Larsen”), further in view of Hashimoto et al. (US20060279246A1).
Claim 5:
Fichera in view of Larsen teaches “The computer-implemented method according to claim 4,” as described above. Neither Fichera or Larsen appear to explicitly teach “wherein transferring data between the data processing unit and the control processing unit only indirectly via a data storage unit.” However, Hashimoto does teach this claim limitation (Hashimoto teaches a robot control processor 23A i.e. control processing unit accessing a main memory 24A i.e. data storage unit in Hashimoto [0041] "The main memory 24A accessible by the robot control processor 23A at a high speed may be, for example, an SDRAM. The main memory 24A temporarily stores the operation program for operating the robot and the data, and, further, stores the image data (environmental condition data) detected by the CCD camera 31. The operation program and data that are stored, are read out upon being accessed by the robot control processor 23A. As the operation program and the like that are read out accumulate in the cache memory in the processor 23A, the image processing is executed at a higher speed."; Hashimoto teaches that camera controller 6 i.e. data processing unit receives data from a vision sensor and transfers the image data to the main memory 24A after converting the image data into a form that is handled by processor 23A in Hashimoto [0047] "Referring to FIG. 2, the camera controller 6 receives the image data from the CCD camera which is a vision sensor, send the image data that are received to the CPU external bus controller 7, and transfers the image data to the main memory 24A, and is equipped with an interface unit 6 a and a data storage unit 6 b. The interface unit 6 a has a function for converting the image data received from the camera 31 into a form that is handled by the processor 23A.";
[AltContent: rect]
PNG
media_image1.png
688
496
media_image1.png
Greyscale
[AltContent: rect]
PNG
media_image2.png
311
568
media_image2.png
Greyscale
).
Fichera, Larsen, and Hashimoto are analogous art because they are from the same field of endeavor of robot control. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having teachings of Fichera, Larsen, and Hashimoto before him/her, to modify the teachings of an A Python framework for programming autonomous robots using a declarative approach of Fichera modified to include the monitoring of a rule in a loop of Larsen to include the robot control processor, memory, and camera controller of Hashimoto because adding the Robot controller of Hashimoto would allow for processing data from sensors at a decreased cost without decreasing performance of the robot controller as described in in Hashimoto [0050] "According to this embodiment as described above, the image data picked up by the CCD camera 31 are transferred to the main memory 24A at a high speed through the high-speed CPU external bus 37 or the memory bus 39, preventing the transfer of robot control signals from being hindered by the image data. Therefore, it is possible to realize an intelligent robot controller for processing data from various sensors at a decreased cost without decreasing the performance of the robot controller.”
Claim 6:
Fichera in view of Larsen, further in view of Hashimoto teaches “The computer-implemented method according to claim 5, wherein input data from the machine received only in the data storage unit.” (Hashimoto teaches a data storage unit 6b that stores the data until data transfer i.e. the input is received in data storage unit 6b in Hashimoto [0047] "Referring to FIG. 2, the camera controller 6 receives the image data from the CCD camera which is a vision sensor, send the image data that are received to the CPU external bus controller 7, and transfers the image data to the main memory 24A, and is equipped with an interface unit 6 a and a data storage unit 6 b. The interface unit 6 a has a function for converting the image data received from the camera 31 into a form that is handled by the processor 23A. In the case of analog data, the interface unit 6 a works as an interface circuit including an analog/digital converter. In the case of digital data, on the other hand, the interface unit 6 a serves as a receiver circuit. For example, a camera that uses such an interface as USB, IEEE 1394 or Ethernet (registered trademark) transfers the digital data. Therefore, the interface unit works as a receiver circuit for the respective communications. The data storage unit 6 b works to temporarily store the data until the data transfer timing is taken, and comprises, for example, an FIFO buffer.").
Claim 9:
Fichera in view of Larsen, further in view of Hashimoto teaches “The control apparatus according to claim 8, further comprising a data storage unit configured to reactively transfer data between the data processing unit and the control processing unit.” (Hashimoto teaches a robot control processor 23A i.e. control processing unit accessing a main memory 24A i.e. data storage unit in Hashimoto [0041] "The main memory 24A accessible by the robot control processor 23A at a high speed may be, for example, an SDRAM. The main memory 24A temporarily stores the operation program for operating the robot and the data, and, further, stores the image data (environmental condition data) detected by the CCD camera 31. The operation program and data that are stored, are read out upon being accessed by the robot control processor 23A. As the operation program and the like that are read out accumulate in the cache memory in the processor 23A, the image processing is executed at a higher speed."; Hashimoto teaches that camera controller 6 i.e. data processing unit receives data from a vision sensor and transfers the image data to the main memory 24A after converting the image data into a form that is handled by processor 23A in Hashimoto [0047] "Referring to FIG. 2, the camera controller 6 receives the image data from the CCD camera which is a vision sensor, send the image data that are received to the CPU external bus controller 7, and transfers the image data to the main memory 24A, and is equipped with an interface unit 6 a and a data storage unit 6 b. The interface unit 6 a has a function for converting the image data received from the camera 31 into a form that is handled by the processor 23A.").
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Fang et al. (CN112235419A) teaches a method of generating a behavior tree for control of robots in Fang [0026] "The functional module layer includes a behavior tree parsing module, an instruction distribution module, a session management module, a data source management module, a device control module, and a scene configuration module. The behavior tree parsing module uses a JSON-based behavior tree schema to handle the generation of behavior trees. Through the configuration of the JSON file, the behavior tree parsing module can generate behavior trees in memory and trigger execution in a loop.Meanwhile, the behavior tree parsing module also supports receiving task plans from external systems, adapting them to a defined schema, and generating a behavior tree.Based on this extended model, the advantages of the cloud platform can be fully utilized to integrate knowledge base, robot collaboration and other algorithm modules to generate more intelligent and flexible behavior trees to control robots and robot clusters."
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Zachary A Cain whose telephone number is (571)272-4503. The examiner can normally be reached Mon-Fri 7:00-3:30 CST.
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, Kenneth M Lo can be reached at (571) 272-9774. 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.
/Z.A.C./ Examiner, Art Unit 2116 /KENNETH M LO/Supervisory Patent Examiner, Art Unit 2116