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 .
Status
This instant application No. 18/277,211 has claims 1-15 pending based on the preliminary amendment filed on August 14, 2023.
Priority / Filing Date
Applicant’s claim for priority of PCT/EP2022/053396 (filed on February 11, 2022) which claims priority of EP 21157352.2 (filed on February 16, 2021) is acknowledged. The effective filing date for this application is February 16, 2021.
Drawings
The drawings filed on August 14, 2023 are acceptable for examination purposes.
Information Disclosure Statement
As required by M.P.E.P. 609(C), the Applicant’s submissions of the Information Disclosure Statements filed on 17 January 2024, 7 February 2025, 18 September 2025, 13 February 2026, and 11 March 2026 are acknowledged by the Examiner and the cited references have been considered in the examination of the claims now pending. As required by M.P.E.P. 609 C(2), each copy of the PTOL-1449s initialed and dated by the Examiner is attached to the instant Office action.
Claim Rejections - 35 USC § 112
35 U.S.C. 112 reads as follows:
(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.
Claims 11, and 15 are rejected under 35 U.S.C. 112(b) for being indefinite as the claims recite terms whose scope(s) is/are not reasonably ascertainable.
Claim 11 recites removing an unwanted defined type but does not identify an objective criterion for determining when a defined type is unwanted.
Claim 15 recites that defined types in both parts are substantially identical but does not provide an objective standard for determining the degree of similarity (what percentage of similarity constitutes substantially identical, e.g., 51% or 99%?). Further, there is no objective criterion for defining conflicting rules or a conflicting hierarchy when certain rules or hierarchy is/are conflicting.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-15 are rejected under 35 U.S.C. 101 because the claimed invention is directed to nonstatutory subject matters.
Regarding claim 1, a “modelling apparatus” is being claimed. However, this modelling apparatus can be interpreted by a person of ordinary skills in the art as being implemented by software modules that carry out the claimed functions. Furthermore, in accordance with Applicant’s specification ([Page 8, Lines 13-17] of Specification), Applicant states the modelling apparatus…may be implemented…in software… consisting of data structures and computer programs, which impart functionality when employed as an apparatus. As such, the claim is not limited to statutory subject matter and is therefore non-statutory.
Applicant is suggested to include at least one hardware component (e.g. computer processor and computer memory) and explain how the at least one hardware component can be utilized within the claimed system. One example is as follows:
“A modelling apparatus for modelling a robotic system, the modelling apparatus comprising at least one hardware processor and memory configured to:…”
Similarly, the claimed interface (claim 13) and multi-apparatus modelling system comprising first and second modelling apparatuses (claim 14) are interpreted to be implementable by software modules (e.g., virtual API simulators connecting multiple software apparatuses). As such, claims 2-15 fail to resolve the deficiencies of claim 1 and are also rejected under 35 U.S.C. 101.
Assuming that the claimed apparatus is hardware-implemented, the claimed invention in claims 1-15 would still be directed to a judicial exception (i.e., an abstract idea) without significantly more.
a. Independent claim 1 recites in elements that are directed to an abstract idea (“Courts have examined claims that required the use of a computer and still found that the underlying, patent-ineligible invention could be performed via pen and paper or in a person’s mind.” Versata Dev. Group v. SAP Am., Inc., 793 F.3d 1306, 1335, 115 USPQ2d 1681, 1702 (Fed. Cir. 2015)). The claim recites a mental process of organization and evaluation operations:
modelling the robotic system with a model comprising instances of defined types and links representing relationships;
defining types and parent-child relationships as nodes and directional edges of one or more directed acyclic graphs (DAGs);
defining and inheriting type rules among parent and child types; and
validating the model against validation rules by determining whether the model satisfies those rules.
These limitations recite organizing information into categories and hierarchical relationships, applying rules to the categorized information, and evaluating whether the information conforms to the rules. Such operations are reasonably characterized as a mental process because a person can perform them in the mind with the aid of pen/paper (e.g., a systems designer could list robotic-system elements, classify each element under a type hierarchy, identify relationships among the listed elements, apply inherited rules, and decide whether each element and relationship conforms to the selected rules. The claimed defined types, instances, links, parent-child relationships, type rules, and validation rules are information constructs without requiring a particular physical representation of a robotic component. Instead, the limitations organize descriptive information and determine whether that information complies with other descriptive information. Thus, at a minimum, the claim recites a mental process of classifying and evaluating information, and also may be characterized as reciting mathematical relationships and logical rules.
Per Step 2A – Prong 2, the claim does not include additional elements that integrate the abstract idea into a practical application. The claim, considered as a whole, uses generic modelling apparatus functionality to perform and apply the abstract mental process in the technological environment of robotic system modelling without reciting an improving to computer or robotic system functionality. The additional elements, considered individually and as an ordered combination, amount to no more than generic computer implementation of the abstract idea. The claim does not recite specialized hardware configuration, a nonconventional data storage architecture, a particular graph processing mechanism, an unconventional validation engine, or any claim implementation that provides a technical improvement:
The claimed modelling apparatus is recited only at a high level of generality, and the apparatus is invoked as a generic computer-based environment in which the abstract data modeling and validation operations are performed.
The recitation of a robotic system merely identifies a technological field in which the abstract idea is used. The claim does not require that validation causes the robotic system to move, changes a physical operating parameter, controls an actuator, etc. Rather, each instance is broadly recited as a description of an element of the robotic system. Thus, the claim concerns the organization and validation of descriptions of robotic system elements, not an improvement to operation of the robotic system itself.
The DAG and inheritance limitations define the content and logical arrangement of the validation rules. Storing or organizing information as nodes, links, types, parent-child relationships, and inheritance rules is a form a data organization. The claim does not recite how the graph is stored, traversed, updated, validated, or processed in a manner that improves computer performance such as reduced memory usage, faster validation, reduced network traffic, etc.
The claimed determining whether the model satisfies [the validation] rules is an abstract evaluation. Merely applying a selected set of logical validation rules to a selected body of information does not integrate the abstract idea into a practical application.
Per Step 2B, the ordered combination, considered both individually and as an ordered combination, does not provide significantly more. The ordered combination consists of (1) organizing descriptions of robotic system elements as typed instances and relational links, (2) defining a hierarchy of types and inherited rules, and (3) determining whether the resulting information conforms to those rules. This is the abstract idea itself implemented on a generic apparatus. The fact that the information describes a robotic system does not provide an inventive concept because the claim does not require use of the evaluated information to physically operate or improve a robot. Thus, claim 1 is ineligible under 35 U.S.C. 101.
b. Regarding claims 2-12, when considered individually and in combination with claim 1, they do not integrate the recited abstract idea into a practical application and do not provide an inventive concept.
Per step 2A – prong 2, the claims add further details concerning the content, hierarchy, formatting, organization, modification and validation of
Claims 2-3 recite inherited and non-inherited type rules, multiple parent types, and multilevel parent-child hierarchies.
Claim 4 recites morphological rules defining permitted interconnections.
Claim 5 recites directional links, link ownership, and input/output relationships.
Claim 6 recites descriptive and functional types and data describing a current or target robotic system’s state.
Claims 7-9 recite instance data units, type data units, and common structured formats.
Claims 10-11 recite changing model data, type rules, types, instances, and links, followed by revalidation.
Claim 12 recites that the descriptive information pertains to a robot, robot controller, and/or current or target state.
These limitations merely further define the information being organized, the logical relationships among the information, and the rules used to validate that information. They do not recite a particular improvement to computer operation, database operation, graph processing, model validation, robotic sensing, robotic control, or another technology. Nor do the claims recite a particular machine configuration, specialized hardware, transformation, or other meaningful restriction that applies the abstract idea in a practical manner. The recitation of information describing a robotic system, robot controller, current state, or target state merely limits the abstract data modeling an validation activity to a stated field of use. The claims do not require that the claimed model or validation outcome cause a particular physical operation or improvement in the robotic system. As such, the claims do not integrate the judicial exception into a practical application.
Per step 2B, the additional elements, individually and in combination, do not amount to significantly more than the abstract idea. The claims recite well-understood, routine, and conventional (WURC) information management functions including defining and inheriting rules, categorizing data, maintaining type hierarchies, representing relationships with links, formatting data records, adding or removing data, modifying ules, and repeating a validation operation after an update. The claims do not recite a non-conventional hardware arrangement, a particular graph processing technique, a specific data storage architecture, or an implementation that improves computer or robotic system performance. The ordered combination simply applies the abstract idea of organizing and evaluating information under selected validation rules with increasingly detailed logical constraints and generic data structures. Thus, the claims do not recite an inventive concept sufficient to transform the judicial exception into a patent eligible application.
c. Regarding claim 13, when considered individually and in combination with claim 1, the additional interface, input, model-update, and control-output do not integrate the recited abstract idea into a practical application and do not provide significantly more.
Per step 2A – prong 2, the claim recites an interface connected to the robotic system and, following validation, receiving data from the robotic system to update the model and/or outputting data to control the robotic system based on the model. These limitations are stated at a result-oriented level of generality without reciting a particular sensor, actuator, robot controller, communication protocol, control signal, etc. The claim also does not specify how the result of the claimed model validation changes operation of the robotic system. Thus, the interface merely provides generic input/output functionality in conjunction with the abstract data modeling and validation process. Broadly reciting output of data to control a robotic system based on the model does not establish a practical application where the claim does not require a particular technical control operation or an improvement to robotic functionality.
d. Regarding claims 14-15, the multi-apparatus configuration does not integrate the recited abstract idea into a practical application and does not provide an inventive concept.
Per step 2A – prong 2, claim 14 recites first and second modeling apparatuses that communicate with one another and determine interoperability by cross-validating models against one another’s rules and/or determining compatibility between respective portions of type-hierarchy graphs. Claim 15 further specifies compatibility criteria based on similarity of types, common type rules, and absence of conflicting rules or hierarchies. The additional limitations merely apply the abstract comparison and evaluation of information to two models rather than one. The claims do not recite a particular distributed processing architecture, network protocol, interoperability format, data conversion techniques, robotics communication mechanism, or technical operation performed in response to the compatibility determination. Further, determining interoperability is a stated result of comparing and validating descriptive information. The claims do not require establishment of a communication link, translation between incompatible robotic control protocols, configuration of a robot controller, coordinated movement of robots, or another cocreate technological use of the determination. Thus, the claims do not integrate the judicial exception into a practical application.
Per step 2B, the additional elements amount to generic use of two communicating modeling apparatuses to compare data, apply validation rules, and determine compatibility. Communication between generic apparatuses and comparison of stored models and rule sets are WURC computer functions. The claimed compatibility criteria (substantial identity, shared rules, and absence of conflicts) are part of the abstract comparison itself. The claims do not recite a specialized computer configuration or a specific technological improvement in multi-robot interoperability, data communication, robotics control, or computer performance. As such, the claims, individually and as an ordered combination, do not recite significantly more than the judicial exception and are ineligible.
Claim Rejections - 35 USC § 102
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)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-15 are rejected under AIA 35 U.S.C. 102(a)(1) as being anticipated by Caliskanelli et al. (“CorteX: A Software Framework for Interoperable, Plug-and-Play, Distributed, Robotic Systems of Systems”; published on December 17, 2020; hereinafter Caliskanelli).
It is noted that there are six co-authors in the paper that were not listed as inventors in this instant application, thus, the paper qualifies as 35 U.S.C. 102(a)(1) prior art based on the publication date.
Regarding claim 1, Caliskanelli clearly shows and discloses modelling apparatus for modelling a robotic system (CorteX applies an inherently concurrent architectural design through the use of object-orientated design methodologies and implements the imperative paradigm within the single methods only (i.e. control system functions) and for main executables, [Page 307]), the modelling apparatus configured to:
model the robotic system with a model, the model comprising instances of at least a subset of a set of defined types interconnected with links (A system in the CorteX environment can be represented with a graph consisting of nodes and edges, similar to the graph presented in Fig. 10.6. Every node in a CorteX environment is called a simplex and every edge denotes information flow between simplexes, [Pages 307-308]), each instance being a description of an element of the robotic system (The term simplex is used to describe units of data within CorteX, facilitating functionality within the control system, including: defining data, describing input and output relationships, calling functionality, representing (a part of) a system, controlling an active element (i.e. controller), or communicating with other simplexes within the system, [Pages 307-308]), the links between the instances representing relationships therebetween (rlspm: A link to another simplex, in order to obtain information or call a command. It may be a single element or an array. This is automatically generated and set based on the ontological type, [Page 308]); and
validate the model against validation rules by determining whether the model satisfies those rules (Ontology, morphology, and the type model that are explained in the previous section are validated in the CorteX Core against a given use case. For example, the case study presented in Fig. 10.7 and the associated types of each simplex are validated against the ontology and the morphological rules. The initialisation process achieves success if, and only if, all the simplexes can compile correctly, thus requiring construction of data, relationships, commands, and command parameters to match with the associated simplex type and morphological rules, [Page 317]), wherein the validation rules comprise:
a definition of one or more directed acyclic graphs of the defined types interconnected with parent-child relationships, the defined types corresponding to nodes and the parent-child relationships corresponding to directional edges of the one or more directed acyclic graphs (In the proposed interoperable solution, data belonging to a particular component is complimented with a combined architecture and inheritance type structure of the component, [Page 296]. The ability to use a simplex of a given type at various levels of its inheritance hierarchy allows for standardisation but also extension, in the form of polymorphism, [Page 311]. Obeying any dependency driven order (often in the form of Directed Acyclic Graph (DAG)), and execute them in parallel where possible, [Page 322]),
each defined type defining type rules for that type which an instance of that type must satisfy in order to be valid (a robotics and control system ontology is used to provide semantic meaning to components of robotic and control system elements, represented by simplexes. On the other hand, morphology is used to provide a set of rules to enforce the syntactic meaning and a binding structure to the component types represented in the ontology to achieve operational success among the distributed components, [Page 311]. The types that are provided in the ontology not only define functionality and structure but also data represented and external interfaces. Types can define not only the relationships a component must have to be considered of that particular type), but also how many (minimum, maximum, or absolute) components must be related to it, and define a particular type that the related components must be, [Page 312]),
each parent-child relationship between a pair of the types defining those types as parent and child types relative to one another according to the corresponding edge direction, wherein each child type inherits the type rules of each of its parent types according to the parent-child relationships (Using the ontology built for the type inheritance model structure, the CorteX system is capable of discovering that the Kuka LBR IIWA type also inherits the Serial Manipulator interface, [Page 309]. Agent A declares the Axis type as before. Agent B declares an Axis type with a definition that matches Agent A, but also declares another type that inherits from Axis, states it contains torque data, and calls it AxisWithTorque. Not only does this mean that Agent B can add their data to the system, but Agent A can also use the simplex of type AxisWithTorque with any interface designed for a simplex of type Axis as one inherits from the other, and therefore must contain all the required information from the Axis type, [Page 311]).
Regarding claim 2, Caliskanelli further discloses each child type defines:
the type rules which that child type inherits from each of its parent types by reference to each of its parent types; and/or
each type rule for that child type beyond the type rules which that child type inherits from each of its parent types (Agent A declares the Axis type as before. Agent B declares an Axis type with a definition that matches Agent A, but also declares another type that inherits from Axis, states it contains torque data, and calls it AxisWithTorque, [Page 311]).
Regarding claim 3, Caliskanelli further discloses:
at least one child type has at least two parent types (Careful examination can detect that Robotiq 2-Finger Gripper is classified under the 1DOF Manipulator and listed under the Gripper type model, [Page 309]); and/or
at least one child type has at least one parent type which itself is a child type having at least one parent type, optionally which itself is a child type having at least one parent type.
Regarding claim 4, Caliskanelli further discloses the validation rules comprise morphological rules which define, for at least one particular defined type, interconnections which an instance of that particular defined type must have with other instances of defined types in the model in order for the model to be valid, optionally wherein, for at least one defined type, its type rules comprise its morphological rules (Types can define not only the relationships a component must have (to be considered of that particular type), but also how many (minimum, maximum, or absolute) components must be related to it, and define a particular type that the related components must be, [Page 312]).
Regarding claim 5, Caliskanelli further discloses the model defines a directed graph of its instances, the links being directional links, the instances corresponding to nodes and the links corresponding to edges of the directed graph (A system in the CorteX environment can be represented with a graph consisting of nodes and edges, similar to the graph presented in Fig. 10.6. Every node in a CorteX environment is called a simplex and every edge denotes information flow between simplexes, [Page 307]), each link being owned by one of the instances which it interconnects, the direction of the links representing an input relationship or an output relationship between the interconnected instances concerned relative to the instance owning the link concerned (Arrowheads in the boxes denote the ownership of the rule; boxes that contain the arrowheads are the owners of the morphological rules and are responsible for implementing the associated rule. The first rule is to provide input to the processor. This may not be required if the process is “open loop” and is therefore optional. The second rule is designed to allow for sub-processes that may need to be completed first for the processor to function. This may also not be required and is therefore also optional. The final rule is to provide an output for the processor, [Page 314]).
Regarding claim 6, Caliskanelli further discloses:
the defined types comprise descriptive types and optionally also at least one functional type; each instance of a descriptive type describes a current state and/or a target state of its element of the robotic system; and optionally each instance of a functional type describes how to manipulate data of an interconnected instance of a descriptive type to derive information which describes the robotic system and/or to model activity in the robotic system (Fig. 10.3 Robotic and control system ontology—type model. Within our implementation, type modules fall into two main categories: descriptive shown in blue and active shown in white. Active modules, on the other hand, are used in full CorteX control systems (CorteX CS) in which functionality has been added, in order for the modules to manipulate the data, [Page 310]).
Regarding claim 7, Caliskanelli further discloses each instance is an instance data unit which optionally defines each of its links to another instance or instances of the model, optionally wherein the instance data units have the same structured format as one another (Each simplex uses the same format for internal data representation and has the same external interface, [Page 307]. A typical simplex sm S, a self-contained unit of information, is the tuple: sm =<typem, idm, datam, rlspm, cmdm, cmdboxm >, [Page 308]).
Regarding claim 8, Caliskanelli further discloses the definition of the one or more directed acyclic graphs of the defined types comprises a type data unit per defined type, each said type data unit defining the defined type concerned (The implementation of this solution takes the form of a core library containing standardised structures for storing the data and metadata, [Page 296]) and optionally, for each defined type other than a root defined type corresponding to a root node of the one or more directed acyclic graphs, the parent-child relationship to each of its parent types (In the proposed interoperable solution, data belonging to a particular component is complimented with a combined architecture and inheritance type structure of the component, [Page 296]. Agent B declares an Axis type with a definition that matches Agent A, but also declares another type that inherits from Axis, states it contains torque data, and calls it AxisWithTorque, [Page 311]).
Regarding claim 9, Caliskanelli further discloses the type data units have the same structured format as one another, optionally wherein the structured format of the instance data units corresponds to the structured format of the type data units (Each simplex uses the same format for internal data representation and has the same external interface, as shown in Fig. 10.2. This data representation can be used as part of a communications protocol to allow distributed components of a single control system to exchange data without prior knowledge of each other, [Page 307]).
Regarding claim 10, Caliskanelli further discloses:
changing the model and/or the validation rules (The type model is distributed at runtime and can be completely customised for the particular application, rather than using predetermined types, [Page 311]); and
following said change, validating the model against the validation rules by determining whether the model satisfies those rules (The initialisation process achieves success if, and only if, all the simplexes can compile correctly, thus requiring construction of data, relationships, commands, and command parameters to match with the associated simplex type and morphological rules, [Page 317]).
Regarding claim 11, Caliskanelli further discloses said change comprises at least one of:
changing the type rules of one of the defined types, optionally of one of the defined types of which the model comprises an instance, or of one of the defined types from which a particular defined type inherits type rules, the model comprising an instance of that particular defined type, or of one of the defined types which inherits type rules from a given defined type, the model comprising an instance of that given defined type;
adding a new defined type to the one or more directed acyclic graphs along with at least one parent-child relationship to an existing defined type of the one or more directed acyclic graphs, optionally wherein the new defined type is interconnected with a parent-child relationship to a particular existing defined type such that it inherits the type rules of that particular existing defined type, the model comprising an instance of that particular existing defined type;
removing an unwanted defined type from the one or more directed acyclic graphs along with each of its parent-child relationships to an existing defined type of the one or more directed acyclic graphs, optionally along with removing any defined type which inherits its rules from the unwanted defined type, optionally wherein the unwanted defined type is interconnected with at least one parent-child relationship to a particular existing defined type such that it inherits the type rules of that particular existing defined type, the model comprising an instance of that particular existing defined type;
changing an instance of a defined type in the model;
adding an instance of a defined type to the model along with at least one link to an existing instance of the model (This means that an Arm component cannot be added to a CorteX system without a Serial Manipulator component and a Gripper component and the relationships configured to connect them, [Page 313]. New CorteX agents (Clusters) may also be discovered at runtime, so when new CorteX participants “come online”, they will appear in the DDS interface automatically, [Page 320]); and
removing an instance of a defined type from the model along with at least one link to an existing instance of the model.
Regarding claim 12, Caliskanelli further discloses:
each instance of the model is a description of an element of a robot of the robotic system and/or of a robot controller of the robotic system (a robotics and control system ontology is used to provide semantic meaning to components of robotic and control system elements, represented by simplexes, [Page 311]); and/or
the model represents a current state and/or a target state of at least part of:
the robotic system;
the robot of the robotic system; or
the robot controller of the robotic system.
Regarding claim 13, Caliskanelli further discloses an interface for connection between the modelling apparatus and the robotic system, wherein the modelling apparatus is configured, following validation of the model, to:
receive data from the robotic system via the interface and to update the model based on the received data; and/or output data via the interface to the robotic system to control the robotic system based on the model (In terms of hardware, an observation contains data read from the hardware, and a modification would contain data to be written back to the hardware as a demand, [Page 310]. The left side of each axis view shows the current state of the axis from the DS402 Observation, the centre drive control area shows state values and control buttons for the DS402 Processor, and the right side shows the demand state of the drive from the DS402 Modification, [Page 327]).
Regarding claim 14, Caliskanelli further discloses a multi-apparatus modelling system comprising first and second modelling apparatuses configured to communicate with one another, each of the first and second modelling apparatuses being a modelling apparatus as claimed in claim 1, wherein: the first modelling apparatus models a first robotic system with a first model of the first robotic system and the second modelling apparatus models a second robotic system with a second model of the second robotic system (New CorteX agents (Clusters) may also be discovered at runtime, so when new CorteX participants “come online”, they will appear in the DDS interface automatically. CorteX provides fully distributed data transmission and communication via DDS, in (almost) real-time manner. Therefore, unlike MQTT or ROS, there is no need for a central server, as each individual CorteX agent is able to broadcast messages to all other agents in a fully decentralised, distributed manner, [Page 320]); and
the multi-apparatus modelling system is configured to determine interoperability between the first model and the second model by:
validating the first model against the validation rules of the second modelling apparatus; and/or
validating the second model against the validation rules of the first modelling apparatus; and/or
determining compatibility between at least a first-model-specific part of the one or more directed acyclic graphs of the first modelling apparatus and a second-model-specific part of the one or more directed acyclic graphs of the second modelling apparatus (If two systems are required to interoperate, then the types within their type models must not contradict each other, but the overall models do not need to be identical, [Page 311]).
Regarding claim 15, Caliskanelli further discloses determining that at least the first-model-specific part of the one or more directed acyclic graphs of the first modelling apparatus and at least the second-model-specific part of the one or more directed acyclic graphs of the second modelling apparatus are compatible (If two systems are required to interoperate, then the types within their type models must not contradict each other, but the overall models do not need to be identical, [Page 311]) if:
those defined types which are in both of those parts are substantially identical; and/or
those defined types which are in both of those parts define at least the same type rules as one another; and/or
they do not define conflicting rules or a conflicting hierarchy of defined types (These two agents are not interoperable as they do not agree on the definition of the Axis type, [Page 311]).
Relevant Prior Art
The following references are deemed relevant to the claims:
Sun et al. (Pub. No. US 2021/0122046) teaches using robotic system simulation to control a robotic system. A communication indicating an action to be performed by a robotic element is received from a robotic control system. Performance of the action by the robotic element is simulated. A state tracking data is updated to reflect a virtual change to one or more state variables as a result of simulated performance of the action. Successful completion of the action by the robotic element is reported to the robotic control system.
Hellman et al. (Pub. No. US 2003/0163597) teaches ontology enables creation of a model of multiple classes and a graph of relationships therebetween. When a class is defined, its attributes are described using handles to related classes. These can in turn be used to look up attributes of the related class, and thus attributes of attributes can be accessed to any depth. The ability to update ontology definitions is provided, by controlling changes made to an ontology so as to ensure backward compatibility. This ensures that a vocabulary that is valid within the framework of a current ontology will continue to be valid with respect to future evolutions of the ontology. Preferably, the present invention uses rules for allowing only a "safe" set of edits to be performed on an ontology.
Contact Information
Any inquiry concerning this communication or earlier communications from the Examiner should be directed to Son Hoang whose telephone number is (571) 270-1752. The Examiner can normally be reached on Monday – Friday (7:00 AM – 4:00 PM).
If attempts to reach the Examiner by telephone are unsuccessful, the Examiner’s supervisor, Sherief Badawi can be reached on (571) 272-9782. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SON T HOANG/Primary Examiner, Art Unit 2169
September 17, 2026
Prosecution Insights