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 .
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, 5-8, 12-15, 18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Perrone (US 20180095467 A1), in view of Leon et al. (US 20220274251 A1), herein after will be referred to as Leon.
Regarding Claim 1
Disclosure by Perrone
Perrone teaches:
A method of using a general-purpose robotics operating system (GPROS), the method comprising: See at least: “In another aspect, an embodiment provides methods for using a GPROS. In aspects, the methods can comprise: providing a set of application services for accessing configuration data using a generic abstraction…” (Perrone, [0046]) “This aspect is also a method for using a general purpose robotics operating system (GPROS), wherein the method comprises: providing a set of robotics application services to access configuration data using a generic abstraction…” (Perrone, [0046])
Rationale: Perrone expressly teaches a method of using a general purpose robotics operating system (GPROS). The transitional language “the method comprising:” is accounted for because Perrone teaches that the GPROS method “can comprise” providing application services and executing GPROS services.
loading the GPROS configuration data See at least: “An embodiment in aspects also defines a method by which configuration data may be loaded, transparent to the application, from one or more configuration data sources in both a static fashion (i.e., at application startup) or dynamically (i.e., as the application is running).” (Perrone, [0006])
Rationale: Perrone expressly teaches that configuration data may be loaded from one or more configuration data sources either statically at application startup or dynamically while the application is running. Because the configuration data is used in Perrone’s GPROS framework, Perrone teaches loading the GPROS configuration data.
and the service extension files See at least: “In these embodiments, the software of an embodiment can be run alone or in conjunction with additional software applications, services extensions, modules, etc. (i.e., plug-ins), which may be created separately by a programmer.” (Perrone, [0028]) “Configuration data can be read or sent over a variety of network connections, and the code itself can be read or sent over a network, such that the initial code requires no additional customization. If multiple robots on a network include an embodiment, new configuration and code (and hence, behavior) can all be dynamically, and optionally simultaneously, loaded into any robot on the network.” (Perrone, [0010])
Rationale: Perrone expressly teaches service extensions, modules, and plug-ins in [0028], and further teaches that “code itself” and “new configuration and code” may be dynamically loaded in [0010]. A PHOSITA would have understood the dynamically loadable “code” of Perrone [0010] to include Perrone’s service extensions, modules, and plug-ins [0028]. Therefore, Perrone renders the service extension files obvious.
into a GPROS-based application; See at least: “GPROS, as depicted in FIG. 1, allows for specific robotics applications 130 to be created. For example, an autonomous unmanned ground vehicle (UGV) application for traversing a long distance within a route corridor while avoiding obstacles may be built on the GPROS, leveraging common robotics software services.” (Perrone, [0101])
Rationale: Perrone expressly teaches that specific robotics applications may be built on GPROS and may leverage common GPROS robotics software services. Therefore, loading GPROS configuration data and loadable service-extension code artifacts into such an application corresponds to loading the GPROS configuration data and the service-extension files into a GPROS-based application.
and using the GPROS-based application See at least: “By using some embodiments’ services, robotics and automation applications inherit complete static and dynamic configurability, configurability using any underlying configuration medium, automateable assembly and construction based on configuration information, automateable deployment based on configuration information…” (Perrone, [0106]) “The GPROS engine provides the rest and hence a platform atop of which robotics and automation applications can be more rapidly, dynamically, extensibly, and affordably developed, configured, assembled, deployed, distributed, and managed.” (Perrone, [0106])
Rationale: Perrone expressly teaches GPROS-based robotics and automation applications that are configured, assembled, deployed, distributed, and managed using GPROS services and configuration information. This corresponds to using the GPROS-based application.
to operate a GPROS-based robot See at least: “The RobotGeneric 703 is a completely configurable abstraction that can be used to model any type of robot. Sensors 711, Conduct, and Actuators 721 are associated with a robot in a configurable fashion.” (Perrone, [0203]) “Upon construction using the Config 540 and Registry service, the robot may be commanded according to its lifecycle to live, wake, sleep, and die.” (Perrone, [0203])
Rationale: Perrone expressly teaches a configurable GPROS robot abstraction with configurable sensors, conduct, and actuators, and further teaches that the robot may be commanded according to its lifecycle. This corresponds to using the GPROS-based application to operate a GPROS-based robot.
or a GPROS-based autonomous vehicle. See at least: “Thus, GPROS applies to and is used as an unmanned ground vehicle operating system and autonomous vehicle operating system.” (Perrone, [0205]) “As can be seen, by configuring the various application services of GPROS, a fully autonomous or automated vehicle, otherwise referred to as a driverless car or self-driving car, can be realized.” (Perrone, [0305])
Rationale: Perrone expressly teaches that GPROS is used as an autonomous vehicle operating system and that configuring GPROS application services realizes a fully autonomous or automated vehicle. This corresponds to the claimed alternative a GPROS-based autonomous vehicle.
Claim Limitations Not Explicitly Disclosed by Perrone
Perrone does not explicitly teach the following claim limitations: with generative pre-trained transformers (GPT) (GPROS-GPT) model, training the GPROS-GPT model; querying the GPROS-GPT model to generate GPROS configuration data and service extension files.
Disclosure by Leon
Leon renders obvious:
with generative pre-trained transformers / (GPT) / (GPROS-GPT) model, See at least: “The action recommendation circuitry 202 includes a generative artificial intelligence (AI) model that proposes actions based on representations of the task, environment, and scene.” (Leon, [0038]) “The example action recommendation circuitry 202 is trained, in part, on augmented code stored in the augmented code database 216.” (Leon, [0038]) “In some examples, the generative model architecture is capable of generating multiple outputs for a single input.” (Leon, [0040]) “Output features from the 2D CNN and 3D CNN networks may be provided to a recurrent neural network (RNN) model such as a long short-term memory (LSTM) or a transformer model that preserves the temporal aspects of action sequences in description processing.” (Leon, [0048])
Rationale: The parenthetical (GPT) is the abbreviation for generative pre-trained transformers, and (GPROS-GPT) model is the coined compound term identifying a GPT-style model adapted for Perrone’s GPROS framework. Leon supplies the generative AI, transformer, training, and robot-code recommendation model concept, while Perrone supplies the GPROS environment. Leon expressly teaches a trained generative AI model for robot code/action recommendation, and also teaches the use of a transformer model to preserve temporal aspects of action sequences. Leon does not literally recite “generative pre-trained transformers” or “GPT.” However, it is well-known in the art of AI software development that by the effective filing date, generative pre-trained transformer (GPT) architectures—wherein a model is first broadly pre-trained on large-scale datasets before being fine-tuned or adapted for domain-specific tasks such as code or action generation—were a ubiquitous and predictable design choice for implementing generative AI systems. A PHOSITA would therefore have recognized a GPT-style generative pre-trained transformer as a well-known and predictable architecture for implementing Leon’s generative AI model for robot code/action recommendation. Substituting this known GPT-style architecture for Leon’s generative model would have been obvious. When adapted to Perrone’s GPROS framework, the resulting model is the claimed generative pre-trained transformer (GPT) model (GPROS-GPT).
training the GPROS-GPT model; See at least: “FIG. 5 is a flowchart representative of example machine readable instructions and/or example operations 500 that may be executed and/or instantiated by processor circuitry to implement industrial robot code recommendations. The machine readable instructions and/or operations 500 of FIG. 5 begin at block 502, at which the code recommendation circuitry 102 of FIGS. 1-4 is trained. The code recommendation circuitry 102 of FIGS. 1-4 includes at least two generative models which are additionally trained at block 502.” (Leon, [0068]) “Therefore, the parameter recommendation circuitry 204 trains a generative model for each action.” (Leon, [0045]) “Example 17 includes the method of any of the previous examples, further including training the first and second generative artificial intelligence models based on encoded task, encoded environment, and previous action data.” (Leon, [0125])
Rationale: Leon expressly teaches training generative models in a robot-code recommendation system. In the proposed combination, Leon’s trained generative model is implemented as a GPT-style generative pre-trained transformer and adapted to Perrone’s GPROS configuration and service-extension environment. This renders the obvious training of the GPROS-GPT model.
querying the GPROS-GPT model See at least: “At runtime, the action recommendation circuitry 202 performs action recommendations based on an encoded task and environment description, an initial action sequence (that can be empty) and a scene state representation from sensor data.” (Leon, [0042]) “Encoded task and environment data may be expressed as a vector or word embedding. An example encoding method includes semantic lifting of natural language queries, parsing the query within the context of the industrial robot 104 of FIG. 1.” (Leon, [0049])
Rationale: Leon expressly teaches runtime recommendation based on encoded task/environment descriptions and natural-language queries parsed in the context of a robot. In the proposed combination, the natural-language query is applied to the GPROS-adapted GPT-style generative model. Therefore, Leon renders obvious querying the GPROS-GPT model.
to generate GPROS configuration data and service extension files; See at least: “The action recommendation circuitry 202 includes a generative artificial intelligence (AI) model that proposes actions based on representations of the task, environment, and scene.” (Leon, [0038]) “In some examples, the generative model architecture is capable of generating multiple outputs for a single input.” (Leon, [0040]) “The parameter recommendation circuitry 204 generates parameters of suggested actions.” (Leon, [0043]) “The configuration services are used in conjunction with an object registration service to automatically create, configure, assemble, deploy, launch, and manage any application objects defined in the configuration.” (Perrone, [0023]) “In these embodiments, the software of an embodiment can be run alone or in conjunction with additional software applications, services extensions, modules, etc. (i.e., plug-ins), which may be created separately by a programmer.” (Perrone, [0028]) “Provision of all of these services in a combined fashion enables robotics application providers (e.g., developers and tools) to focus on specifying the business logic and configuration data specific to a robotics or automation application.” (Perrone, [0106]) “new configuration and code (and hence, behavior) can all be dynamically, and optionally simultaneously, loaded into any robot on the network.” (Perrone, [0010])
Rationale: Leon expressly teaches the use of trained generative AI models to produce action proposals, multiple ranked outputs, and associated parameters for robot operation based on task, environment, and scene data. Perrone teaches that GPROS-based robotics applications and robot behavior are defined and operated through configuration data that its configuration services use to automatically create, configure, assemble, deploy, and manage application objects, and that such applications may incorporate service extensions, modules, and plug-ins (i.e., loadable code artifacts) created separately by a programmer. Perrone further teaches that new configurations and code can be dynamically loaded to change robot behavior.
It would have been obvious to one of ordinary skill in the art to adapt Leon’s generated action proposals, sequences, and parameters so that the generative output is expressed in the form of Perrone-compatible GPROS configuration data (e.g., data structures defining RobotGeneric Conduct, ActionPlans, or behavioral specifications) and/or service extension files (e.g., loadable modules or plug-ins that extend GPROS services or implement custom behavior). A PHOSITA would have reasonably expected success in doing so because both references are directed to programmatically specifying and extending robot behavior—Leon by generating actionable behavioral recommendations from high-level task/environment inputs, and Perrone by consuming configuration data and loadable code extensions to define, assemble, and operate that behavior within a GPROS framework. The combination, therefore, renders obvious querying the GPROS-GPT model to generate GPROS configuration data and service extension files.
Motivation to Combine Perrone and Leon
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Perrone and Leon before them, to modify Perrone’s GPROS configuration, service-extension, and robotics-application framework by incorporating Leon’s trained generative AI robot-code recommendation system, including a GPT-style generative pre-trained transformer architecture as the generative model, so that natural-language or task/environment-based queries could generate Perrone-compatible GPROS configuration data and service-extension code artifacts for loading into and using a GPROS-based robot or autonomous-vehicle application.
Perrone and Leon are both directed to the same field of endeavor — robotics software systems and automated robot programming — such that a PHOSITA working in this field would have been familiar with both references.
Perrone expressly teaches that the GPROS platform “lends itself to automating the process of robotics and automation configuration, assembly, construction, deployment, and development by use of associated tools” (Perrone, [0008]), thereby providing an express textual suggestion to incorporate automated generation tools such as Leon’s generative AI model into Perrone’s GPROS framework.
A PHOSITA would have been motivated to make this combination because Perrone teaches a highly configurable GPROS framework in which robotics applications are developed, configured, assembled, deployed, distributed, and managed using configuration information and loadable code, while Leon teaches trained generative AI models that improve robot programming by generating action proposals, action parameters, and action sequences from task, environment, scene, and natural-language information. The combination would have predictably improved automation, reduced manual robotics programming burden, improved deployment efficiency, and increased configurability of robot and autonomous-vehicle applications by using Leon’s generative model to produce the GPROS artifacts that Perrone already teaches are used to configure, assemble, deploy, and operate GPROS-based applications.
Regarding Claim 5,
The combination of Perrone and Leon establishes the method of Claim 1, which is the basis for Claim 5.
Disclosure by Perrone
Perrone teaches:
wherein the loading the GPROS configuration data and the service extension files into the GPROS-based application comprises:
See at least: “Configuration data can be read or sent over a variety of network connections, and the code itself can be read or sent over a network, such that the initial code requires no additional customization. If multiple robots on a network include an embodiment, new configuration and code (and hence, behavior) can all be dynamically, and optionally simultaneously, loaded into any robot on the network.” (Perrone, [0010]) “In these embodiments, the software of an embodiment can be run alone or in conjunction with additional software applications, services extensions, modules, etc. (i.e., plug-ins), which may be created separately by a programmer.” (Perrone, [0028]) “By using some embodiments' services, robotics and automation applications inherit complete static and dynamic configurability, configurability using any underlying configuration medium, automateable assembly and construction based on configuration information, automateable deployment based on configuration information, configurable and distributable lifecycle management, configurable ability to plug-in any underlying distributed service communications approach...” (Perrone, [0106])
Rationale: Perrone expressly teaches loading configuration data and code into robots in the GPROS environment. Perrone also teaches service extensions, modules, and plug-ins that may be created separately by a programmer and used with the GPROS software. Perrone further teaches that GPROS-based robotics and automation applications are configured, assembled, deployed, distributed, and managed based on configuration information. Thus, Perrone teaches the general GPROS loading framework recited by the limitation, including loading GPROS configuration data and service-extension code artifacts into a GPROS-based application environment. The term “comprises:” is accounted for because Perrone’s loading and configuration framework allows additional implementation steps for collecting, storing, compiling, linking, and deploying the artifacts used by the GPROS-based application.
Claim Limitations Not Explicitly Disclosed by Perrone
Perrone does not explicitly teach the following claim limitations:
collecting the GPROS configuration data and the service extension files generated from the querying the GPROS-GPT model;
storing the GPROS configuration data and the service extension files into GPROS configuration folders; and
compiling and linking the service extension files into the GPROS-based application.
Disclosure by Leon
Leon renders obvious:
collecting the GPROS configuration data and the service extension files generated from the querying the GPROS-GPT model;
See at least: “At runtime, the action recommendation circuitry 202 performs action recommendations based on an encoded task and environment description, an initial action sequence (that can be empty) and a scene state representation from sensor data.” (Leon, [0042]) “The output of the action recommendation circuitry 202 is a sequence of actions. The output is transmitted to the parameter recommendation circuitry 204.” (Leon, [0042]) “The parameter recommendation circuitry 204 generates parameters of suggested actions.” (Leon, [0043]) “Encoded task and environment data may be expressed as a vector or word embedding. An example encoding method includes semantic lifting of natural language queries, parsing the query within the context of the industrial robot 104 of FIG. 1.” (Leon, [0049]) “Example 15 includes a method comprising generating, by executing an instruction with processor circuitry, at least one action proposal for an industrial robot, ranking, by executing an instruction with the processor circuitry, the at least one action proposal based on encoded scene information, generating, by executing an instruction with the processor circuitry, parameters for the at least one action proposal based on the encoded scene information, task data, and environment data, and generating, by executing an instruction with the processor circuitry, an action sequence based on the at least one action proposal.” (Leon, [0123]) “Example 16 includes the method of any of the previous examples, further including generating the at least one action proposal based on a first generative artificial intelligence model, and generating parameters for the at least one action proposal based on a second generative artificial intelligence model including the encoded scene information, the task data, and the environment data.” (Leon, [0124])
Rationale: Leon expressly teaches that natural language queries are parsed in the context of an industrial robot, and that a generative artificial intelligence system generates action proposals, action parameters, and action sequences from task, environment, and scene information. Leon further teaches that the output of the action recommendation circuitry is transmitted to downstream parameter recommendation circuitry. Thus, Leon expressly teaches generating robot-operation outputs in response to query or task inputs and passing those generated outputs for further use.
In the combination with Perrone, the generated outputs of Leon are adapted to Perrone’s GPROS framework so that the outputs are expressed as Perrone-compatible GPROS configuration data and service extension files. Collecting those generated artifacts would have been PHOSITA-obvious because generated configuration data and generated service-extension files must be received, retained, or otherwise made available before they can be loaded, stored, compiled, linked, or deployed in Perrone’s GPROS-based application framework. This is not treated as an express disclosure by Perrone alone. Rather, it is an obvious intermediate software handling step resulting from Leon’s generated robot-code recommendations being used as Perrone-compatible GPROS configuration and service-extension artifacts.
Obviousness in View of Perrone and Leon
The combination of Perrone and Leon renders obvious:
storing the GPROS configuration data and the service extension files into GPROS configuration folders;
See at least: “The Config service 540 extends the Any service 510 by providing specific calls and services that relate to retrieving and storing configuration data. Thus, configuration data may be stored in any type of underlying storage medium (e.g., file, XML, database, remote server, etc).” (Perrone, [0111]) “Configuration information may be stored in different underlying mediums 543 such as configuration files, XML documents, databases, statically in code (e.g., class files), or remote servers.” (Perrone, [0111]) “Thus, the conditions and their parameters, the conditional evaluation functions, the System, the association of System objects to other triggered System objects, and the arbitration of which System objects are executed can all be defined in configuration files or objects using the Config service described here.” (Perrone, [0135]) “A Conduct service such as Neural, implementing a neural network for example, can look at the logged information, state of the system, state of inputs, and create new configuration files with new parameters for the conditions to trigger which System objects.” (Perrone, [0136]) “The output of the action recommendation circuitry 202 is a sequence of actions. The output is transmitted to the parameter recommendation circuitry 204.” (Leon, [0042]) “Example 20 includes the method of any of the previous examples, wherein the task data and the encoded scene information include code from an augmented code database.” (Leon, [0128])
Rationale: Perrone expressly teaches storing GPROS configuration data using the Config service, including storage in files, XML documents, databases, code such as class files, or remote servers. Perrone also teaches that GPROS objects, parameters, behavior associations, and arbitration rules can be defined in configuration files or objects, and that machine learning may create new configuration files with new parameters for triggering system objects. Leon teaches generated robot-code recommendations and generated robot-operation outputs that are passed for downstream use.
Perrone and Leon do not expressly recite the exact words “GPROS configuration folders.” However, storing the generated GPROS configuration data and generated service extension files into GPROS configuration folders would have been PHOSITA-obvious because Perrone already teaches file-based GPROS configuration storage and code-based configuration storage, and Leon supplies generated code and robot-operation outputs to be used downstream. A folder is a conventional file system container for organizing related files. A PHOSITA implementing the Perrone-Leon combination would have had a reason to store generated GPROS configuration files and generated service-extension files in GPROS configuration folders to keep the generated files organized, discoverable by the Config service or build process, and available for later loading, assembly, deployment, and management. This is a predictable use of a known file-system organization technique to support Perrone’s express goals of automated configuration, assembly, construction, deployment, and development.
and compiling and linking the service extension files into the GPROS-based application.
See at least: “In these embodiments, the software of an embodiment can be run alone or in conjunction with additional software applications, services extensions, modules, etc. (i.e., plug-ins), which may be created separately by a programmer. The additional plug-ins can be any software in any language, and may specify a single function or action, or may specify multiple functions or actions.” (Perrone, [0028]) “Configuration data can be read or sent over a variety of network connections, and the code itself can be read or sent over a network, such that the initial code requires no additional customization. If multiple robots on a network include an embodiment, new configuration and code (and hence, behavior) can all be dynamically, and optionally simultaneously, loaded into any robot on the network.” (Perrone, [0010]) “It should thus be evident that an embodiment provides an operating system that provides individual services and the combination and interconnections of such services using built-in service extensions, built-in completely configurable generic services, and a way to plug in additional service extensions to yield a comprehensive and cohesive framework for developing, configuring, assembling, constructing, deploying, and managing robotics and/or automation applications.” (Perrone, [0311]) “An embodiment provides services that are common to any robotics or automation application, and encapsulates them separately, while providing them as a complete package to enable programmers to write programs in any language for any device or peripheral and plug those programs into the system to achieve a goal.” (Perrone, [0311]) “The disclosed systems, methods, apparatus, and articles of manufacture improve the efficiency of using a computing device by allowing programmers to describe described by the programmer (e.g., store this item). The example systems described herein increases robotics programmer productivity and reduces reliance on domain knowledge for robotics programming.” (Leon, [0106]) “Example 20 includes the method of any of the previous examples, wherein the task data and the encoded scene information include code from an augmented code database.” (Leon, [0128])
Rationale: Perrone expressly teaches service extensions, modules, and plug-ins that may be separately created by a programmer, may be any software in any language, and may specify one or more functions or actions. Perrone also teaches that new configuration and code may be dynamically loaded in the GPROS environment, and that additional service extensions may be plugged into the system to provide a framework for developing, configuring, assembling, constructing, deploying, and managing robotics applications. Leon teaches robot-code recommendations and code from an augmented code database.
Perrone and Leon do not expressly recite the exact phrase “compiling and linking.” However, compiling and linking the generated service extension files into the GPROS-based application would have been PHOSITA-obvious when the service extension files are generated as source-code or module-code artifacts. Compiling is the conventional software build operation that converts source code into executable or object code, and linking is the conventional build or integration operation that connects the compiled code with the application, framework, libraries, or extension interface needed for execution. A PHOSITA implementing Leon’s generated code recommendations as Perrone service extensions would have had a reason to compile and link the generated service extension files so that the generated extension code could be executed by, called by, or plugged into the GPROS-based application.
This conclusion does not rely merely on the existence of plug-ins in Perrone. Rather, the rationale is grounded in the combination: Leon supplies generated robot-code artifacts, Perrone supplies the GPROS service-extension and plug-in architecture, and compiling and linking are predictable software engineering techniques for integrating generated service-extension code into an executable or deployable GPROS-based application. Applying those known build steps would have yielded the predictable result of making the generated service-extension functionality available to the GPROS-based application for configuration, assembly, deployment, and operation.
Motivation to Combine Perrone and Leon
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Perrone and Leon before them, to modify Perrone’s GPROS configuration and service extension framework to use Leon’s generative AI robot code recommendation system to generate Perrone compatible GPROS configuration data and service extension files from task, environment, scene, and natural language query inputs, and to collect, store, compile, and link those generated files for use in a GPROS based application.
Perrone provides the GPROS framework for loading configuration data and code, using service extensions and plug-ins, and configuring, assembling, deploying, and managing robotics applications. Leon provides a generative AI system that generates robot action proposals, parameters, and action sequences from task, environment, scene, and natural language inputs. Thus, Leon’s generated robot operation outputs would have been a predictable source of the configuration data and service extension artifacts used by Perrone’s GPROS framework.
A PHOSITA would have been motivated to combine the references because the combination would have improved the efficiency and automation of robotics application development. Perrone seeks configurable and automated assembly and deployment of robotics applications, while Leon reduces manual robot programming by generating robot code recommendations from high level inputs. Using Leon’s generative system to create Perrone-compatible GPROS configuration data and service extension files would have predictably reduced manual coding, improved configuration efficiency, and accelerated deployment of GPROS-based robotics applications.
The additional steps of collecting, storing, compiling, and linking the generated files would have been routine and predictable implementation steps. Once Leon generates the robot operation outputs for use in Perrone’s GPROS environment, the generated files must be made available, organized, built, and integrated before the GPROS-based application can use them. Storing the files in GPROS configuration folders would have predictably organized the configuration and service extension files for later loading and deployment. Compiling and linking the service extension files would have predictably made the generated extension code executable by, callable by, or pluggable into the GPROS-based application.
The combination would not have changed the basic operation of either reference. Perrone would still provide the GPROS configuration, loading, service extension, and deployment framework, while Leon would provide the generative robot code recommendation mechanism. The result would have been the predictable use of known software generation, storage, build, and integration techniques to configure and extend a GPROS-based application using generated GPROS configuration data and generated service extension files.
Regarding Claim 6,
The combination of Perrone and Leon establishes the method of Claim 5, which is the basis for Claim 6.
Disclosure by Perrone
Perrone teaches:
wherein the compiling and linking the service extension files comprises:
See at least: “Configuration data can be read or sent over a variety of network connections, and the code itself can be read or sent over a network, such that the initial code requires no additional customization. If multiple robots on a network include an embodiment, new configuration and code (and hence, behavior) can all be dynamically, and optionally simultaneously, loaded into any robot on the network.” (Perrone, [0010]) “In these embodiments, the software of an embodiment can be run alone or in conjunction with additional software applications, services extensions, modules, etc. (i.e., plug-ins), which may be created separately by a programmer.” (Perrone, [0028]) “By using some embodiments’ services, robotics and automation applications inherit complete static and dynamic configurability, configurability using any underlying configuration medium, automateable assembly and construction based on configuration information, automateable deployment based on configuration information...” (Perrone, [0106])
Rationale: Perrone expressly teaches a GPROS framework that supports service extensions, modules, and plug-ins created separately by a programmer, along with dynamic loading of new configuration and code. Perrone also teaches that GPROS-based applications support dynamic configurability, automated assembly, and automated deployment. Thus, Perrone provides the dynamic GPROS service extension framework in which the compilation and linking steps occur.
Claim Limitations Not Explicitly Disclosed by Perrone
Perrone does not explicitly teach the following claim limitation:
dynamically compiling and linking the service extension files.
Obviousness of the Remaining Limitation in View of Perrone and Leon
The combination of Perrone and Leon renders obvious:
dynamically compiling and linking the service extension files.
See at least: “Configuration data can be read or sent over a variety of network connections, and the code itself can be read or sent over a network, such that the initial code requires no additional customization. If multiple robots on a network include an embodiment, new configuration and code (and hence, behavior) can all be dynamically, and optionally simultaneously, loaded into any robot on the network.” (Perrone, [0010]) “In these embodiments, the software of an embodiment can be run alone or in conjunction with additional software applications, services extensions, modules, etc. (i.e., plug-ins), which may be created separately by a programmer.” (Perrone, [0028]) “At runtime, the action recommendation circuitry 202 performs action recommendations based on an encoded task and environment description, an initial action sequence (that can be empty) and a scene state representation from sensor data.” (Leon, [0042]) “The output of the action recommendation circuitry 202 is a sequence of actions. The output is transmitted to the parameter recommendation circuitry 204.” (Leon, [0042]) “Example 20 includes the method of any of the previous examples, wherein the task data and the encoded scene information include code from an augmented code database.” (Leon, [0128])
Rationale: Perrone teaches a dynamically configurable GPROS framework that supports dynamic loading of new configuration and code, as well as the use of separately created service extensions and plug-ins. Leon teaches runtime generation of robot action recommendations, parameters, and action sequences, along with the use of code from an augmented code database. In the combination that establishes Claim 5, Leon’s generated outputs are adapted into Perrone-compatible GPROS configuration data and service extension files.
A PHOSITA would have had a reason to dynamically compile and link the generated service extension files so that newly generated or updated extension functionality could be integrated into the GPROS-based application without requiring a full static rebuild. Dynamic compiling and linking is a predictable software engineering technique for integrating source or module code into a running application or framework. Applying this technique would have predictably allowed Leon-generated service extension files to become immediately usable within Perrone’s dynamically configurable GPROS platform.
Motivation to Combine Perrone and Leon
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Perrone and Leon before them, to modify the Perrone and Leon combination of Claim 5 so that service extension files generated for Perrone’s GPROS-based application are dynamically compiled and linked when generated or updated by Leon’s robot code recommendation system.
Perrone provides a dynamically configurable GPROS framework that supports dynamic loading of configuration and code, service extensions, and automated deployment. Leon provides runtime generation of robot operation outputs and code recommendations. These teachings are technically compatible because both references address software-based configuration and control of robots. A PHOSITA would have been motivated to use dynamic compiling and linking because it would have allowed newly generated service extension files to be built and integrated when needed, rather than requiring a static rebuild. This would have predictably improved automation, reduced manual effort, and increased deployment speed while supporting Perrone’s goal of dynamic and extensible robotics application development.
Regarding Claim 7,
The combination of Perrone and Leon establishes the method of Claim 1, which is the basis for Claim 7.
Disclosure by Perrone
Perrone teaches:
wherein the using the GPROS-based application to operate the GPROS-based robot or the GPROS-based autonomous vehicle comprises:
See at least: “The RobotGeneric 703 is a completely configurable abstraction that can be used to model any type of robot. Sensors 711, Conduct, and Actuators 721 are associated with a robot in a configurable fashion.” (Perrone, [0203]) “Upon construction using the Config 540 and Registry service, the robot may be commanded according to its lifecycle to live, wake, sleep, and die.” (Perrone, [0203]) “Thus, GPROS applies to and is used as an unmanned ground vehicle operating system and autonomous vehicle operating system.” (Perrone, [0205]) “As can be seen, by configuring the various application services of GPROS, a fully autonomous or automated vehicle, otherwise referred to as a driverless car or self-driving car, can be realized.” (Perrone, [0305])
Rationale: Perrone expressly teaches using a GPROS-based application to operate configurable robots and autonomous vehicles. Perrone teaches a RobotGeneric abstraction with configurable sensors, conduct, and actuators that can be commanded through its lifecycle, and that GPROS can be configured to operate as an autonomous vehicle operating system.
launching the GPROS-based application to use the configuration data and the service extension files.
See at least: “An embodiment in aspects also defines a method by which configuration data may be loaded, transparent to the application, from one or more configuration data sources in both a static fashion (i.e., at application startup) or dynamically (i.e., as the application is running).” (Perrone, [0006]) “The configuration services are used in conjunction with an object registration service to automatically create, configure, assemble, deploy, launch, and manage any application objects defined in the configuration.” (Perrone, [0023]) “In these embodiments, the software of an embodiment can be run alone or in conjunction with additional software applications, services extensions, modules, etc. (i.e., plug-ins), which may be created separately by a programmer.” (Perrone, [0028])
Rationale: Perrone expressly teaches loading configuration data (statically or dynamically) and using service extensions and plug-ins with GPROS software. Perrone further teaches that configuration services are used to automatically create, configure, assemble, deploy, launch, and manage application objects. Thus, Perrone teaches launching a GPROS-based application to use configuration data and service extension files.
Claim Limitations Not Explicitly Disclosed by Perrone
Perrone does not explicitly teach the following claim limitation:
placing the GPROS-based robot or the GPROS-based autonomous vehicle in a zone of operation;
Obviousness of the Remaining Limitation in View of Perrone and Leon
The combination of Perrone and Leon renders obvious:
placing the GPROS-based robot or the GPROS-based autonomous vehicle in a zone of operation;
See at least: “The RobotGeneric 703 is a completely configurable abstraction that can be used to model any type of robot. Sensors 711, Conduct, and Actuators 721 are associated with a robot in a configurable fashion.” (Perrone, [0203]) “Upon construction using the Config 540 and Registry service, the robot may be commanded according to its lifecycle to live, wake, sleep, and die.” (Perrone, [0203]) “Thus, GPROS applies to and is used as an unmanned ground vehicle operating system and autonomous vehicle operating system.” (Perrone, [0205])
Rationale: Perrone teaches operating GPROS-based robots and autonomous vehicles through configuration-driven behavior and lifecycle commands. Placing a robot or autonomous vehicle in a defined zone of operation prior to launching and operating it is a conventional and predictable operational step when using a robotics operating system in a real-world environment. A PHOSITA would have found it obvious to place the GPROS-based robot or autonomous vehicle in a zone of operation as part of using Perrone’s GPROS framework to operate the robot or vehicle.
Motivation to Combine Perrone and Leon
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Perrone and Leon before them, to modify Perrone’s GPROS framework by incorporating Leon’s trained generative AI model as the GPROS-GPT model so that the GPROS-based application can be launched with configuration data and service extension files generated by the GPROS-GPT model to operate a GPROS-based robot or autonomous vehicle placed in a zone of operation.
Perrone provides a configurable GPROS platform for operating robots and autonomous vehicles using configuration data, service extensions, and lifecycle commands. Leon provides a generative AI system that produces robot operation outputs and code recommendations. A PHOSITA would have been motivated to make this combination because Perrone seeks automated configuration, deployment, and operation of robotics applications, while Leon automates the generation of the artifacts used to configure and operate those applications. The combination would have predictably allowed a GPROS-based robot or autonomous vehicle to be placed in a zone of operation and operated using configuration data and service extension files generated by the GPROS-GPT model.
Regarding Claim 8,
Disclosure by Perrone
Perrone discloses:
A non-transitory computer-readable medium storing instructions that, when executed by a processor, cause the processor to perform operations, comprising:
See at least: “Computer system 6900 may include one or more processors (also called central processing units, or CPUs), such as a processor 6904.” (Perrone, [0314]) “Main memory 6908 may have stored therein control logic (i.e., computer software) and/or data.” (Perrone, [0317]) “In some embodiments, a tangible, non-transitory apparatus or article of manufacture comprising a tangible, non-transitory computer useable or readable medium having control logic (software) stored thereon may also be referred to herein as a computer program product or program storage device.” (Perrone, [0325]) “Such control logic, when executed by one or more data processing devices (such as computer system 6900), may cause such data processing devices to operate as described herein.” (Perrone, [0325])
Rationale: Perrone discloses a processor-based computer system with memory storing control logic (software) on a tangible, non-transitory computer-readable medium. Perrone further discloses that the stored control logic, when executed by the processor, causes the system to perform the described GPROS operations. Thus, Perrone discloses the claimed non-transitory computer-readable medium storing processor-executable instructions.
loading the GPROS configuration data and the service extension files into a GPROS-based application; and
See at least: “An embodiment in aspects also defines a method by which configuration data may be loaded, transparent to the application, from one or more configuration data sources in both a static fashion (i.e., at application startup) or dynamically (i.e., as the application is running).” (Perrone, [0006]) “Configuration data can be read or sent over a variety of network connections, and the code itself can be read or sent over a network, such that the initial code requires no additional customization. If multiple robots on a network include an embodiment, new configuration and code (and hence, behavior) can all be dynamically, and optionally simultaneously, loaded into any robot on the network.” (Perrone, [0010]) “In these embodiments, the software of an embodiment can be run alone or in conjunction with additional software applications, services extensions, modules, etc. (i.e., plug-ins), which may be created separately by a programmer.” (Perrone, [0028])
Rationale: Perrone discloses loading configuration data and code (including service extensions, modules, and plug-ins created separately by a programmer) into GPROS-based applications, either statically or dynamically. Thus, Perrone discloses loading the GPROS configuration data and service extension files into a GPROS-based application.
using the GPROS-based application to operate a GPROS-based robot or a GPROS-based autonomous vehicle.
See at least: “The RobotGeneric 703 is a completely configurable abstraction that can be used to model any type of robot. Sensors 711, Conduct, and Actuators 721 are associated with a robot in a configurable fashion.” (Perrone, [0203]) “Upon construction using the Config 540 and Registry service, the robot may be commanded according to its lifecycle to live, wake, sleep, and die.” (Perrone, [0203]) “Thus, GPROS applies to and is used as an unmanned ground vehicle operating system and autonomous vehicle operating system.” (Perrone, [0205]) “As can be seen, by configuring the various application services of GPROS, a fully autonomous or automated vehicle, otherwise referred to as a driverless car or self-driving car, can be realized.” (Perrone, [0305])
Rationale: Perrone discloses using a GPROS-based application to operate configurable robots and autonomous vehicles. Perrone teaches a RobotGeneric abstraction with configurable sensors, conduct, and actuators that can be commanded through its lifecycle, and that GPROS can be configured to operate as an autonomous vehicle operating system.
Claim Limitations Not Explicitly Disclosed by Perrone
Perrone does not explicitly disclose the following claim limitations:
training a general-purpose robotics operating system (GPROS) with generative pre-trained transformers (GPT) (GPROS-GPT) model;
querying the GPROS-GPT model to generate GPROS configuration data and service extension files;
Disclosure by Leon
Leon renders obvious:
training a general-purpose robotics operating system (GPROS) with generative pre-trained transformers (GPT) (GPROS-GPT) model;
See at least: “The action recommendation circuitry 202 includes a generative artificial intelligence (AI) model that proposes actions based on representations of the task, environment, and scene.” (Leon, [0038]) “The example action recommendation circuitry 202 is trained, in part, on augmented code stored in the augmented code database 216.” (Leon, [0038]) “FIG. 5 is a flowchart representative of example machine readable instructions and/or example operations 500 that may be executed and/or instantiated by processor circuitry to implement industrial robot code recommendations. The machine readable instructions and/or operations 500 of FIG. 5 begin at block 502, at which the code recommendation circuitry 102 of FIGS. 1-4 is trained.” (Leon, [0068]) “Output features from the 2D CNN and 3D CNN networks may be provided to a recurrent neural network (RNN) model such as a long short-term memory (LSTM) or a transformer model that preserves the temporal aspects of action sequences in description processing.” (Leon, [0048])
Rationale: Leon discloses training generative AI models for robot code and action recommendation and discloses the use of a transformer model for processing action sequence information. In the proposed combination, Leon’s trained generative model is implemented as a GPT-style generative pre-trained transformer adapted to Perrone’s GPROS framework (GPROS-GPT). This is a predictable use of a known generative transformer architecture within Perrone’s GPROS environment.
querying the GPROS-GPT model to generate GPROS configuration data and service extension files;
See at least: “At runtime, the action recommendation circuitry 202 performs action recommendations based on an encoded task and environment description, an initial action sequence (that can be empty) and a scene state representation from sensor data.” (Leon, [0042]) “The action recommendation circuitry 202 includes a generative artificial intelligence (AI) model that proposes actions based on representations of the task, environment, and scene.” (Leon, [0038]) “The parameter recommendation circuitry 204 generates parameters of suggested actions.” (Leon, [0043])
Rationale: Leon discloses a generative AI model that, when queried at runtime with task and environment data, generates action proposals, parameters, and sequences. In the proposed combination, Leon’s generative model is adapted as the GPROS-GPT model to produce outputs expressed as Perrone-compatible GPROS configuration data and service extension files. This is a predictable adaptation of Leon’s generative outputs to Perrone’s GPROS framework.
Motivation to Combine Perrone and Leon
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Perrone and Leon before them, to modify Perrone’s processor-executed GPROS configuration, service-extension, and robotics-application framework by incorporating Leon’s trained generative AI robot-code recommendation system, implemented as a GPT-style transformer model, so that task, environment, scene, or natural-language queries generate Perrone-compatible GPROS configuration data and service extension files for loading into and using a GPROS-based robot or autonomous-vehicle application.
Perrone and Leon are technically compatible because both address software-based robot programming and control. Perrone provides the GPROS framework, including processor-executed software, configuration data, service extensions, plug-ins, dynamic loading, and GPROS-based robot or autonomous-vehicle operation. Leon provides trained generative AI models that generate robot action proposals, parameters, action sequences, and code-related outputs from task, environment, scene, and natural-language inputs.
A PHOSITA would have been motivated to combine the references because Perrone seeks automated configuration, assembly, deployment, and development of robotics applications, while Leon provides a generative robot-code recommendation mechanism that reduces manual robot programming by generating robot-operation outputs from high-level inputs. Using Leon’s generative model to create Perrone-compatible GPROS configuration data and service extension files would have predictably reduced manual coding, improved configuration efficiency, and accelerated development and deployment of GPROS-based robot and autonomous-vehicle applications.
Regarding Claim 12,
The combination of Perrone and Leon establishes the non-transitory computer-readable medium of Claim 8, which is the basis for Claim 12.
Disclosure by Perrone
Perrone discloses the GPROS loading framework relevant to Claim 12:
wherein the loading the GPROS configuration data and the service extension files into the GPROS-based application comprises:
See at least: “An embodiment in aspects also defines a method by which configuration data may be loaded, transparent to the application, from one or more configuration data sources in both a static fashion (i.e., at application startup) or dynamically (i.e., as the application is running).” (Perrone, [0006]) “Configuration data can be read or sent over a variety of network connections, and the code itself can be read or sent over a network, such that the initial code requires no additional customization. If multiple robots on a network include an embodiment, new configuration and code (and hence, behavior) can all be dynamically, and optionally simultaneously, loaded into any robot on the network.” (Perrone, [0010]) “In these embodiments, the software of an embodiment can be run alone or in conjunction with additional software applications, services extensions, modules, etc. (i.e., plug-ins), which may be created separately by a programmer.” (Perrone, [0028])
Rationale: Perrone expressly discloses loading configuration data from configuration data sources, dynamically loading new configuration and code, and using service extensions, modules, and plug-ins with GPROS software. Perrone therefore provides the GPROS loading framework in which the claimed collecting, storing, compiling, and linking sub-steps would be implemented. Perrone is not relied upon as expressly disclosing each sub-step of Claim 12.
Claim Limitations Not Explicitly Disclosed by Perrone
Perrone does not explicitly disclose the following additional claim limitations: collecting the GPROS configuration data and the service extension files generated from the querying the GPROS-GPT model; storing the GPROS configuration data and the service extension files into GPROS configuration folders; and compiling and linking the service extension files into the GPROS-based application.
Obviousness of the Remaining Limitations in View of Perrone and Leon
The combination of Perrone and Leon renders obvious:
collecting the GPROS configuration data and the service extension files generated from the querying the GPROS-GPT model;
See at least: “At runtime, the action recommendation circuitry 202 performs action recommendations based on an encoded task and environment description, an initial action sequence (that can be empty) and a scene state representation from sensor data.” (Leon, [0042]) “The output of the action recommendation circuitry 202 is a sequence of actions. The output is transmitted to the parameter recommendation circuitry 204.” (Leon, [0042]) “The parameter recommendation circuitry 204 generates parameters of suggested actions.” (Leon, [0043]) “Encoded task and environment data may be expressed as a vector or word embedding. An example encoding method includes semantic lifting of natural language queries, parsing the query within the context of the industrial robot 104 of FIG. 1.” (Leon, [0049])
Rationale: Neither Perrone nor Leon is relied upon as expressly reciting the exact collecting step. Leon teaches that runtime robot-operation outputs are generated from encoded task/environment inputs and natural-language queries and transmitted for downstream use. In the Perrone-Leon combination, those generated outputs are expressed as Perrone-compatible GPROS configuration data and service extension files. Collecting the generated GPROS configuration data and service extension files would have been an ordinary and predictable software-handling step because the generated artifacts must be received, gathered, or otherwise made available before they can be stored, compiled, linked, loaded, or used by the GPROS-based application.
storing the GPROS configuration data and the service extension files into GPROS configuration folders; and
See at least: “The Config service 540 extends the Any service 510 by providing specific calls and services that relate to retrieving and storing configuration data. Thus, configuration data may be stored in any type of underlying storage medium (e.g., file, XML, database, remote server, etc).” (Perrone, [0111]) “Configuration information may be stored in different underlying mediums 543 such as configuration files, XML documents, databases, statically in code (e.g., class files), or remote servers.” (Perrone, [0111]) “Thus, the conditions and their parameters, the conditional evaluation functions, the System, the association of System objects to other triggered System objects, and the arbitration of which System objects are executed can all be defined in configuration files or objects using the Config service described here.” (Perrone, [0135]) “A Conduct service such as Neural, implementing a neural network for example, can look at the logged information, state of the system, state of inputs, and create new configuration files with new parameters for the conditions to trigger which System objects.” (Perrone, [0136])
Rationale: Perrone teaches storing configuration data in files, XML documents, databases, code such as class files, or remote servers, and further teaches configuration files that define GPROS behavior. Perrone and Leon do not expressly recite “GPROS configuration folders.” However, using folders to store generated GPROS configuration files and service-extension files would have been a routine and predictable file-system organization technique. A PHOSITA would have had a reason to store the generated files in GPROS configuration folders so the related configuration and extension artifacts could be organized, located, loaded, built, deployed, and managed by the GPROS application framework.
compiling and linking the service extension files into the GPROS-based application.
See at least: “In these embodiments, the software of an embodiment can be run alone or in conjunction with additional software applications, services extensions, modules, etc. (i.e., plug-ins), which may be created separately by a programmer.” (Perrone, [0028]) “It should thus be evident that an embodiment provides an operating system that provides individual services and the combination and interconnections of such services using built-in service extensions, built-in completely configurable generic services, and a way to plug in additional service extensions to yield a comprehensive and cohesive framework for developing, configuring, assembling, constructing, deploying, and managing robotics and/or automation applications.” (Perrone, [0311]) “Example 20 includes the method of any of the previous examples, wherein the task data and the encoded scene information include code from an augmented code database.” (Leon, [0128])
Rationale: Perrone teaches service extensions, modules, and plug-ins that may be separately created and plugged into the GPROS software framework. Leon teaches code from an augmented code database in the robot-code recommendation context. In the combination, generated service extension files are software artifacts used to extend Perrone’s GPROS-based application. Compiling and linking such files would have been a predictable software build and integration step because source-code or module-code extension files must be made executable, callable, or otherwise integrated with the application, runtime, libraries, or plug-in interface before use by the GPROS-based application.
Motivation to Combine Perrone and Leon for Claim 12
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Perrone and Leon before them, to modify Perrone’s GPROS configuration and service-extension framework so that Perrone-compatible GPROS configuration data and service extension files generated using Leon’s generative robot-code recommendation system are collected, stored in organized GPROS configuration folders, and compiled and linked into the GPROS-based application.
Perrone provides the GPROS framework for configuration data, service extensions, plug-ins, loading, assembly, deployment, and operation of robotics applications. Leon provides generated robot-operation outputs based on task, environment, scene, and natural-language inputs. A PHOSITA would have combined these teachings to automate the creation and handling of the configuration and extension artifacts used by Perrone’s GPROS framework, thereby reducing manual programming, improving configuration efficiency, and accelerating deployment.
Claim Limitations Not Explicitly Disclosed by the Combination of All References
After combining the teachings of Perrone and Leon, all limitations of Claim 12 are disclosed or rendered obvious.
Regarding Claim 13,
The combination of Perrone and Leon establishes the non-transitory computer-readable medium of Claim 12, which is the basis for Claim 13.
Claim Limitations Not Explicitly Disclosed by Perrone
Perrone does not explicitly disclose the following additional claim limitation: wherein the compiling and linking the service extension files comprises dynamically compiling and linking the service extension files.
Obviousness of the Remaining Limitation in View of Perrone and Leon
The combination of Perrone and Leon renders obvious:
wherein the compiling and linking the service extension files comprises dynamically compiling and linking the service extension files.
See at least: “Configuration data can be read or sent over a variety of network connections, and the code itself can be read or sent over a network, such that the initial code requires no additional customization. If multiple robots on a network include an embodiment, new configuration and code (and hence, behavior) can all be dynamically, and optionally simultaneously, loaded into any robot on the network.” (Perrone, [0010]) “In these embodiments, the software of an embodiment can be run alone or in conjunction with additional software applications, services extensions, modules, etc. (i.e., plug-ins), which may be created separately by a programmer.” (Perrone, [0028]) “By using some embodiments’ services, robotics and automation applications inherit complete static and dynamic configurability, configurability using any underlying configuration medium, automateable assembly and construction based on configuration information, automateable deployment based on configuration information...” (Perrone, [0106]) “At runtime, the action recommendation circuitry 202 performs action recommendations based on an encoded task and environment description, an initial action sequence (that can be empty) and a scene state representation from sensor data.” (Leon, [0042])
Rationale: Perrone does not expressly recite “dynamically compiling and linking,” and Leon does not independently teach that exact phrase. However, Perrone teaches dynamic loading of new configuration and code, dynamic configurability, and separately created service extensions and plug-ins. Leon teaches runtime generation of robot-operation outputs. In the Claim 12 combination, Leon’s generated service extension files are used in Perrone’s dynamically configurable GPROS framework. A PHOSITA would have found it obvious to dynamically compile and link the generated or updated service extension files so that newly generated extension functionality could be integrated into the GPROS-based application when needed, without requiring a static rebuild each time the generated files changed. This is a predictable software implementation technique that supports Perrone’s dynamic loading and configurable robotics application framework.
Motivation to Combine Perrone and Leon for Claim 13
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Perrone and Leon before them, to modify the Perrone-Leon combination of Claim 12 so that the service extension files generated for use in Perrone’s GPROS-based application are dynamically compiled and linked when generated or updated.
A PHOSITA would have had a reason to do so because the combined system generates service extension files for a dynamically configurable robotics application. Dynamic compiling and linking would have allowed newly generated or updated service-extension code to be built and integrated when needed, improving automation, reducing manual build effort, increasing deployment speed, and supporting Perrone’s dynamic configuration and dynamic loading framework.
Claim Limitations Not Explicitly Disclosed by the Combination of All References
After combining the teachings of Perrone and Leon, all limitations of Claim 13 are disclosed or rendered obvious.
Regarding Claim 14,
The combination of Perrone and Leon establishes the non-transitory computer-readable medium of Claim 8, which is the basis for Claim 14.
Disclosure by Perrone
Perrone discloses:
wherein the using the GPROS-based application to operate the GPROS-based robot or the GPROS-based autonomous vehicle comprises:
See at least: “By using some embodiments’ services, robotics and automation applications inherit complete static and dynamic configurability, configurability using any underlying configuration medium, automateable assembly and construction based on configuration information, automateable deployment based on configuration information...” (Perrone, [0106]) “The RobotGeneric 703 is a completely configurable abstraction that can be used to model any type of robot. Sensors 711, Conduct, and Actuators 721 are associated with a robot in a configurable fashion.” (Perrone, [0203]) “As can be seen, by configuring the various application services of GPROS, a fully autonomous or automated vehicle, otherwise referred to as a driverless car or self-driving car, can be realized.” (Perrone, [0305])
Rationale: Perrone discloses using GPROS services to configure, assemble, deploy, and manage robotics applications. Perrone also discloses a configurable robot abstraction and teaches that configuring GPROS application services can realize a fully autonomous vehicle. Thus, Perrone discloses the operational GPROS framework corresponding to the claimed use of the GPROS-based application.
launching the GPROS-based application to use the GPROS configuration data and the service extension files.
See at least: “The configuration services are used in conjunction with an object registration service to automatically create, configure, assemble, deploy, launch, and manage any application objects defined in the configuration.” (Perrone, [0023]) “Configuration data can be read or sent over a variety of network connections, and the code itself can be read or sent over a network, such that the initial code requires no additional customization. If multiple robots on a network include an embodiment, new configuration and code (and hence, behavior) can all be dynamically, and optionally simultaneously, loaded into any robot on the network.” (Perrone, [0010]) “In these embodiments, the software of an embodiment can be run alone or in conjunction with additional software applications, services extensions, modules, etc. (i.e., plug-ins), which may be created separately by a programmer.” (Perrone, [0028]) “FIG. 34 illustrates how the registry service is used to launch generic robotics applications.” (Perrone, [0249]) “The System 1200 initiates the Object Launcher 1201, and after the initial loading of the program, an object handle is obtained from the ObjectRegistry 1202 given its launcher ID.” (Perrone, [0249])
Rationale: Perrone expressly teaches launching application objects defined in configuration and launching generic robotics applications using a registry service. Perrone also teaches that configuration data and code may be loaded and that GPROS software may run with service extensions, modules, and plug-ins. Therefore, Perrone teaches launching the GPROS-based application to use GPROS configuration data and service-extension code artifacts. In the Perrone-Leon combination, the GPROS configuration data and service extension files are the generated Perrone-compatible artifacts supplied by the GPROS-GPT model.
Claim Limitations Not Explicitly Disclosed by Perrone
Perrone does not explicitly disclose the following additional claim limitation: placing the GPROS-based robot or the GPROS-based autonomous vehicle in a zone of operation; and
Obviousness of the Remaining Limitation in View of Perrone and Leon
The combination of Perrone and Leon renders obvious:
placing the GPROS-based robot or the GPROS-based autonomous vehicle in a zone of operation; and
See at least: “A RouteSegment 793 encapsulates a linear route from one waypoint to another waypoint, and attributes about that route such as a collection of features, direction, route segment speed, and length.” (Perrone, [0194]) “A TrackSegment 794 defines boundaries within which a robot may travel over a route segment. A Course 791 is a type of Route 792 which defines the TrackSegments 794 over which a robot may or should travel.” (Perrone, [0194]) “The RouteNetwork is essentially a map with the various course features that may be identifiable on a map.” (Perrone, [0196]) “At runtime, the action recommendation circuitry 202 performs action recommendations based on an encoded task and environment description, an initial action sequence (that can be empty) and a scene state representation from sensor data.” (Leon, [0042])
Rationale: Perrone does not expressly recite placing the robot or autonomous vehicle in a zone of operation. However, Perrone teaches route segments, track segments, course boundaries, route networks, and maps that define where a robot may or should travel. Leon teaches runtime robot-operation outputs based on task, environment, and scene information. In the combined system, the robot or autonomous vehicle operates according to configured route, course, environment, and behavior information. A PHOSITA would have found it obvious to place or deploy the GPROS-based robot or autonomous vehicle in the intended operating area before launching operation because the configured route, course, map, environment, and behavior information are meaningful only when the robot or vehicle is in the corresponding operating zone. This is a routine and predictable deployment step for a mobile robot or autonomous vehicle.
Motivation to Combine Perrone and Leon for Claim 14
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Perrone and Leon before them, to modify Perrone’s GPROS robotics application framework so that GPROS-compatible configuration data and service extension files generated using Leon’s robot-code recommendation system are used when the GPROS-based application is launched to operate a robot or autonomous vehicle in its intended zone of operation.
A PHOSITA would have been motivated to make the combination because Perrone provides the GPROS launch, configuration, routing, and operation framework, while Leon provides generated robot-operation outputs based on task, environment, scene, and query inputs. The combination would predictably reduce manual programming, improve configuration efficiency, and allow the launched GPROS-based application to operate the robot or autonomous vehicle according to the generated configuration and extension artifacts in the intended operating area.
Claim Limitations Not Explicitly Disclosed by the Combination of All References
After combining the teachings of Perrone and Leon, all limitations of Claim 14 are disclosed or rendered obvious.
Regarding Claim 15,
Disclosure by Perrone
Perrone discloses:
A computing system comprising: one or more memories; and at least one processor each coupled to at least one of the one or more memories, wherein the at least one processor is configured to:
See at least: “Various embodiments may be implemented, for example, using one or more well-known computer systems, such as computer system 6900 shown in FIG. 69.” (Perrone, [0313]) “Computer system 6900 may include one or more processors (also called central processing units, or CPUs), such as a processor 6904. Processor 6904 may be connected to a communication infrastructure or bus 6906.” (Perrone, [0314]) “Computer system 6900 may also include a main or primary memory 6908, such as random access memory (RAM). Main memory 6908 may include one or more levels of cache. Main memory 6908 may have stored therein control logic (i.e., computer software) and/or data.” (Perrone, [0317]) “Computer system 6900 may also include one or more secondary storage devices or memory 6910.” (Perrone, [0318]) “Such control logic, when executed by one or more data processing devices (such as computer system 6900), may cause such data processing devices to operate as described herein.” (Perrone, [0325])
Rationale: Perrone expressly discloses a computing system including one or more processors and one or more memories. Perrone further teaches that the processor is connected to a communication infrastructure or bus and that the computer system includes main memory and secondary memory. A PHOSITA would have understood the processor to be coupled to at least one memory through the disclosed computer-system bus or communication infrastructure so that the processor can execute stored control logic/software. Perrone also teaches that the stored control logic, when executed, causes the data processing device to operate according to the disclosed GPROS embodiments. Thus, Perrone discloses the claimed computing-system structure and the “wherein the at least one processor is configured to” framework.
load the GPROS configuration data and the service extension files into a GPROS-based application; and
See at least: “An embodiment in aspects also defines a method by which configuration data may be loaded, transparent to the application, from one or more configuration data sources in both a static fashion (i.e., at application startup) or dynamically (i.e., as the application is running).” (Perrone, [0006]) “Configuration data can be read or sent over a variety of network connections, and the code itself can be read or sent over a network, such that the initial code requires no additional customization. If multiple robots on a network include an embodiment, new configuration and code (and hence, behavior) can all be dynamically, and optionally simultaneously, loaded into any robot on the network.” (Perrone, [0010]) “In these embodiments, the software of an embodiment can be run alone or in conjunction with additional software applications, services extensions, modules, etc. (i.e., plug-ins), which may be created separately by a programmer.” (Perrone, [0028]) “GPROS, as depicted in FIG. 1, allows for specific robotics applications 130 to be created. For example, an autonomous unmanned ground vehicle (UGV) application for traversing a long distance within a route corridor while avoiding obstacles may be built on the GPROS, leveraging common robotics software services.” (Perrone, [0101])
Rationale: Perrone discloses processor-executed GPROS software that loads configuration data, dynamically loads new configuration and code, and uses service extensions, modules, and plug-ins. Perrone also discloses specific robotics applications built on GPROS. Therefore, Perrone discloses loading GPROS configuration data and service-extension code artifacts into a GPROS-based application.
use the GPROS-based application to operate a GPROS-based robot or a GPROS-based autonomous vehicle.
See at least: “The RobotGeneric 703 is a completely configurable abstraction that can be used to model any type of robot. Sensors 711, Conduct, and Actuators 721 are associated with a robot in a configurable fashion.” (Perrone, [0203]) “Upon construction using the Config 540 and Registry service, the robot may be commanded according to its lifecycle to live, wake, sleep, and die.” (Perrone, [0203]) “Thus, GPROS applies to and is used as an unmanned ground vehicle operating system and autonomous vehicle operating system.” (Perrone, [0205]) “As can be seen, by configuring the various application services of GPROS, a fully autonomous or automated vehicle, otherwise referred to as a driverless car or self-driving car, can be realized.” (Perrone, [0305])
Rationale: Perrone discloses using GPROS to model and command a configurable robot having sensors, conduct, and actuators. Perrone also discloses that GPROS is used as an autonomous vehicle operating system and that configuring GPROS application services can realize a fully autonomous vehicle. Thus, Perrone discloses using the GPROS-based application to operate a GPROS-based robot or an autonomous GPROS-based vehicle.
Claim Limitations Not Explicitly Disclosed by Perrone
Perrone does not explicitly disclose the following claim limitations of independent Claim 15:
train a general-purpose robotics operating system (GPROS) with generative pre-trained transformers (GPT) (GPROS-GPT) model; query the GPROS-GPT model to generate GPROS configuration data and service extension files;
Obviousness of the Remaining Limitations in View of Perrone and Leon
The combination of Perrone and Leon renders obvious:
train a general-purpose robotics operating system (GPROS) with generative pre-trained transformers (GPT) (GPROS-GPT) model;
See at least: “The action recommendation circuitry 202 includes a generative artificial intelligence (AI) model that proposes actions based on representations of the task, environment, and scene.” (Leon, [0038]) “The example action recommendation circuitry 202 is trained, in part, on augmented code stored in the augmented code database 216.” (Leon, [0038]) “In some examples, the generative model architecture is capable of generating multiple outputs for a single input.” (Leon, [0040]) “Output features from the 2D CNN and 3D CNN networks may be provided to a recurrent neural network (RNN) model such as a long short-term memory (LSTM) or a transformer model that preserves the temporal aspects of action sequences in description processing.” (Leon, [0048]) “FIG. 5 is a flowchart representative of example machine readable instructions and/or example operations 500 that may be executed and/or instantiated by processor circuitry to implement industrial robot code recommendations. The machine readable instructions and/or operations 500 of FIG. 5 begin at block 502, at which the code recommendation circuitry 102 of FIGS. 1-4 is trained. The code recommendation circuitry 102 of FIGS. 1-4 includes at least two generative models which are additionally trained at block 502.” (Leon, [0068])
Rationale: Leon teaches trained generative AI models for robot code recommendation and a transformer model in the context of robot action-sequence processing. Leon does not expressly disclose GPROS or the coined phrase “GPROS-GPT.” Perrone supplies the GPROS framework, while Leon supplies the trained generative AI/transformer robot-code recommendation model. A PHOSITA would have found it obvious to implement Leon’s generative robot-code recommendation model as a GPT-style transformer model adapted to Perrone’s GPROS environment, yielding the claimed GPROS-GPT model. This is a predictable use of a known generative transformer architecture to produce task-responsive robot code, actions, or configuration outputs within a robotics software framework.
query the GPROS-GPT model to generate GPROS configuration data and service extension files;
See at least: “At runtime, the action recommendation circuitry 202 performs action recommendations based on an encoded task and environment description, an initial action sequence (that can be empty) and a scene state representation from sensor data.” (Leon, [0042]) “The output of the action recommendation circuitry 202 is a sequence of actions. The output is transmitted to the parameter recommendation circuitry 204.” (Leon, [0042]) “The parameter recommendation circuitry 204 generates parameters of suggested actions.” (Leon, [0043]) “Encoded task and environment data may be expressed as a vector or word embedding. An example encoding method includes semantic lifting of natural language queries, parsing the query within the context of the industrial robot 104 of FIG. 1.” (Leon, [0049]) “Example 20 includes the method of any of the previous examples, wherein the task data and the encoded scene information include code from an augmented code database.” (Leon, [0128])
Rationale: Leon teaches runtime recommendation based on encoded task and environment descriptions, generated action sequences, generated parameters, natural-language query parsing in a robot context, and code from an augmented code database. In the Perrone-Leon combination, the queried model is the GPROS-adapted GPT-style model, and Leon’s generated robot-operation outputs are expressed as Perrone-compatible GPROS configuration data and service extension files. A PHOSITA would have had a reason to do so because Perrone’s GPROS framework already uses configuration data and service-extension code artifacts to define, extend, load, and operate robot behavior.
Motivation to Combine Perrone and Leon for Claim 15
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Perrone and Leon before them, to modify Perrone’s processor-executed GPROS configuration, service-extension, and robotics-application framework by incorporating Leon’s trained generative AI robot-code recommendation system, implemented as a GPT-style transformer model, so that task, environment, scene, or natural-language queries generate Perrone-compatible GPROS configuration data and service extension files for loading into and using a GPROS-based robot or autonomous-vehicle application.
Perrone and Leon are technically compatible because both address software-based robot programming and control. Perrone provides the GPROS framework, including processor-executed software, configuration data, service extensions, plug-ins, dynamic loading, and GPROS-based robot or autonomous-vehicle operation. Leon provides trained generative AI models that generate robot-operation outputs from task, environment, scene, and natural-language inputs. A PHOSITA would have been motivated to combine them to reduce manual robot programming, improve configuration efficiency, and accelerate development and deployment of GPROS-based robot and autonomous-vehicle applications.
Regarding Claim 18,
The combination of Perrone and Leon establishes the computing system of Claim 15, which is the basis for Claim 18.
Disclosure by Perrone
Perrone discloses the processor-configured GPROS loading framework relevant to Claim 18:
wherein to load the GPROS configuration data and the service extension files into the GPROS-based application, the at least one processor is configured to:
See at least: “An embodiment in aspects also defines a method by which configuration data may be loaded, transparent to the application, from one or more configuration data sources in both a static fashion (i.e., at application startup) or dynamically (i.e., as the application is running).” (Perrone, [0006]) “Computer system 6900 may include one or more processors (also called central processing units, or CPUs), such as a processor 6904.” (Perrone, [0314]) “Such control logic, when executed by one or more data processing devices (such as computer system 6900), may cause such data processing devices to operate as described herein.” (Perrone, [0325])
Rationale: Perrone discloses processor-executed control logic and a GPROS framework in which configuration data may be loaded at startup or dynamically. Thus, Perrone discloses the processor-configured loading context of Claim 18. Perrone is not relied upon as expressly disclosing the collecting, storing, compiling, and linking sub-steps.
Claim Limitations Not Explicitly Disclosed by Perrone
Perrone does not explicitly disclose the following additional claim limitations:
collect the GPROS configuration data and the service extension files generated from the querying the GPROS-GPT model; store the GPROS configuration data and the service extension files into GPROS configuration folders; and compile and link the service extension files into the GPROS-based application.
Obviousness of the Remaining Limitations in View of Perrone and Leon
The combination of Perrone and Leon renders obvious:
collect the GPROS configuration data and the service extension files generated from the querying the GPROS-GPT model;
See at least: “At runtime, the action recommendation circuitry 202 performs action recommendations based on an encoded task and environment description, an initial action sequence (that can be empty) and a scene state representation from sensor data.” (Leon, [0042]) “The output of the action recommendation circuitry 202 is a sequence of actions. The output is transmitted to the parameter recommendation circuitry 204.” (Leon, [0042]) “Encoded task and environment data may be expressed as a vector or word embedding. An example encoding method includes semantic lifting of natural language queries, parsing the query within the context of the industrial robot 104 of FIG. 1.” (Leon, [0049])
Rationale: Neither Perrone nor Leon is relied upon as expressly reciting the exact processor-configured collecting step. Leon teaches runtime robot operations, outputs generated from task/environment inputs and natural-language queries, and transmits them for downstream use. In the Claim 15 Perrone-Leon system, those generated outputs are expressed as Perrone-compatible GPROS configuration data and service extension files. Configuring the processor to collect those generated artifacts would have been an ordinary and predictable software-handling step because the generated files must be made available before they can be stored, compiled, linked, loaded, or used by the GPROS-based application.
store the GPROS configuration data and the service extension files into GPROS configuration folders; and
See at least: “The Config service 540 extends the Any service 510 by providing specific calls and services that relate to retrieving and storing configuration data. Thus, configuration data may be stored in any type of underlying storage medium (e.g., file, XML, database, remote server, etc).” (Perrone, [0111]) “Configuration information may be stored in different underlying mediums 543 such as configuration files, XML documents, databases, statically in code (e.g., class files), or remote servers.” (Perrone, [0111]) “Thus, the conditions and their parameters, the conditional evaluation functions, the System, the association of System objects to other triggered System objects, and the arbitration of which System objects are executed can all be defined in configuration files or objects using the Config service described here.” (Perrone, [0135])
Rationale: Perrone teaches storing GPROS configuration data in files and other storage media, and using configuration files or objects to define GPROS behavior. Although Perrone does not expressly recite “GPROS configuration folders,” a PHOSITA would have found it obvious to store generated GPROS configuration data and service extension files in GPROS configuration folders because folders are conventional file-system containers for organizing related configuration and source/code artifacts so that they can be located, loaded, built, deployed, and managed by the application framework.
compile and link the service extension files into the GPROS-based application.
See at least: “In these embodiments, the software of an embodiment can be run alone or in conjunction with additional software applications, services extensions, modules, etc. (i.e., plug-ins), which may be created separately by a programmer.” (Perrone, [0028]) “It should thus be evident that an embodiment provides an operating system that provides individual services and the combination and interconnections of such services using built-in service extensions, built-in completely configurable generic services, and a way to plug in additional service extensions...” (Perrone, [0311]) “Example 20 includes the method of any of the previous examples, wherein the task data and the encoded scene information include code from an augmented code database.” (Leon, [0128])
Rationale: Perrone teaches service extensions, modules, and plug-ins that may be separately created and plugged into the GPROS software framework. Leon teaches code from an augmented code database in the robot-code recommendation context. In the Claim 15 combination, the generated service extension files are software artifacts for extending the GPROS-based application. Compiling and linking such files would have been a routine and predictable processor-implemented software build and integration step to make generated extension code executable, callable, or pluggable into the GPROS-based application.
Motivation to Combine Perrone and Leon for Claim 18
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Perrone and Leon before them, to configure the processor in the Perrone-Leon computing system of Claim 15 to collect generated GPROS configuration data and service extension files, store the generated files in GPROS configuration folders, and compile and link the generated service extension files into the GPROS-based application.
A PHOSITA would have had a reason to implement these steps because Leon generates robot-operation outputs for downstream use, while Perrone’s GPROS framework consumes configuration data and service-extension code to configure, extend, load, and operate robotics applications. Collecting, storing, compiling, and linking the generated artifacts are predictable, processor-implemented software-handling, organization, build, and integration steps that would improve automation, reduce manual programming, and support deployment of the GPROS-based application.
Regarding Claim 20,
The combination of Perrone and Leon establishes the computing system of Claim 15, which is the basis for Claim 20.
Disclosure by Perrone
Perrone discloses:
wherein to use the GPROS-based application to operate the GPROS-based robot or the GPROS-based autonomous vehicle, the at least one processor is configured to:
See at least: “Computer system 6900 may include one or more processors (also called central processing units, or CPUs), such as a processor 6904.” (Perrone, [0314]) “Such control logic, when executed by one or more data processing devices (such as computer system 6900), may cause such data processing devices to operate as described herein.” (Perrone, [0325]) “The RobotGeneric 703 is a completely configurable abstraction that can be used to model any type of robot.” (Perrone, [0203]) “As can be seen, by configuring the various application services of GPROS, a fully autonomous or automated vehicle, otherwise referred to as a driverless car or self-driving car, can be realized.” (Perrone, [0305])
Rationale: Perrone discloses a processor-executed computing system and GPROS services used to operate a robot or autonomous vehicle. Thus, Perrone discloses the processor-configured GPROS operation context recited by Claim 20.
launch the GPROS-based application to use the GPROS configuration data and the service extension files,
See at least: “The configuration services are used in conjunction with an object registration service to automatically create, configure, assemble, deploy, launch, and manage any application objects defined in the configuration.” (Perrone, [0023]) “Configuration data can be read or sent over a variety of network connections, and the code itself can be read or sent over a network, such that the initial code requires no additional customization. If multiple robots on a network include an embodiment, new configuration and code (and hence, behavior) can all be dynamically, and optionally simultaneously, loaded into any robot on the network.” (Perrone, [0010]) “In these embodiments, the software of an embodiment can be run alone or in conjunction with additional software applications, services extensions, modules, etc. (i.e., plug-ins), which may be created separately by a programmer.” (Perrone, [0028]) “FIG. 34 illustrates how the registry service is used to launch generic robotics applications.” (Perrone, [0249]) “The System 1200 initiates the Object Launcher 1201, and after the initial loading of the program, an object handle is obtained from the ObjectRegistry 1202 given its launcher ID.” (Perrone, [0249])
Rationale: Perrone expressly teaches launching application objects defined in configuration and launching generic robotics applications using a registry service. Perrone also teaches that configuration data and code may be loaded and that GPROS software may run with service extensions, modules, and plug-ins. Therefore, Perrone teaches configuring the processor to launch the GPROS-based application to use GPROS configuration data and service-extension code artifacts. In the Perrone-Leon computing system, the GPROS configuration data and service extension files are the generated Perrone-compatible artifacts supplied by the GPROS-GPT model.
Claim Limitations Not Explicitly Disclosed by Perrone
Perrone does not explicitly disclose the following additional claim limitation:
wherein the GPROS-based robot or the GPROS-based autonomous vehicle is placed in a zone of operation.
Obviousness of the Remaining Limitation in View of Perrone and Leon
The combination of Perrone and Leon renders obvious:
wherein the GPROS-based robot or the GPROS-based autonomous vehicle is placed in a zone of operation.
See at least: “A TrackSegment 794 defines boundaries within which a robot may travel over a route segment. A Course 791 is a type of Route 792 which defines the TrackSegments 794 over which a robot may or should travel.” (Perrone, [0194]) “The RouteNetwork is essentially a map with the various course features that may be identifiable on a map.” (Perrone, [0196]) “At runtime, the action recommendation circuitry 202 performs action recommendations based on an encoded task and environment description, an initial action sequence (that can be empty) and a scene state representation from sensor data.” (Leon, [0042])
Rationale: Perrone does not expressly recite that the GPROS-based robot or autonomous vehicle is placed in a zone of operation. However, Perrone teaches track segments, course boundaries, route networks, and maps that define where the robot may or should travel. Leon teaches runtime robot-operation outputs based on task, environment, and scene information. In the Perrone-Leon system, the launched GPROS-based application operates the robot or autonomous vehicle using configuration data and service-extension functionality directed to a particular task, route, map, or environment. A PHOSITA would have found it obvious that the GPROS-based robot or autonomous vehicle is placed in the corresponding zone of operation because the configured route, map, task, environment, and behavior information can be performed only when the robot or vehicle is physically located in the area where the operation is to occur. This is a routine and predictable operational condition for using a mobile robot or autonomous vehicle.
Motivation to Combine Perrone and Leon for Claim 20
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Perrone and Leon before them, to configure the processor in the Perrone-Leon computing system of Claim 15 to launch the GPROS-based application using the generated GPROS configuration data and service extension files when the GPROS-based robot or autonomous vehicle is placed in its intended zone of operation.
A PHOSITA would have been motivated to make the combination because Perrone’s GPROS framework launches and operates robots and autonomous vehicles using configuration information, service extensions, route/course information, and maps, while Leon supplies generated robot-operation outputs based on task, environment, and scene inputs. The combination would predictably allow the robot or autonomous vehicle to operate according to the generated configuration and extension artifacts in the area where the task is to be performed, thereby improving automation, configuration efficiency, and deployment of GPROS-based robotic or autonomous-vehicle applications.
Claims 2, 9, 16 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Perrone, in view of Leon, and in view of Farabet et al. (US 20190303759 A1) herein after will be referred to as Farabet.
Regarding Claim 2,
The combination of Perrone and Leon establishes the method of Claim 1, which is the basis for Claim 2.
Claim Limitations Not Explicitly Disclosed by Perrone
Perrone does not explicitly disclose the following claim limitations:
training the GPROS-GPT model using data from a plurality of data sources, wherein the data comprises one or more of text data, Extensible Markup Language (XML) files, image data, video data, LiDAR point cloud data, or RADAR data; and fine-tuning the trained GPROS-GPT model using a specific dataset corresponding to a task or a domain associated with GPROS template data.
Disclosure by Leon
Leon teaches:
wherein the training the GPROS-GPT model further comprises:
See at least: “The example action recommendation circuitry 202 is trained, in part, on augmented code stored in the augmented code database 216.” (Leon, [0038]) “Therefore, the parameter recommendation circuitry 204 trains a generative model for each action.” (Leon, [0045]) “FIG. 5 is a flowchart representative of example machine readable instructions and/or example operations 500 that may be executed and/or instantiated by processor circuitry to implement industrial robot code recommendations. The machine readable instructions and/or operations 500 of FIG. 5 begin at block 502, at which the code recommendation circuitry 102 of FIGS. 1-4 is trained. The code recommendation circuitry 102 of FIGS. 1-4 includes at least two generative models which are additionally trained at block 502.” (Leon, [0068])
Rationale: Leon expressly teaches training generative models for industrial robot code recommendation. In the parent Claim 1 combination, Leon’s trained generative AI / transformer model is adapted to Perrone’s GPROS environment as the GPROS-GPT model. Thus, Leon teaches the further training context recited by this limitation.
training the GPROS-GPT model using data from a plurality of data sources,
See at least: “At runtime, the action recommendation circuitry 202 performs action recommendations based on an encoded task and environment description, an initial action sequence (that can be empty) and a scene state representation from sensor data.” (Leon, [0042]) “Therefore, the parameter recommendation circuitry 204 trains a generative model for each action. Sensor input can be used to train each action specific generative model by running example tasks containing multiple actions.” (Leon, [0045]) “Example 17 includes the method of any of the previous examples, further including training the first and second generative artificial intelligence models based on encoded task, encoded environment, and previous action data.” (Leon, [0125])
Rationale: Leon teaches training generative AI models using multiple categories of robot-related data, including encoded task data, encoded environment data, previous action data, and sensor input. In the parent Claim 1 combination, these data categories are applied to the GPROS-adapted GPT-style model. Leon therefore teaches or renders obvious training the GPROS-GPT model using data from a plurality of data sources.
wherein the data comprises one or more of text data, Extensible Markup Language (XML) files, image data, video data, LiDAR point cloud data, or RADAR data; and
See at least: “The example natural language encoder 208 of FIG. 2 includes the task description encoder 210 and the environment encoder 212. The task description encoder 210 takes in natural language input...” (Leon, [0047]) “Encoded task and environment data may be expressed as a vector or word embedding. An example encoding method includes semantic lifting of natural language queries, parsing the query within the context of the industrial robot 104 of FIG. 1.” (Leon, [0049]) “Configuration data may be stored in any type of underlying storage medium (e.g., file, XML, database, remote server, etc).” (Perrone, [0111])
Rationale: Leon teaches natural-language input, natural-language queries, and word embeddings, which correspond to text data. Perrone teaches XML as a storage format for configuration data. Because the claim recites “one or more of” the listed data types, the combined teachings of Leon and Perrone account for the text data and XML file alternatives.
Claim Limitations Not Explicitly Disclosed by the Combination of Perrone and Leon
After combining the teachings of Perrone and Leon, the following additional limitations are not explicitly disclosed:
image data, video data, LiDAR point cloud data, or RADAR data; and fine-tuning the trained GPROS-GPT model using a specific dataset corresponding to a task or a domain associated with GPROS template data.
Disclosure by Farabet
Farabet teaches:
image data, video data, LiDAR point cloud data, or RADAR data;
See at least: “The sensors of the vehicle(s) 102 may include, without limitation... stereo camera(s) 1168, wide-view camera(s) 1170... infrared camera(s) 1172, surround camera(s) 1174... long-range and/or mid-range camera(s) 1198...” (Farabet, [0028]) “In such examples, an on-demand transcoding service may transform the raw data into various target formats (e.g., MPEG, JPEG, FP16, etc.)...” (Farabet, [0037]) “The flash LIDAR device may use a 5 nanosecond class I (eye-safe) laser pulse per frame and may capture the reflected laser light in the form of 3D range point clouds...” (Farabet, [0202]) “RADAR sensor(s) 1160...” (Farabet, [0028])
Rationale: Farabet expressly teaches camera systems that capture image data, video input and MPEG target formats, LiDAR technologies that produce 3D range point clouds, and RADAR sensors. These teachings correspond to the image, video, LiDAR point cloud, and RADAR data alternatives. Because the claim recites “one or more of” the listed data types, Farabet’s teachings satisfy multiple alternatives in the limitation.
and fine-tuning the trained GPROS-GPT model
See at least: “The process 118 may further include data indexing and curation 124, data labeling services 126, model training 128, model refinement, pruning, and/or fine tuning 130...” (Farabet, [0034]) “The workflow 300B may provide for fine-tuning and/or transfer learning.” (Farabet, [0047]) “As such, where the trained DNNs suffer, fine-tuning may be executed to improve, validate, and verify the DNNs prior to deployment...” (Farabet, [0123])
Rationale: Farabet expressly teaches model refinement, fine-tuning, and transfer learning for trained autonomous machine models prior to deployment. A PHOSITA would have applied Farabet’s fine-tuning approach to the trained GPROS-GPT model of the Perrone-Leon combination to improve the model’s generated GPROS configuration data and service extension files before deployment in a robotics or autonomous-vehicle application.
Obviousness of the Remaining Limitation in View of Perrone, Leon, and Farabet
The combination of Perrone, Leon, and Farabet renders obvious:
using a specific dataset corresponding to a task or a domain associated with GPROS template data.
See at least: “A VRAF extension of GPROS provides services common to a specific vertical robotics and automation application domain...” (Perrone, [0105]) “Provision of all of these services in a combined fashion enables robotics application providers (e.g., developers and tools) to focus on specifying the business logic and configuration data specific to a robotics or automation application.” (Perrone, [0106]) “Search indexes may be used to retrieve specific segments of the data, which may then be tagged and/or flagged for further processing.” (Farabet, [0037]) “Exported datasets may be stored in a dataset store, which may be a service that handles immutable datasets for further processing. Once the datasets are stored, the datasets may be used and re-used to reproduce training results exactly, or run and re-run simulation jobs.” (Farabet, [0037])
Rationale: Perrone supplies the GPROS task/domain/template-data context by teaching vertical robotics application domains, configuration data specific to robotics applications, and configuration files or objects that define GPROS behavior, parameters, and system associations. Farabet supplies the specific-dataset teaching by disclosing retrieval of specific data segments, tagging or flagging those segments, storing exported datasets in a dataset store, and reusing stored datasets for training and simulation. Leon supplies the trained generative robot-code model.
A PHOSITA would have found it obvious to fine-tune the trained GPROS-GPT model using a specific dataset corresponding to a robotics task or GPROS domain associated with GPROS template data because task/domain-specific data would align the model’s generated outputs with Perrone’s domain-specific GPROS configuration files, configuration objects, behavior parameters, and service-extension needs. This would have predictably improved the accuracy, relevance, and reliability of generated GPROS configuration data and service extension files for the intended robotics or autonomous-vehicle domain.
Motivation to Combine Perrone, Leon, and Farabet for Claim 2
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Perrone, Leon, and Farabet before them, to modify the Perrone-Leon GPROS-GPT system so that the GPROS-GPT model is trained using data from multiple data sources, including natural-language/text data, XML/configuration data, image data, video data, LiDAR point-cloud data, and RADAR data, and fine-tuned using a task-specific or domain-specific dataset associated with GPROS template/configuration data.
Perrone provides the GPROS configuration framework and domain-specific robotics configuration environment. Leon provides trained generative AI robot-code recommendation models using task, environment, action, scene, sensor, and natural-language inputs. Farabet provides multi-source autonomous-machine datasets, sensor modalities, dataset curation, model training, and fine-tuning techniques. A PHOSITA would have been motivated to combine these teachings to improve model accuracy, task-specific performance, configuration quality, and deployment reliability.
Regarding Claim 9,
The combination of Perrone and Leon establishes the non-transitory computer-readable medium of Claim 8, which is the basis for Claim 9.
Claim Limitations Not Explicitly Disclosed by Perrone
Perrone does not explicitly disclose the following claim limitations:
training the GPROS-GPT model using data from a plurality of data sources, wherein the data comprises one or more of text data, Extensible Markup Language (XML) files, image data, video data, LiDAR point cloud data, or RADAR data; and fine-tuning the trained GPROS-GPT model using a specific dataset corresponding to a task or a domain associated with GPROS template data.
Disclosure by Leon
Leon discloses:
wherein the training the GPROS-GPT model further comprises:
See at least: “Example 10 includes the computer readable medium of any of the previous examples, wherein the instructions, when executed, cause the processor circuitry to train the first and second generative artificial intelligence models based on encoded task, encoded environment, and previous action data.” (Leon, [0117])
Rationale: Leon expressly discloses a computer-readable medium embodiment in which instructions cause processor circuitry to train generative AI models. In the Claim 8 combination, those generative models are adapted as the GPROS-GPT model.
training the GPROS-GPT model using data from a plurality of data sources,
See at least: “Example 10 includes the computer readable medium of any of the previous examples, wherein the instructions, when executed, cause the processor circuitry to train the first and second generative artificial intelligence models based on encoded task, encoded environment, and previous action data.” (Leon, [0117])
Rationale: Leon teaches processor-executed training of generative AI models using multiple categories of data, including encoded task data, encoded environment data, and previous action data. In the Claim 8 combination, those data categories are applied to the GPROS-GPT model.
wherein the data comprises one or more of text data, Extensible Markup Language (XML) files, image data, video data, LiDAR point cloud data, or RADAR data; and
See at least: “Example 11 includes the computer readable medium of any of the previous examples, wherein the instructions, when executed, cause the processor circuitry to extract features from a natural language input...” (Leon, [0118]) “Configuration data may be stored in any type of underlying storage medium (e.g., file, XML, database, remote server, etc).” (Perrone, [0111])
Rationale: Leon teaches natural-language input in a computer-readable medium embodiment, corresponding to text data. Perrone teaches XML as a storage format for configuration data. Because the claim recites “one or more of,” these teachings account for the text data and XML file alternatives.
Claim Limitations Not Explicitly Disclosed by the Combination of Perrone and Leon
After combining the teachings of Perrone and Leon, the following additional limitations are not explicitly disclosed:
image data, video data, LiDAR point cloud data, or RADAR data; and fine-tuning the trained GPROS-GPT model using a specific dataset corresponding to a task or a domain associated with GPROS template data.
Disclosure by Farabet
Farabet discloses:
image data, video data, LiDAR point cloud data, or RADAR data; and
See at least: “The sensors of the vehicle(s) 102 may include, without limitation... stereo camera(s) 1168... RADAR sensor(s) 1160... LIDAR sensor(s) 1164...” (Farabet, [0028]) “In such examples, an on-demand transcoding service may transform the raw data into various target formats (e.g., MPEG, JPEG, FP16, etc.)...” (Farabet, [0037]) “The flash LIDAR device may use a 5 nanosecond class I (eye-safe) laser pulse per frame and may capture the reflected laser light in the form of 3D range point clouds...” (Farabet, [0202])
Rationale: Farabet expressly teaches camera systems that capture image data, video input and MPEG target formats, LiDAR technologies that produce 3D range point clouds, and RADAR sensors. These teachings correspond to the image, video, LiDAR point cloud, and RADAR data alternatives.
fine-tuning the trained GPROS-GPT model
See at least: “The process 118 may further include data indexing and curation 124, data labeling services 126, model training 128, model refinement, pruning, and/or fine tuning 130...” (Farabet, [0034]) “The workflow 300B may provide for fine-tuning and/or transfer learning.” (Farabet, [0047]) “As such, where the trained DNNs suffer, fine-tuning may be executed to improve, validate, and verify the DNNs prior to deployment...” (Farabet, [0123])
Rationale: Farabet expressly teaches model refinement, fine-tuning, and transfer learning for trained autonomous machine models prior to deployment. A PHOSITA would have applied Farabet’s fine-tuning approach to the trained GPROS-GPT model in the Perrone-Leon computer-readable medium combination to improve generated GPROS configuration data and service extension files.
Obviousness of the Remaining Limitation in View of Perrone, Leon, and Farabet
The combination of Perrone, Leon, and Farabet renders obvious:
using a specific dataset corresponding to a task or a domain associated with GPROS template data.
See at least: “A VRAF extension of GPROS provides services common to a specific vertical robotics and automation application domain...” (Perrone, [0105]) “Provision of all of these services in a combined fashion enables robotics application providers (e.g., developers and tools) to focus on specifying the business logic and configuration data specific to a robotics or automation application.” (Perrone, [0106]) “Search indexes may be used to retrieve specific segments of the data...” (Farabet, [0037]) “Exported datasets may be stored in a dataset store... and re-used to reproduce training results exactly, or run and re-run simulation jobs.” (Farabet, [0037])
Rationale: Perrone supplies the GPROS template-data context by teaching domain-specific robotics application services, configuration data specific to robotics applications, and configuration files or objects that define GPROS behavior, parameters, and system associations. Farabet supplies the specific-dataset teaching by disclosing retrieval of specific data segments, tagging or flagging those segments, storing exported datasets in a dataset store, and reusing stored datasets for training and simulation. Leon supplies the trained generative robot-code model.
A PHOSITA would have found it obvious to fine-tune the trained GPROS-GPT model using a dataset specific to the relevant GPROS task or domain, so that the generated GPROS configuration data and service extension files align with the applicable GPROS template/configuration data. This would have predictably improved model accuracy, relevance, and domain-specific performance.
Motivation to Combine Perrone, Leon, and Farabet for Claim 9
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Perrone, Leon, and Farabet before them, to configure the non-transitory computer-readable medium of the Perrone-Leon combination so that its instructions train the GPROS-GPT model using data from multiple data sources and fine-tune the trained GPROS-GPT model using a task-specific or domain-specific dataset associated with GPROS template/configuration data.
Perrone provides the GPROS configuration framework and domain-specific robotics configuration environment. Leon provides processor-executed generative AI robot-code recommendation training based on task, environment, action, sensor, scene, and natural-language data. Farabet provides multi-source autonomous-machine training data, dataset curation, model training, and fine-tuning. A PHOSITA would have been motivated to combine these teachings to improve model accuracy, reliability, and domain-specific performance when generating GPROS configuration data and service extension files for the intended GPROS robotic application.
Claim Limitations Not Explicitly Disclosed by the Combination of All References
After combining the teachings of Perrone, Leon, and Farabet, all limitations of Claim 9 are disclosed or rendered obvious.
Regarding Claim 16,
The combination of Perrone and Leon establishes the computing system of Claim 15, which is the basis for Claim 16.
Claim Limitations Not Explicitly Disclosed by Perrone
Perrone does not explicitly disclose the following claim limitations:
train the GPROS-GPT model using data from a plurality of data sources, wherein the data comprises one or more of text data, Extensible Markup Language (XML) files, image data, video data, LiDAR point cloud data, or RADAR data; and fine-tune the trained GPROS-GPT model using a specific dataset corresponding to a task or a domain associated with GPROS template data.
Disclosure by Leon
Leon discloses or renders obvious:
wherein to train the GPROS-GPT,
See at least: “The example action recommendation circuitry 202 is trained, in part, on augmented code stored in the augmented code database 216.” (Leon, [0038]) “Therefore, the parameter recommendation circuitry 204 trains a generative model for each action.” (Leon, [0045])
Rationale: Leon teaches training generative AI models in an industrial robot code recommendation system. In the Claim 15 combination, those trained generative models are adapted as the GPROS-GPT model.
train the GPROS-GPT model using data from a plurality of data sources,
See at least: “Example 3 includes the apparatus of any of the previous examples, wherein the processor circuitry is to execute the instructions to train the first and second generative artificial intelligence models based on encoded task, encoded environment, and previous action data.” (Leon, [0110]) “Therefore, the parameter recommendation circuitry 204 trains a generative model for each action. Sensor input can be used to train each action specific generative model by running example tasks containing multiple actions.” (Leon, [0045])
Rationale: Leon teaches processor circuitry configured to train generative AI models using multiple categories of data, including encoded task data, encoded environment data, previous action data, and sensor input. In the Claim 15 combination, a PHOSITA would have configured the processor to train the GPROS-GPT model using these multiple data sources.
wherein the data comprises one or more of text data, Extensible Markup Language (XML) files, image data, video data, LiDAR point cloud data, or RADAR data;
See at least: “Example 4 includes the apparatus of any of the previous examples, wherein the processor circuitry is to encode the task data by executing the instructions to extract features from a natural language input...” (Leon, [0111]) “Configuration data may be stored in any type of underlying storage medium (e.g., file, XML, database, remote server, etc).” (Perrone, [0111])
Rationale: Leon teaches processor circuitry using natural-language input, which corresponds to text data. Perrone teaches XML as a storage format for configuration data. Because the claim recites “one or more of,” these teachings account for the text data and XML file alternatives.
Claim Limitations Not Explicitly Disclosed by the Combination of Perrone and Leon
After combining the teachings of Perrone and Leon, the following additional limitations are not explicitly disclosed:
image data, video data, LiDAR point cloud data, or RADAR data; and fine-tune the trained GPROS-GPT model using a specific dataset corresponding to a task or a domain associated with GPROS template data.
Disclosure by Farabet
Farabet discloses or renders obvious:
image data, video data, LiDAR point cloud data, or RADAR data; and
See at least: “The sensors of the vehicle(s) 102 may include, without limitation... stereo camera(s) 1168... RADAR sensor(s) 1160... LIDAR sensor(s) 1164...” (Farabet, [0028]) “In such examples, an on-demand transcoding service may transform the raw data into various target formats (e.g., MPEG, JPEG, FP16, etc.)...” (Farabet, [0037]) “The flash LIDAR device may use a 5 nanosecond class I (eye-safe) laser pulse per frame and may capture the reflected laser light in the form of 3D range point clouds...” (Farabet, [0202])
Rationale: Farabet expressly teaches camera systems that capture image data, video input and MPEG target formats, LiDAR technologies that produce 3D range point clouds, and RADAR sensors. These teachings correspond to the image, video, LiDAR point cloud, and RADAR data alternatives.
fine-tune the trained GPROS-GPT model
See at least: “The process 118 may further include data indexing and curation 124, data labeling services 126, model training 128, model refinement, pruning, and/or fine tuning 130...” (Farabet, [0034]) “The workflow 300B may provide for fine-tuning and/or transfer learning.” (Farabet, [0047]) “As such, where the trained DNNs suffer, fine-tuning may be executed to improve, validate, and verify the DNNs prior to deployment...” (Farabet, [0123])
Rationale: Farabet expressly teaches fine-tuning trained autonomous machine models before deployment. In the combined system, a PHOSITA would have configured the processor to fine-tune the trained GPROS-GPT model to improve generated GPROS configuration data and service extension files for the intended robotics or autonomous-vehicle task.
Obviousness of the Remaining Limitation in View of Perrone, Leon, and Farabet
The combination of Perrone, Leon, and Farabet renders obvious:
using a specific dataset corresponding to a task or a domain associated with GPROS template data.
See at least: “A VRAF extension of GPROS provides services common to a specific vertical robotics and automation application domain...” (Perrone, [0105]) “Provision of all of these services in a combined fashion enables robotics application providers (e.g., developers and tools) to focus on specifying the business logic and configuration data specific to a robotics or automation application.” (Perrone, [0106]) “Search indexes may be used to retrieve specific segments of the data...” (Farabet, [0037]) “Exported datasets may be stored in a dataset store... and re-used to reproduce training results exactly, or run and re-run simulation jobs.” (Farabet, [0037])
Rationale: Perrone supplies the GPROS template-data context by teaching vertical robotics application domains, configuration data specific to robotics applications, and configuration files or objects defining behavior and parameters. Farabet supplies the specific-dataset teaching by disclosing specific data-segment retrieval, tagging or flagging for processing, dataset storage, and dataset reuse for training and simulation. A PHOSITA would have found it obvious to configure the processor to fine-tune the trained GPROS-GPT model using a dataset specific to the relevant robotics task or GPROS domain, so that the generated outputs align with the applicable GPROS template/configuration data.
Motivation to Combine Perrone, Leon, and Farabet for Claim 16
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Perrone, Leon, and Farabet before them, to configure the processor in the Perrone-Leon computing system of Claim 15 to train the GPROS-GPT model using multiple data sources and to fine-tune the trained GPROS-GPT model using a task-specific or domain-specific dataset associated with GPROS template/configuration data.
A PHOSITA would have been motivated to make this combination because Perrone provides the GPROS configuration and robotics-domain framework, Leon provides processor-configured generative AI robot-code training, and Farabet provides multi-source autonomous-machine training data, dataset curation, and fine-tuning techniques. The combination would have predictably improved model accuracy, task suitability, and reliability when generating GPROS configuration data and service extension files for a GPROS-based robot or autonomous vehicle.
Claim Limitations Not Explicitly Disclosed by the Combination of All References
After combining the teachings of Perrone, Leon, and Farabet, all limitations of Claim 16 are disclosed or rendered obvious.
Regarding Claim 19,
The combination of Perrone, Leon, and Farabet establishes the computing system of Claim 16, which is the basis for Claim 19.
Claim Limitations Not Explicitly Disclosed by Perrone
Perrone does not explicitly disclose the following additional claim limitation:
wherein to compile and link the service extension files, the at least one processor is configured to dynamically compile and link the service extension files.
Obviousness of the Remaining Limitation in View of Perrone and Leon
The combination of Perrone and Leon renders obvious:
wherein to compile and link the service extension files, the at least one processor is configured to dynamically compile and link the service extension files.
See at least: “Configuration data can be read or sent over a variety of network connections, and the code itself can be read or sent over a network, such that the initial code requires no additional customization. If multiple robots on a network include an embodiment, new configuration and code (and hence, behavior) can all be dynamically, and optionally simultaneously, loaded into any robot on the network.” (Perrone, [0010]) “In these embodiments, the software of an embodiment can be run alone or in conjunction with additional software applications, services extensions, modules, etc. (i.e., plug-ins), which may be created separately by a programmer.” (Perrone, [0028]) “By using some embodiments’ services, robotics and automation applications inherit complete static and dynamic configurability, configurability using any underlying configuration medium, automateable assembly and construction based on configuration information, automateable deployment based on configuration information...” (Perrone, [0106]) “At runtime, the action recommendation circuitry 202 performs action recommendations based on an encoded task and environment description, an initial action sequence (that can be empty) and a scene state representation from sensor data.” (Leon, [0042])
Rationale: Perrone does not expressly recite processor-configured dynamic compiling and linking. However, Perrone teaches dynamic loading of new configuration and code, dynamic configurability, and separately created service extensions and plug-ins. Leon teaches runtime generation of robot-operation outputs, which are combined and generated as GPROS configuration data and service extension files. In the combined system, generated service extension files are software artifacts used in Perrone’s dynamically configurable GPROS framework.
A PHOSITA would have found it obvious to configure the processor to dynamically compile and link the generated or updated service extension files so that newly generated extension functionality could be integrated into the GPROS-based application when needed, without requiring a static rebuild each time the service extension files changed. This is a predictable software build-and-integration technique that supports Perrone’s dynamic loading and dynamic configurability and enables Leon’s generated service-extension functionality to be deployed efficiently in the GPROS-based application.
Motivation to Combine Perrone, Leon, and Farabet for Claim 19
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Perrone, Leon, and Farabet before them, to configure the processor in the combined computing system so that service extension files generated for the GPROS-based application are dynamically compiled and linked when generated or updated.
Perrone provides a dynamically configurable GPROS framework that supports dynamic loading of configuration and code. Leon provides runtime generation of robot-operation outputs that are adapted as GPROS configuration data and service extension files. Farabet provides multi-source autonomous machine training data, dataset curation, and model fine-tuning techniques that support the overall training and refinement pipeline for the GPROS-GPT model. A PHOSITA would have been motivated to combine these teachings because dynamically compiling and linking the generated service extension files would have predictably allowed newly generated or updated extension functionality to be integrated into the GPROS-based application when needed, improving automation, reducing manual build effort, increasing deployment speed, and supporting Perrone’s dynamic configuration and loading framework while maintaining consistency with the overall Perrone-Leon-Farabet combination used to establish Claim 16.
Claims 3 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Perrone, in view of Leon, in view of Farabet, and in view of Brill et al. (US 20050273317 A1) herein after will be referred to as Brill.
Regarding Claim 3,
The combination of Perrone, Leon, and Farabet establishes the method of Claim 2, which is the basis for Claim 3.
Claim Limitations Not Explicitly Taught by the Combination of Perrone, Leon, and Farabet
Perrone, Leon, and Farabet establish that the GPROS-GPT model is trained using text data and is subsequently fine-tuned using a task-specific or domain-specific dataset. However, the combination does not expressly identify the text-data training as unsupervised training or expressly identify the fine-tuning as supervised training. Accordingly, the following limitations remain:
wherein the training the GPROS-GPT model using the text data comprises an unsupervised training and the fine-tuning of the trained GPROS-GPT model comprises a supervised training.
Obviousness of the Remaining Limitation in View of Perrone, Leon, Farabet, and Brill
Brill expressly teaches the “unsupervised training” aspect, while the Perrone-Leon-Farabet combination supplies the GPROS-GPT model trained using text data. The combination of Perrone, Leon, Farabet, and Brill renders obvious:
wherein the training the GPROS-GPT model using the text data comprises an unsupervised training
See at least: “The present invention provides a method and apparatus for performing unsupervised training of one or more natural language processing components, such as syntactic parsers and/or semantic interpreters. The invention performs this training by utilizing at least two natural language processing systems, typically consisting of a syntactic parser and semantic interpreter, possibly with other components. These systems are used to form separate meaning sets from parallel corpora, which represent the same set of sentences written in different languages.” (Brill, [0022]) “Under the method of the present invention, one or more of the specifications 324, 326, 334 and/or 336 are adjusted through unsupervised training. In the description below, an unsupervised training method involving generating and testing candidate learning sets is described.” (Brill, [0029])
Rationale: Brill expressly teaches an unsupervised training technique for natural language processing components that learns from text corpora by generating and testing candidate learning sets. A PHOSITA would have understood that such unsupervised training reduces the need for manually supplied target labels for the text-training examples. In the proposed combination, the portion of the GPROS-GPT model training that uses text data is performed using this type of unsupervised training. A PHOSITA would have found it obvious to apply Brill’s known unsupervised training technique to the text-data training of the GPROS-GPT model.
and the fine-tuning of the trained GPROS-GPT model comprises a supervised training.
See at least: “The workflow 300B may provide for fine-tuning and/or transfer learning. For example, the system may reload models from the model store 306 … and continue to train them.” (Farabet, [0047]) “The pre-trained models may be used to score new data, and the score may be used to prioritize which data to label.… As such, when a frame is confusing for the DNN … then the frame may be labeled so that the DNN can learn from the frame, thereby further refining the pre-trained DNN.” (Farabet, [0044]) “The workflow 300A may include data ingestion 122, passing of the data to dataset store(s) 302 … labeling the data using data labeling services 126, and training DNNs using model training 128.” (Farabet, [0043])
Rationale: Farabet teaches a computer-implemented workflow in which selected data are labeled and then used to further refine or fine-tune a pre-trained model. A PHOSITA would have understood that refining a model using labeled examples constitutes supervised training, because the labels supply the target information against which the model’s outputs are evaluated. Brill paragraph [0004] corroborates that supervised training of natural language components uses an annotated corpus in which target outputs are provided. In the combined system, after the GPROS-GPT model has been initially trained on text data using unsupervised training, it would have been obvious to fine-tune the model using labeled task-specific or domain-specific data, thereby making the fine-tuning a supervised training step.
Motivation to Combine Perrone, Leon, Farabet, and Brill for Claim 3
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Perrone, Leon, Farabet, and Brill before them, to implement the text-data training stage of the GPROS-GPT model as unsupervised training and to implement the subsequent task-specific or domain-specific fine-tuning stage as supervised training.
Perrone provides the GPROS robotics configuration framework and domain-specific environment. Leon provides a generative model trained using natural-language and robotics-related data. Farabet provides workflows for labeling data and fine-tuning pre-trained models. Brill provides established unsupervised training techniques for natural language processing components using text corpora. Brill is reasonably pertinent to the claimed problem because it expressly contemplates that a trained natural-language unit may be used to produce actions performed by a robot (Brill, [0041]).
A PHOSITA would have been motivated to use unsupervised training for the initial text-data training because Brill’s technique would reduce dependence on manually annotated target outputs during the broad training stage. A PHOSITA would then have been motivated to use supervised fine-tuning on labeled task-specific or domain-specific data because doing so would predictably improve the accuracy and relevance of the GPROS configuration data and service extension files for the intended application. A PHOSITA would have had a reasonable expectation of success because Brill’s unsupervised natural-language training technique and Farabet’s labeled-data fine-tuning workflow, corroborated by Brill’s description of supervised training using annotated text, are compatible software-based model-training techniques applicable to an existing trained model. Brill trains natural-language components by adjusting their specifications, while Farabet reloads pre-trained models and continues training them through a labeled-data fine-tuning workflow. Applying those training operations would not require changing the GPROS interfaces through which the trained model’s outputs are used.
Regarding Claim 10,
The combination of Perrone, Leon, and Farabet establishes the non-transitory computer-readable medium of Claim 9, which is the basis for Claim 10.
Claim Limitations Not Explicitly Disclosed by the Combination of Perrone, Leon, and Farabet
Perrone, Leon, and Farabet establish processor-executable instructions for training the GPROS-GPT model using text and other data and for fine-tuning the trained model using a task-specific or domain-specific dataset. However, the combination does not expressly identify the text-data training as unsupervised training or expressly identify the fine-tuning as supervised training. Accordingly, the following limitations remain:
wherein the training the GPROS-GPT model using the text data comprises an unsupervised training and the fine-tuning of the trained GPROS-GPT model comprises a supervised training.
Obviousness of the Remaining Limitation in View of Perrone, Leon, Farabet, and Brill
Brill expressly teaches the “unsupervised training” aspect, while the Perrone-Leon-Farabet combination supplies the GPROS-GPT model trained using text data. The combination of Perrone, Leon, Farabet, and Brill renders obvious:
wherein the training the GPROS-GPT model using the text data comprises an unsupervised training
See at least: “The present invention provides a method and apparatus for performing unsupervised training of one or more natural language processing components, such as syntactic parsers and/or semantic interpreters. The invention performs this training by utilizing at least two natural language processing systems, typically consisting of a syntactic parser and semantic interpreter, possibly with other components. These systems are used to form separate meaning sets from parallel corpora, which represent the same set of sentences written in different languages.” (Brill, [0022]) “Under the method of the present invention, one or more of the specifications 324, 326, 334 and/or 336 are adjusted through unsupervised training. In the description below, an unsupervised training method involving generating and testing candidate learning sets is described.” (Brill, [0029])
Rationale: Brill expressly discloses computer-implemented unsupervised training of natural language processing components using text corpora and an unsupervised learning module that generates and tests candidate learning sets. A PHOSITA would have understood that such unsupervised training reduces the need for manually supplied target labels for the text-training examples. In the Perrone-Leon-Farabet computer-readable-medium combination establishing Claim 9, the stored instructions cause processor circuitry to train the GPROS-GPT model using text data. A PHOSITA would have found it obvious to incorporate Brill’s unsupervised training technique into those instructions so that the training the GPROS-GPT model using the text data comprises an unsupervised training.
and the fine-tuning of the trained GPROS-GPT model comprises a supervised training.
See at least: “The workflow 300B may provide for fine-tuning and/or transfer learning. For example, the system may reload models from the model store 306 … and continue to train them.” (Farabet, [0047]) “The pre-trained models may be used to score new data, and the score may be used to prioritize which data to label.… As such, when a frame is confusing for the DNN … then the frame may be labeled so that the DNN can learn from the frame, thereby further refining the pre-trained DNN.” (Farabet, [0044]) “The workflow 300A may include data ingestion 122, passing of the data to dataset store(s) 302 … labeling the data using data labeling services 126, and training DNNs using model training 128.” (Farabet, [0043])
Rationale: Farabet teaches a computer-implemented workflow in which selected data are labeled and then used to further refine or fine-tune a pre-trained model. A PHOSITA would have understood that refining a model using labeled examples constitutes supervised training. Brill paragraph [0004] corroborates that supervised training of natural language components uses an annotated corpus in which target outputs are provided. In the combined system, after the GPROS-GPT model has been initially trained on text data using unsupervised training, it would have been obvious to configure the stored instructions so that the model is subsequently fine-tuned using labeled task-specific or domain-specific examples, thereby making the fine-tuning a supervised training step.
Motivation to Combine Perrone, Leon, Farabet, and Brill for Claim 10
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Perrone, Leon, Farabet, and Brill before them, to configure the instructions stored on the non-transitory computer-readable medium so that the GPROS-GPT model is initially trained on text data through unsupervised training and is subsequently fine-tuned through supervised training using labeled examples associated with the intended GPROS task or domain.
Perrone provides the processor-executed GPROS framework. Leon provides processor-executed generative AI training using natural-language and robotics data. Farabet provides computer-implemented labeling and fine-tuning of pre-trained models. Brill provides computer-implemented unsupervised training techniques for natural language components using text corpora. Brill is reasonably pertinent to the claimed problem because it expressly contemplates that a trained natural-language unit may be used to produce actions performed by a robot (Brill, [0041]).
A PHOSITA would have been motivated to encode this two-stage training workflow in the stored instructions because Brill’s unsupervised technique would reduce dependence on manually annotated target outputs during the initial text-data training stage, while supervised fine-tuning on labeled task-specific data would predictably improve the accuracy and relevance of the GPROS configuration data and service extension files for the intended application. A PHOSITA would have had a reasonable expectation of success because Brill’s unsupervised natural-language training technique and Farabet’s labeled-data fine-tuning workflow, corroborated by Brill’s description of supervised training using annotated text, are compatible software-based model-training techniques applicable to an existing trained model. Brill trains natural-language components by adjusting their specifications, while Farabet reloads pre-trained models and continues training them through a labeled-data fine-tuning workflow. Applying those training operations would not require changing the GPROS interfaces through which the trained model’s outputs are used.
Claims 4, 11, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Perrone, in view of Leon, and in view of Wang et al. (US 20210232773 A1) herein after will be referred to as Wang.
Regarding Claim 4,
The combination of Perrone and Leon establishes the method of Claim 1, which is the basis for Claim 4.
Claim Limitations Not Explicitly Taught by Perrone
Perrone does not explicitly teach the following claim limitations:
wherein the querying the GPROS-GPT model comprises: receiving an input text; breaking the input text into a plurality of tokens while maintaining a context and order of words in the input text; mapping the plurality of tokens into a plurality of unique integer identifiers (IDs); converting the plurality of IDs to a plurality of continuous vectors; processing the plurality of continuous vectors using a multi-layer transformer architecture; and generating the GPROS configuration data and service extension files based on the plurality of continuous vectors.
Disclosure by Leon
Leon teaches:
wherein the querying the GPROS-GPT model comprises: receiving an input text;
See at least: “At runtime, the action recommendation circuitry 202 performs action recommendations based on an encoded task and environment description, an initial action sequence (that can be empty) and a scene state representation from sensor data.” (Leon, [0042]) “The example natural language encoder 208 of FIG. 2 includes the task description encoder 210 and the environment encoder 212. The task description encoder 210 takes in natural language input...” (Leon, [0047])
Rationale: Leon expressly teaches a runtime generative process that receives natural language input. In the Claim 1 combination, Leon’s generative model is adapted as the GPROS-GPT model. Leon therefore teaches or renders obvious both the transitional limitation and receiving an input text.
Claim Limitations Not Explicitly Taught by the Combination of Perrone and Leon
After combining the teachings of Perrone and Leon, the following additional limitations are not explicitly taught:
breaking the input text into a plurality of tokens while maintaining a context and order of words in the input text; mapping the plurality of tokens into a plurality of unique integer identifiers (IDs); converting the plurality of IDs to a plurality of continuous vectors; processing the plurality of continuous vectors using a multi-layer transformer architecture; and generating the GPROS configuration data and service extension files based on the plurality of continuous vectors.
Obviousness of the Remaining Limitations in View of Perrone, Leon, and Wang
The combination of Perrone, Leon, and Wang renders obvious:
breaking the input text into a plurality of tokens while maintaining a context and order of words in the input text;
See at least: “The token level encoding layer 442 may employ a tokenizer (e.g., WordPiece) to tokenize the long sequence by splitting the long sequence into a word sequence. In some aspects, each word may be embedded with an absolute positional code.” (Wang, [0046]) “Each input token embedding can be combined with its position embedding and segment embedding...” (Wang, [0047]) “The unified transformer encoder 450 can denote the embedded vision-language inputs as [H'=[e₁, ..., eₙ]] and then encode them into multiple levels of contextual representations H'=[h₁', ..., hₙ₁'] using stacked L-stacked transformer blocks...” (Wang, [0048])
Rationale: Wang expressly teaches WordPiece tokenization that splits input text into a sequence of tokens while preserving word order through absolute positional codes and position embeddings. Wang further teaches that these embeddings are processed by stacked transformer blocks to produce multiple levels of contextual representations. A PHOSITA would have found it obvious to apply Wang’s tokenization and contextual processing techniques to the natural language input received by the GPROS-GPT model.
mapping the plurality of tokens into a plurality of unique integer identifiers (IDs);
See at least: “Each input token embedding can be combined with its position embedding and segment embedding... before feeding to multiple transformer blocks in the unified transformer encoder 450.” (Wang, [0047])
Rationale: Wang teaches converting tokenized text into embeddings for transformer processing but does not expressly state that tokens are first mapped to unique integer IDs. A PHOSITA would have found it obvious to assign each distinct WordPiece token a unique integer vocabulary index so that its corresponding embedding vector could be retrieved from an embedding table. This is the conventional and predictable implementation of the embedding process disclosed by Wang.
converting the plurality of IDs to a plurality of continuous vectors;
See at least: “Each input token embedding can be combined with its position embedding and segment embedding (0 or 1, indicating whether it is image or text) before feeding to multiple transformer blocks in the unified transformer encoder 450.” (Wang, [0047])
Rationale: Wang expressly teaches representing tokenized input as continuous token embeddings before transformer processing. Once each WordPiece token is assigned a unique integer vocabulary index, using that index to retrieve the corresponding continuous embedding vector would have been the conventional and predictable implementation of Wang’s disclosed embedding process.
processing the plurality of continuous vectors using a multi-layer transformer architecture;
See at least: “The unified transformer encoder 450 can denote the embedded vision-language inputs as [H'=[e₁, ..., eₙ]] and then encode them into multiple levels of contextual representations H'=[h₁', ..., hₙ₁'] using stacked L-stacked transformer blocks, where the 1-th transformer block is denoted as H'←Transformer(H'¹), 1∈[1, L]. Inside each transformer block, the previous layer's output H'¹∈R w×dᵢ is aggregated using the multi-head self-attention...” (Wang, [0048])
Rationale: Wang expressly teaches processing continuous vector embeddings using stacked multi-layer transformer blocks with multi-head self-attention to produce contextualized representations.
generating the GPROS configuration data and service extension files based on the plurality of continuous vectors.
See at least: “The unified transformer encoder 450 can denote the embedded vision-language inputs as [H'=[e₁, ..., eₙ]] and then encode them into multiple levels of contextual representations H'=[h₁', ..., hₙ₁'] using stacked L-stacked transformer blocks...” (Wang, [0048]) “During inference, the subject technology can directly either rank the answer candidates according to their respective NSP scores or generate an answer sequence by recursively applying the MLM operation.” (Wang, [0018] and [0054])
Rationale: Wang teaches that contextualized representations produced by stacked transformer blocks are used during inference to generate output sequences. The Perrone-Leon combination establishing the parent claim already renders obvious generating GPROS configuration data and service extension files. Wang further teaches that generated output sequences are derived from continuous contextual representations produced by stacked transformer blocks. It would therefore have been obvious to implement the parent claim’s established artifact-generation operation using Wang’s vector-based transformer output pipeline, so that the GPROS configuration data and service extension files are generated based on the plurality of continuous vectors.
Motivation to Combine Perrone, Leon, and Wang for Claim 4
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Perrone, Leon, and Wang before them, to modify the Perrone-Leon GPROS-GPT system so that querying the GPROS-GPT model comprises receiving input text, tokenizing it while preserving context and order, mapping tokens to unique integer IDs, converting the IDs to continuous vectors, processing the vectors using a multi-layer transformer architecture, and generating GPROS configuration data and service extension files based on the processed vectors.
Perrone provides the GPROS configuration and service extension framework. Leon provides a generative model that receives natural language input and produces robot-related outputs. Wang provides a transformer-based architecture that converts tokenized natural language input into contextualized representations using stacked transformer blocks and generates output sequences from those representations. Wang is reasonably pertinent because it addresses the same technical problem of processing natural language input through tokenization and a multi-layer transformer to generate useful output sequences.
A PHOSITA would have been motivated to combine these teachings because incorporating Wang’s multi-layer transformer architecture would have predictably enabled richer contextual understanding of the input text and improved the quality and coherence of the generated GPROS configuration data and service extension files. A PHOSITA would have had a reasonable expectation of success because Wang’s WordPiece tokenization, embedding lookup, and stacked transformer operations process the same type of natural language input used by Leon’s generative model, while Perrone accepts software-generated configuration and extension artifacts. The modification would apply each component according to its established function and would require only formatting the generated outputs for use with Perrone’s existing GPROS interfaces.
Regarding Claim 11,
The combination of Perrone and Leon establishes the non-transitory computer-readable medium of Claim 8, which is the basis for Claim 11.
Claim Limitations Not Explicitly Disclosed by Perrone
Perrone does not explicitly disclose the following claim limitations:
wherein the querying the GPROS-GPT model comprises: receiving an input text; breaking the input text into a plurality of tokens while maintaining a context and order of words in the input text; mapping the plurality of tokens into a plurality of unique integer identifiers (IDs); converting the plurality of IDs to a plurality of continuous vectors; processing the plurality of continuous vectors using a multi-layer transformer architecture; and generating the GPROS configuration data and service extension files based on the plurality of continuous vectors.
Disclosure by Leon
Leon discloses:
wherein the querying the GPROS-GPT model comprises: receiving an input text;
See at least: “At runtime, the action recommendation circuitry 202 performs action recommendations based on an encoded task and environment description, an initial action sequence (that can be empty) and a scene state representation from sensor data.” (Leon, [0042]) “The example natural language encoder 208 of FIG. 2 includes the task description encoder 210 and the environment encoder 212. The task description encoder 210 takes in natural language input...” (Leon, [0047])
Rationale: Leon discloses a runtime generative process that receives natural language input. In the Claim 8 combination, Leon’s generative model is adapted as the GPROS-GPT model.
Claim Limitations Not Explicitly Disclosed by the Combination of Perrone and Leon
After combining the teachings of Perrone and Leon, the following additional limitations are not explicitly disclosed:
breaking the input text into a plurality of tokens while maintaining a context and order of words in the input text; mapping the plurality of tokens into a plurality of unique integer identifiers (IDs); converting the plurality of IDs to a plurality of continuous vectors; processing the plurality of continuous vectors using a multi-layer transformer architecture; and generating the GPROS configuration data and service extension files based on the plurality of continuous vectors.
Obviousness of the Remaining Limitations in View of Perrone, Leon, and Wang
The combination of Perrone, Leon, and Wang renders obvious:
breaking the input text into a plurality of tokens while maintaining a context and order of words in the input text;
See at least: “The token level encoding layer 442 may employ a tokenizer (e.g., WordPiece) to tokenize the long sequence by splitting the long sequence into a word sequence. In some aspects, each word may be embedded with an absolute positional code.” (Wang, [0046]) “Each input token embedding can be combined with its position embedding and segment embedding...” (Wang, [0047]) “The unified transformer encoder 450 can denote the embedded vision-language inputs as [H'=[e₁, ..., eₙ]] and then encode them into multiple levels of contextual representations H'=[h₁', ..., hₙ₁'] using stacked L-stacked transformer blocks...” (Wang, [0048])
Rationale: Wang expressly teaches WordPiece tokenization that splits input text into a sequence of tokens while preserving word order through absolute positional codes and position embeddings. Wang further teaches that these embeddings are processed by stacked transformer blocks to produce multiple levels of contextual representations. A PHOSITA would have found it obvious to apply Wang’s tokenization and contextual processing techniques when the stored instructions cause the GPROS-GPT model to process natural language input.
mapping the plurality of tokens into a plurality of unique integer identifiers (IDs);
See at least: “Each input token embedding can be combined with its position embedding and segment embedding... before feeding to multiple transformer blocks in the unified transformer encoder 450.” (Wang, [0047])
Rationale: Wang teaches converting tokenized text into embeddings but does not expressly state that tokens are mapped to unique integer IDs. A PHOSITA would have found it obvious to assign each distinct WordPiece token a unique integer vocabulary index so that its corresponding embedding vector could be retrieved from an embedding table.
converting the plurality of IDs to a plurality of continuous vectors;
See at least: “Each input token embedding can be combined with its position embedding and segment embedding (0 or 1, indicating whether it is image or text) before feeding to multiple transformer blocks in the unified transformer encoder 450.” (Wang, [0047])
Rationale: Wang expressly teaches representing tokenized input as continuous token embeddings before transformer processing. Once each WordPiece token is assigned a unique integer vocabulary index, using that index to retrieve the corresponding continuous embedding vector would have been the conventional and predictable implementation of Wang’s disclosed embedding process.
processing the plurality of continuous vectors using a multi-layer transformer architecture;
See at least: “The unified transformer encoder 450 can denote the embedded vision-language inputs as [H'=[e₁, ..., eₙ]] and then encode them into multiple levels of contextual representations H'=[h₁', ..., hₙ₁'] using stacked L-stacked transformer blocks...” (Wang, [0048])
Rationale: Wang expressly teaches processing continuous vector embeddings using stacked multi-layer transformer blocks with multi-head self-attention.
generating the GPROS configuration data and service extension files based on the plurality of continuous vectors.
See at least: “The unified transformer encoder 450 can denote the embedded vision-language inputs as [H'=[e₁, ..., eₙ]] and then encode them into multiple levels of contextual representations H'=[h₁', ..., hₙ₁'] using stacked L-stacked transformer blocks...” (Wang, [0048]) “During inference, the subject technology can directly either rank the answer candidates according to their respective NSP scores or generate an answer sequence by recursively applying the MLM operation.” (Wang, [0018] and [0054])
Rationale: Wang teaches that contextualized representations produced by stacked transformer blocks are used during inference to generate output sequences. The Perrone-Leon combination establishing the parent claim already renders obvious generating GPROS configuration data and service extension files. Wang further teaches that generated output sequences are derived from continuous contextual representations produced by stacked transformer blocks. It would therefore have been obvious to implement the parent claim’s established artifact-generation operation using Wang’s vector-based transformer output pipeline.
Motivation to Combine Perrone, Leon, and Wang for Claim 11
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Perrone, Leon, and Wang before them, to configure the instructions stored on the non-transitory computer-readable medium so that querying the GPROS-GPT model comprises receiving input text, tokenizing it while preserving context and order, mapping tokens to unique integer IDs, converting the IDs to continuous vectors, processing the vectors using a multi-layer transformer architecture, and generating GPROS configuration data and service extension files based on the processed vectors.
Perrone provides the GPROS configuration and service extension framework. Leon provides processor-executed generative AI that receives natural language input. Wang provides a transformer-based architecture for tokenizing text, converting tokens into embeddings, processing them through stacked transformer layers, and generating output from the resulting contextualized representations. Wang is reasonably pertinent because it addresses the same technical problem of processing natural language input through tokenization and a multi-layer transformer to generate useful output sequences.
A PHOSITA would have been motivated to combine these teachings because incorporating Wang’s multi-layer transformer architecture would have predictably enabled richer contextual understanding of the input text and improved the quality of the generated GPROS configuration data and service extension files. A PHOSITA would have had a reasonable expectation of success because Wang’s WordPiece tokenization, embedding lookup, and stacked transformer operations process the same type of natural language input used by Leon’s generative model, while Perrone accepts software-generated configuration and extension artifacts. The modification would apply each component according to its established function and would require only formatting the generated outputs for use with Perrone’s existing GPROS interfaces.
Regarding Claim 17,
The combination of Perrone and Leon establishes the computing system of Claim 15, which is the basis for Claim 17.
Claim Limitations Not Explicitly Disclosed by Perrone
Perrone does not explicitly disclose the following claim limitations:
wherein to query the GPROS-GPT model, wherein to query the GPROS-GPT model, the at least one processor is configured to: receive an input text; break the input text into a plurality of tokens while maintaining a context and order of words in the input text; map the plurality of tokens into a plurality of unique integer identifiers (IDs); convert the plurality of IDs to a plurality of continuous vectors; process the plurality of continuous vectors using a multi-layer transformer architecture; and generate the GPROS configuration data and service extension files based on the plurality of continuous vectors.
Disclosure by Leon
Leon renders obvious:
wherein to query the GPROS-GPT model, wherein to query the GPROS-GPT model, the at least one processor is configured to: receive an input text;
See at least: “At runtime, the action recommendation circuitry 202 performs action recommendations based on an encoded task and environment description, an initial action sequence (that can be empty) and a scene state representation from sensor data.” (Leon, [0042]) “The example natural language encoder 208 of FIG. 2 includes the task description encoder 210 and the environment encoder 212. The task description encoder 210 takes in natural language input...” (Leon, [0047])
Rationale: Leon teaches a runtime generative process executed by processor circuitry that receives natural language input. In the Claim 15 combination, Leon’s generative model is adapted as the GPROS-GPT model.
Claim Limitations Not Explicitly Disclosed by the Combination of Perrone and Leon
After combining the teachings of Perrone and Leon, the following additional limitations are not explicitly disclosed:
break the input text into a plurality of tokens while maintaining a context and order of words in the input text; map the plurality of tokens into a plurality of unique integer identifiers (IDs); convert the plurality of IDs to a plurality of continuous vectors; process the plurality of continuous vectors using a multi-layer transformer architecture; and generate the GPROS configuration data and service extension files based on the plurality of continuous vectors.
Obviousness of the Remaining Limitations in View of Perrone, Leon, and Wang
The combination of Perrone, Leon, and Wang renders obvious:
break the input text into a plurality of tokens while maintaining a context and order of words in the input text;
See at least: “The token level encoding layer 442 may employ a tokenizer (e.g., WordPiece) to tokenize the long sequence by splitting the long sequence into a word sequence. In some aspects, each word may be embedded with an absolute positional code.” (Wang, [0046]) “Each input token embedding can be combined with its position embedding and segment embedding...” (Wang, [0047]) “The unified transformer encoder 450 can denote the embedded vision-language inputs as [H'=[e₁, ..., eₙ]] and then encode them into multiple levels of contextual representations H'=[h₁', ..., hₙ₁'] using stacked L-stacked transformer blocks...” (Wang, [0048])
Rationale: Wang expressly teaches WordPiece tokenization that splits input text into a sequence of tokens while preserving word order through absolute positional codes and position embeddings. Wang further teaches that these embeddings are processed by stacked transformer blocks to produce multiple levels of contextual representations. A PHOSITA would have found it obvious to configure the processor to apply Wang’s tokenization and contextual processing techniques to the natural language input.
map the plurality of tokens into a plurality of unique integer identifiers (IDs);
See at least: “Each input token embedding can be combined with its position embedding and segment embedding... before feeding to multiple transformer blocks in the unified transformer encoder 450.” (Wang, [0047])
Rationale: Wang teaches converting tokenized text into embeddings but does not expressly state that tokens are mapped to unique integer IDs. A PHOSITA would have found it obvious to assign each distinct WordPiece token a unique integer vocabulary index so that its corresponding embedding vector could be retrieved from an embedding table.
convert the plurality of IDs to a plurality of continuous vectors;
See at least: “Each input token embedding can be combined with its position embedding and segment embedding (0 or 1, indicating whether it is image or text) before feeding to multiple transformer blocks in the unified transformer encoder 450.” (Wang, [0047])
Rationale: Wang expressly teaches representing tokenized input as continuous token embeddings before transformer processing. Once each WordPiece token is assigned a unique integer vocabulary index, using that index to retrieve the corresponding continuous embedding vector would have been the conventional and predictable implementation of Wang’s disclosed embedding process.
process the plurality of continuous vectors using a multi-layer transformer architecture;
See at least: “The unified transformer encoder 450 can denote the embedded vision-language inputs as [H'=[e₁, ..., eₙ]] and then encode them into multiple levels of contextual representations H'=[h₁', ..., hₙ₁'] using stacked L-stacked transformer blocks...” (Wang, [0048])
Rationale: Wang expressly teaches processing continuous vector embeddings using stacked multi-layer transformer blocks with multi-head self-attention.
generate the GPROS configuration data and service extension files based on the plurality of continuous vectors.
See at least: “The unified transformer encoder 450 can denote the embedded vision-language inputs as [H'=[e₁, ..., eₙ]] and then encode them into multiple levels of contextual representations H'=[h₁', ..., hₙ₁'] using stacked L-stacked transformer blocks...” (Wang, [0048]) “During inference, the subject technology can directly either rank the answer candidates according to their respective NSP scores or generate an answer sequence by recursively applying the MLM operation.” (Wang, [0018] and [0054])
Rationale: Wang teaches that contextualized representations produced by stacked transformer blocks are used during inference to generate output sequences. The Perrone-Leon combination, establishing the parent claim, already renders obvious generating GPROS configuration data and service extension files. Wang further teaches that generated output sequences are derived from continuous contextual representations produced by stacked transformer blocks. It would therefore have been obvious to implement the parent claim’s established artifact-generation operation using Wang’s vector-based transformer output pipeline.
Motivation to Combine Perrone, Leon, and Wang for Claim 17
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Perrone, Leon, and Wang before them, to configure the at least one processor in the computing system so that, to query the GPROS-GPT model, the processor receives input text, breaks it into tokens while maintaining context and order, maps the tokens to unique integer IDs, converts the IDs to continuous vectors, processes the vectors using a multi-layer transformer architecture, and generates GPROS configuration data and service extension files based on the processed vectors.
Perrone provides the GPROS configuration and service extension framework executed by a processor. Leon provides processor-configured generative AI that receives natural language input. Wang provides a transformer-based architecture for tokenizing text, converting tokens into embeddings, processing them through stacked transformer layers, and generating output from the resulting contextualized representations. Wang is reasonably pertinent because it addresses the same technical problem of processing natural language input through tokenization and a multi-layer transformer to generate useful output sequences.
A PHOSITA would have been motivated to combine these teachings because incorporating Wang’s multi-layer transformer architecture would have predictably enabled richer contextual understanding of the input text and improved the quality of the generated GPROS configuration data and service extension files. A PHOSITA would have had a reasonable expectation of success because Wang’s WordPiece tokenization, embedding lookup, and stacked transformer operations process the same type of natural language input used by Leon’s generative model, while Perrone accepts software-generated configuration and extension artifacts. The modification would apply each component according to its established function and would require only formatting the generated outputs for use with Perrone’s existing GPROS interfaces.
Response to Arguments
Response to Applicant’s Arguments Under 35 U.S.C. § 103
Applicant’s arguments have been fully considered but are not persuasive.
The amendments identified by Applicant as non-narrowing typographical corrections have been considered. These amendments do not materially alter the substantive limitations relied upon in the maintained rejections and do not overcome the prior-art combinations and rationales set forth in this Office action.
Applicable Obviousness Standard
Applicant’s arguments repeatedly focus on whether Perrone, Leon, or Wang individually and expressly recites the complete claimed combination. However, the pending rejections are based on the combined teachings of the applied references, not on any single reference independently anticipating the claims.
The test for obviousness is what the combined teachings of the references would have suggested to one of ordinary skill in the art, rather than whether the features of a secondary reference may be bodily incorporated into the primary reference. In re Keller, 642 F.2d 413, 425, 208 USPQ 871, 881 (CCPA 1981); In re Mouttet, 686 F.3d 1322, 1332–33, 103 USPQ2d 1219, 1226 (Fed. Cir. 2012); MPEP § 2145. A claim cannot be shown nonobvious merely by attacking references individually when the rejection is based on their combined teachings. In re Keller, 642 F.2d 413; In re Merck & Co., 800 F.2d 1091, 1097, 231 USPQ 375, 380 (Fed. Cir. 1986).
The rejection does not contend that Perrone alone trains and queries a GPROS-GPT model or that Leon alone expressly generates files bearing the names “GPROS configuration data” and “service extension files.” Rather, Perrone supplies the GPROS configuration, extension, loading, application, robot, and autonomous-vehicle framework, while Leon supplies the trained generative AI, transformer, natural-language query, and robot-output generation teachings. The rejection explains why a PHOSITA would have adapted Leon’s generated outputs for use as the native configuration and service-extension artifacts consumed by Perrone’s GPROS framework.
A. Independent Claim 1
Applicant argues that Perrone does not automatically generate GPROS configuration data and service extensions and instead relies on configuration information and extensions created manually or through external tools. Applicant further argues that Leon generates only robot “actions,” “sequences,” and “parameters,” rather than GPROS configuration data and service extension files.
These arguments are not persuasive.
Perrone Supplies the Claimed GPROS Framework and Expressly Encourages Automation
Perrone expressly teaches a method that uses a general-purpose robotics operating system and provides application services that access configuration data through a generic abstraction. Perrone, [0046]. Perrone further teaches loading configuration data either at application startup or dynamically while the application is running. Perrone, [0006]. Perrone teaches that configuration data and code may be communicated over a network and that new configuration and code, and therefore new behavior, may be dynamically loaded into robots. Perrone, [0010].
Perrone also expressly teaches:
configuration services that automatically create, configure, assemble, deploy, launch, and manage application objects defined by configuration information. Perrone, [0023];
separately created service extensions, modules, and plug-ins that may run with the GPROS software. Perrone, [0028];
GPROS-based robotics applications built using common robotics software services. Perrone, [0101];
automated assembly, construction, and deployment based on configuration information. Perrone, [0106];
configurable robot abstractions having sensors, conduct, and actuators, with the robot being commanded through the GPROS Config and Registry services. Perrone, [0203]; and
use of GPROS as an unmanned-ground-vehicle and autonomous-vehicle operating system, including the realization of a fully autonomous or self-driving vehicle through configured GPROS application services. Perrone, [0205], [0305].
Applicant’s observation that Perrone may permit programmers or external tools to create configuration information and extensions does not undermine the rejection. Perrone expressly states that its architecture “lends itself to automating the process of robotics and automation configuration, assembly, construction, deployment, and development by use of associated tools.” Perrone, [0008]. Thus, Perrone itself supplies a reason to automate the generation of the configuration and extension artifacts consumed by its GPROS framework.
Leon Supplies the Trained Generative Model, Querying, and Generated Robot Outputs
Applicant correctly observes that Leon generates robot actions, action sequences, and associated parameters. That observation supports, rather than defeats, the rejection.
Leon teaches that robot actions are behaviors, routines, or processes that produce particular outcomes; that actions may be combined into action sequences; and that associated parameters refine how those actions are executed to complete a desired task. Leon, [0023]. Leon further teaches that tasks are associated with environments and scenes that impose constraints on the robot's operation. Leon, [0024].
Leon expressly teaches:
a generative AI model that proposes actions based on task, environment, and scene representations and is trained using augmented code. Leon, [0038];
a generative architecture capable of producing multiple outputs for an input. Leon, [0040];
runtime generation of action recommendations from encoded task, environment, action-sequence, and sensor information. Leon, [0042];
generation of parameters for suggested actions. Leon, [0043];
training a generative model for each robot action. Leon, [0045];
receipt of natural-language input. Leon, [0047];
use of a transformer model to preserve temporal aspects of action sequences. Leon, [0048];
parsing natural-language queries in the context of an industrial robot and expressing encoded task and environment information as vectors or word embeddings. Leon, [0049]; and
training generative models used to implement industrial-robot code recommendations. Leon, [0068], [0125].
Leon, therefore, does not merely disclose an unrelated robot controller. Leon teaches trained generative AI to convert task, environmental, scene, sensor, code, and natural-language information into machine-usable robot actions, sequences, and parameters.
The combination renders the GPROS-GPT Model Obvious.
Applicant argues that Leon does not expressly identify its model as a “GPROS-GPT model.” However, the claimed term is a compound designation for a trained generative transformer model adapted for the GPROS environment. Patentability does not turn on whether the prior art uses the same coined name.
Leon teaches a generative AI model, trains that model before runtime use, and uses a transformer model to process action-sequence information. Leon, [0038], [0045], [0048], [0068]. Leon further teaches querying the trained system at runtime using natural language, task, environment, and scene information. Leon, [0042], [0047], [0049]. Perrone supplies the GPROS environment in which configuration information and service extensions define and extend robot behavior. Perrone, [0023], [0028], [0106], [0135].
Implementing Leon’s trained generative model, with its disclosed transformer architecture, and adapting it for Perrone’s GPROS environment would predictably have produced the claimed GPROS-GPT model. The rejection does not require either reference individually to use the coined expression “GPROS-GPT.”
The combination renders the generation of GPROS Configuration Data and Service Extension Files Obvious.
Applicant’s principal argument is that Leon’s generated actions, sequences, and parameters are not GPROS configuration data or service extension files.
The rejection does not equate Leon’s outputs, without modification, with files already bearing GPROS-specific formatting. Instead, the rejection relies on the combined teachings.
Leon generates robot-operation specifications, including proposed actions, action sequences, and associated parameters, from task, environment, scene, sensor, code, and natural-language inputs. Leon, [0038], [0040], [0042]–[0043], [0049], [0123]–[0125]. Perrone teaches that GPROS behavior, conditions, parameters, system associations, and execution arbitration may be defined in configuration files or objects. Perrone, [0135]. Perrone further teaches service extensions, modules, and plug-ins that add functions or actions to the GPROS application. Perrone, [0028], [0311].
Thus, Leon supplies generated behavioral content and parameters, while Perrone supplies the native GPROS artifact formats through which such behavior and parameters are represented and used. A PHOSITA would have found it obvious to express Leon’s generated action sequences and parameters as Perrone-compatible GPROS configuration data and, where generated functionality extends the existing application services, as service extension files.
The modification would have been technically straightforward and would have produced the predictable result of allowing Leon’s generated robot behavior to be loaded into, configured by, and executed through Perrone’s GPROS application framework. A PHOSITA would have had a reasonable expectation of success because both references concern programmatic specification of robot behavior: Leon generates the behavior and associated parameters, while Perrone consumes configuration information and loadable extensions to define and operate that behavior.
Applicant’s assertion that Leon “directly” uses its generated actions for execution by a robot does not teach away from also representing those generated actions and parameters in the native configuration and extension formats required by a target robotics operating system. Nor has Applicant identified a technical incompatibility that would have prevented Leon’s generated outputs from being formatted for Perrone’s GPROS interfaces.
Accordingly, the combination renders obvious:
training the GPROS-GPT model;
querying the GPROS-GPT model;
generating GPROS configuration data and service extension files;
loading those artifacts into a GPROS-based application; and
using the GPROS-based application to operate a GPROS-based robot or autonomous vehicle.
Applicant’s arguments concerning Claim 1 are therefore not persuasive, and the rejection of Claim 1 under 35 U.S.C. § 103 is maintained.
B. Independent Claim 8
Applicant relies entirely on the arguments presented for Claim 1 and asserts that those arguments apply equally to Claim 8.
For the reasons discussed above, those arguments are not persuasive.
Claim 8 recites substantially corresponding operations in a non-transitory computer-readable medium form. The Perrone-Leon combination establishes the substantive GPROS and generative-model operations for the reasons explained for Claim 1. Perrone additionally teaches computer systems having processors, main memory, secondary memory, stored control logic, and execution of that control logic to cause the data-processing system to perform the disclosed operations. Perrone, [0313]–[0318], [0325]. Leon likewise describes processor-executed machine-readable instructions that implement the training and operation of its generative robot-code recommendation circuitry. Leon, [0068], [0117]–[0118], [0123]–[0125].
Applicant has not separately identified a deficiency concerning the non-transitory computer-readable medium form of the claim. Because the substantive argument concerning the generation of GPROS configuration data and service extension files is unpersuasive, the corresponding argument against Claim 8 is also unpersuasive.
The rejection of Claim 8 under 35 U.S.C. § 103 is maintained.
C. Independent Claim 15
Applicant likewise relies on the arguments presented for Claim 1 and does not separately challenge the processor, memory, coupling, or processor-configuration limitations of Claim 15.
For the reasons discussed above, the Perrone-Leon combination renders the recited GPROS-GPT training, querying, artifact generation, loading, and robot-operation functions obvious.
Perrone expressly teaches a computing system having one or more processors, main memory, secondary memory, and stored control logic that causes the processing system to perform the disclosed GPROS operations. Perrone, [0313]–[0318], [0325]. Leon teaches processor circuitry to execute instructions, train generative AI models, and generate robot action proposals, parameters, and action sequences. Leon, [0110], [0123]–[0125].
Applicant has not identified any technical reason why Leon’s processor-executed generative-model operations could not have been implemented in Perrone’s processor-and-memory GPROS computing system. The combination uses each system according to its established function and would have predictably produced a processor-configured GPROS system capable of generating and using GPROS configuration data and service extension files.
The rejection of Claim 15 under 35 U.S.C. § 103 is maintained.
D. Dependent Claims 4, 11, and 17
Applicant argues that Wang is directed to visual dialogue and does not generate GPROS configuration data or service extension files. Applicant acknowledges, however, that Wang tokenizes textual input and processes image and text information using a unified transformer encoder that produces contextual representations through multiple transformer blocks. Applicant’s characterization of Wang, [0044]–[0048].
Applicant’s argument is not persuasive because the rejection does not rely on Wang alone to teach the complete GPROS system or the final GPROS artifacts. The Perrone-Leon combination, establishing the parent claims, already renders the generation of GPROS configuration data and service extension files obvious. Wang is relied upon for the more specific text processing and transformer architecture added by Claims 4, 11, and 17, and for generating output sequences from transformer-processed vector representations.
Receiving Input Text
Leon expressly teaches a natural-language encoder whose task-description encoder receives natural-language input. Leon, [0047]. Leon further teaches semantic lifting and parsing of natural-language queries in the context of an industrial robot. Leon, [0049]. Thus, Leon teaches receiving the claimed input text.
Breaking the Input Text Into Tokens While Maintaining Context and Word Order
Wang expressly teaches employing a WordPiece tokenizer to split a textual sequence into a word sequence. Wang, [0046]. Wang further teaches absolute positional codes, position embeddings, and segment embeddings. Wang, [0046]–[0047]. The positional information maintains the order of the textual elements.
Wang then processes the embeddings through stacked transformer blocks to produce multiple levels of contextual representations. Wang, [0048]. Thus, Wang teaches both preserving sequence order through positional information and maintaining or modeling token context through transformer-generated contextual representations.
Applicant’s observation that Wang also processes image information does not negate or diminish Wang’s express text-processing teachings. Wang’s textual tokenizer, positional encoding, embeddings, and stacked transformer operations remain directly applicable to the natural-language input received by Leon.
Mapping Tokens to Unique Integer IDs and Converting the IDs to Continuous Vectors
Wang teaches WordPiece tokenization followed by BERT-style word embeddings. Wang, [0046]. Wang further teaches token embeddings that are combined with position and segment embeddings before transformer processing. Wang, [0047].
Wang does not expressly use the exact phrase “unique integer identifiers.” However, a PHOSITA implementing Wang’s WordPiece vocabulary and BERT embedding process would have found it obvious to assign each distinct vocabulary token a stable, unique integer lookup index so that the corresponding token embedding could be retrieved. Using the token identifier to retrieve its corresponding multidimensional embedding would convert the discrete token identifier into the continuous vector used by the transformer.
This is not an unsupported substitution unrelated to Wang’s disclosure. It is the predictable implementation of Wang’s expressly disclosed tokenizer-to-embedding pipeline and enables the token embeddings that Wang expressly feeds into its transformer blocks.
Processing the Continuous Vectors Using a Multi-Layer Transformer Architecture
Wang expressly teaches feeding token embeddings into multiple transformer blocks. Wang, [0047]. Wang further teaches stacked transformer blocks producing multiple levels of contextual representations and describes an embodiment having approximately twelve transformer blocks, twelve attention heads, and a hidden-state size of approximately 768. Wang, [0048].
Accordingly, Wang expressly teaches processing continuous embedding vectors using a multi-layer transformer architecture.
Generating the GPROS Artifacts Based on the Continuous Vectors
Applicant argues that Wang produces an answer to a visual dialogue rather than GPROS configuration data and service extension files. This argument again considers Wang in isolation.
Wang teaches that the embedded inputs are transformed into contextual representations using stacked transformer blocks. Wang, [0048]. Wang further teaches generating an answer sequence during inference by recursively applying masked-language-model operations. Wang, [0018], [0054]. Thus, Wang teaches that generated output sequences are based on the transformer-processed continuous representations.
The Perrone-Leon combination, establishing the parent claims, already renders obvious generating GPROS configuration data and service extension files. Wang additionally teaches a known vector-based transformer pipeline through which generated output sequences are derived from contextual vector representations. It would therefore have been obvious to implement the parent claim’s established GPROS artifact-generation operation using Wang’s transformer pipeline, such that the GPROS configuration data and service extension files are generated based on the plurality of continuous vectors.
The Office does not rely on Wang to independently disclose GPROS. Perrone supplies the GPROS configuration and service-extension framework; Leon supplies generative robot outputs from natural-language and encoded inputs; and Wang supplies detailed tokenization, vectorization, multi-layer transformer processing, and vector-based output generation architecture.
Reason to Combine and Reasonable Expectation of Success
Wang is reasonably pertinent because it addresses the same technical problem of processing natural-language input into contextual vector representations and generating output sequences from those representations. Applying Wang’s text-processing pipeline to Leon’s natural-language robot recommendation system would have predictably improved the system’s ability to maintain word order, model context, and generate coherent outputs.
A PHOSITA would have had a reasonable expectation of success because:
Wang’s WordPiece tokenization and transformer architecture process textual input of the same general type received by Leon’s natural-language encoder. Wang, [0046]–[0048];
Leon generates robot actions and parameters from encoded task, environment, scene, and natural-language information. Leon, [0042]–[0043], [0047], [0049]; and
Perrone consumes configuration information and service extensions to configure and operate GPROS robotics applications. Perrone, [0023], [0028], [0106], [0135].
The proposed combination would use each component according to its established function and would require formatting the generated robot output for Perrone’s existing GPROS interfaces. Applicant has not identified any teaching away, change in principle of operation, technical incompatibility, or evidence that the proposed software integration would have been beyond ordinary skill.
Applicant’s arguments concerning Claims 4, 11, and 17 are therefore not persuasive. The rejections of Claims 4, 11, and 17 under 35 U.S.C. § 103 are maintained.
E. Remaining Dependent Claims
Applicant states generally that the claims depending from Claims 1, 8, and 15 are patentable for the same reasons asserted for the independent claims. Applicant does not present separate substantive arguments directed to the specific additional limitations or reference findings for Claims 2, 3, 5–7, 9, 10, 12–14, 16, and 18–20.
Because Applicant’s arguments concerning the independent claims are not persuasive, reliance solely on dependency does not overcome the separately articulated rejections of the dependent claims. Moreover, Applicant has not substantively challenged:
the Farabet teachings and corresponding combination rationale applied to Claims 2, 9, 16, and 19;
the Brill teachings and corresponding combination rationale applied to Claims 3 and 10;
the collecting, storage, configuration-folder, compiling, linking, dynamic-compilation, launch, and zone-of-operation findings applied to Claims 5–7, 12–14, 18, and 20; or
the specific reasons and predictable results identified for incorporating those additional teachings into the respective parent-claim combinations.
Accordingly, the general dependency-based assertion does not overcome the prima facie cases established for those claims.
Conclusion
Applicant’s arguments have been considered, but do not establish error in the prior-art findings or in the articulated reasons to combine the references.
Applicant’s arguments principally require Leon or Wang individually to expressly disclose the entire claimed GPROS implementation. The maintained rejections instead properly rely on the combined teachings:
Perrone provides the GPROS configuration, service extension, application, robot, autonomous-vehicle, loading, and execution framework;
Leon provides trained generative AI, transformer processing, natural-language querying, and generated robot actions, sequences, and parameters; and
Wang provides the detailed tokenization, positional encoding, token-embedding, contextual-vector, multi-layer-transformer, and sequence-generation architecture.
A PHOSITA would have been motivated to combine these compatible teachings to automate the generation of native GPROS configuration and extension artifacts, reduce manual programming, improve contextual processing of natural-language task descriptions, and increase the efficiency and reliability of configuring GPROS-based robots and autonomous vehicles. The combinations would have used the respective teachings according to their established functions and would have produced predictable results with a reasonable expectation of success.
No persuasive evidence of teaching away, technical incompatibility, unexpected results, or other objective indicia sufficient to rebut the established prima facie cases has been presented.
Therefore, Applicant’s arguments are not persuasive, and the rejections of Claims 1–20 under 35 U.S.C. § 103 are maintained.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to OLUWABUSAYO ADEBANJO AWORUNSE whose telephone number is (571)272-4311. The examiner can normally be reached M - F (8:30AM - 5PM).
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, Jelani Smith can be reached at (571) 270-3969. 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.
/OLUWABUSAYO ADEBANJO AWORUNSE/Examiner, Art Unit 3662
/JELANI A SMITH/Supervisory Patent Examiner, Art Unit 3662
Prosecution Insights