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 .
DETAILED ACTION
Priority
Acknowledgment is made of applicant's claim for domestic benefit based on an application17/826,689 (Now US Patent 12,164,274) filed on May 27, 2022.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1 – 20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1 – 20 of U.S. Patent No. 12,164,274. Although the claims at issue are not identical, they are not patentably distinct from each other because they are simple changes of a statutory category. A person of ordinary skill in the art would conclude that the invention defined in the claims at issue would have been an obvious variation of the invention defined in the claims of the U.S. Patent. Comparisons of claim 1 in the instant application are shown in the following table. A mapping of the other claims in the instant application could also be mapped to similar claims in the patent.
Claims in instant App: 18/937,870
Claims in US Patent 12,164,274
1. A system to train machine learning models to perform autonomous control in an industrial automation environment,
the system comprising: one or more processors; and one or more memories having stored thereon instructions that, upon execution by the one or more processors, cause the one or more processors to:
receive operational data generated by Original Equipment Manufacturer (OEM) devices via one or more Application Programming Interfaces (APIs);
identify a device type for the operational data, wherein the operational data characterizes operations of the OEM devices; generate feature vectors based on the operational data, wherein the feature vectors are designed for ingestion by a machine learning model;
transfer the feature vectors to the machine learning model; and receive a training indication from the machine learning model that indicates an autonomous control output for the device type of the OEM devices.
1. A system to train machine learning systems to perform autonomous control in an industrial automation environment, the system comprising:
a memory that stores executable components; and a processor, operatively coupled to the memory, that executes the executable components, the executable components comprising: a data aggregation component configured to
receive operational data generated by Original Equipment Manufacturer (OEM) devices,
identify a device type for the operational data, and transfer the operational data for the device type to a machine learning interface component wherein the operational data characterizes the operations of the OEM devices; the machine learning interface component configured to receive the operational data for the device type, generate feature vectors based on the operational data configured for ingestion by a machine learning model, and
transfer the feature vectors to a machine learning model; and the machine learning interface component configured to receive a training indication from the machine learning model that indicates an autonomous control output for the device type of the OEM devices.
Claim Rejections - 35 USC § 103
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.
Claims 1, 2, 6, 10, 11, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Lakshmanan et al. (US PG Pub. No. 20240152756) herein “Lakshmanan,” in view of Okawa et al. (PG Pub. No. 20220258336), herein “Okawa.”
Regarding claim 1,
Lakshmanan teaches a system to train machine learning models to perform autonomous control in an industrial automation environment, the system comprising: (Par. 0125: “…the data streams generated by the controllers 810a-d can be ingested and analyzed—at the edge or in the cloud—to train predictive analytics models using machine learning algorithms. For example, data streams from the welding gun controllers 810a-d may be used to train an autoencoder network to detect faulty welds.” Par. 0158: “Networks of IoT devices may include commercial and home automation devices, such as water distribution systems, electric power distribution systems, pipeline control systems, plant control systems, light switches, thermostats, locks, doorbells ( e.g., doorbell cameras), cameras, alarms, motion sensors, and the like.”)
one or more processors; (Par. 0177: “Further, these and like examples to a processor-based system shall be taken to include any set of one or more machines that are controlled by or operated by a processor, set of processors, or processing circuitry (e.g., a computer) to individually or jointly execute instructions to perform any one or more of the methodologies discussed herein.” Par. 0030, 0128, 0183, 0184, 0188, etc.)
and one or more memories having stored thereon instructions that, upon execution by the one or more processors, cause the one or more processors to: (Par. 0030, 0128, 0141 – 0144, 0183, 0184, 0185, etc.)
receive operational data generated by Original Equipment Manufacturer (OEM) devices via one or more Application Programming Interfaces (APIs); (See Par. 0228, 0229, 0232, 0234, and 0235 that teaches supporting the API protocol.)
identify a device type for the operational data, wherein the operational data characterizes operations of the OEM devices; (Par. 0114 - 0119: “…the data stream may include parameters with the following types of information… …an identifier of the particular robot, robot arm, and welding gun that performed the spot weld; Par. 0112: “The controller(s) 810a-d of the tool and/or robot generate a data stream with metadata associated with the completed task. For example, the data stream may include a combination of configuration and performance parameters, such as the reference parameters used to configure the robot or tool to perform the task, along with parameters indicating the actual performance of the completed task based on data captured or measured by sensors and other devices (e.g., image/video frames captured by a camera).” Par. 0113.)
generate feature vectors (data stream) based on the operational data, wherein the feature vectors are designed for ingestion by a machine learning model; (Par. 0112: “…for example, each robot uses a tool to perform an assigned task based on specific reference parameters that control how the task is to be performed. Moreover, each time a task is performed, the controller(s) 810a-d of the tool and/or robot generate a data stream with metadata associated with the completed task. For example, the data stream may include a combination1 of configuration and performance parameters, such as the reference parameters used to configure the robot or tool to perform the task, along with parameters indicating the actual performance of the completed task based on data captured or measured by sensors and other devices (e.g., image/video frames captured by a camera).” Par. 0113: “In some embodiments, for example, the data stream may be represented as a file or data object (e.g., a JSON object) with a collection of values corresponding to the parameters, or “features,” associated with the completed task. The underlying data values in the data stream—which tend to be heavily represented using time-series data—can include any representation of data from any type or combination of modalities, including configuration data for tasks and equipment (e.g., robots, tools), performance data captured by sensors and other devices, visual data—such as images and video—captured by cameras and other visual sensors, audio captured by microphones, and so forth.”
transfer the feature vectors to the machine learning model; (Par. 0125: “Moreover, the data streams generated by the controllers 810a-d can be ingested and analyzed-at the edge or in the cloud-to train predictive analytics models using machine learning algorithms…”) and
Lakshmanan may implicitly teach but does not explicitly teach that the model outputs control commands and output that is based on type of device. However, Okawa teaches receive a training indication from the machine learning model that indicates an autonomous control output for the device type of the OEM devices. (Par. 0314: “In another example, the control command may be determined based on the current task state and the goal task state using a trained machine learning model capable of determining such a control command through machine learning, similarly to the determination model 50, the inference model 551, or other models. In this case, the controller 31 inputs the current task state and the goal task state into the trained machine learning model and performs a computational operation of the trained machine learning model. In this manner, the controller 31 obtains, from the trained machine learning model, an output value corresponding to the determined control command. In the above embodiment, the control command includes a command value for the angle of each joint. However, the control command may have any other structure determined as appropriate for, for example, the type of the robot device.” Par. 0010.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have combined the system to train a machine learning model that using combined data (feature vectors) and input the data to a learning model as in Lakshmanan with using the output of the machine learning model to control an autonomous robot as in Okawa in order to use a trained model to determine the control command for a robot device and to changed the task state of the robot device to drive the robot device. (Par. 0015).
Regarding claim 2,
The previously cited reference(s) teach the limitations of claim 1 which claim 2 depends. Okawa also teaches that the one or more processors to: process, by the machine learning model, the feature vectors to train machine learning algorithms of the machine learning model for autonomous control of the device type of the OEM devices. (Par. 0003: “this technique involves teaching a robot device to perform work for every change in the components including a manipulator mechanism, an end-effector, and workpieces. Teaching a robot device to perform work is costly with this technique. Methods for teaching a robot device to perform work through machine learning have thus been studied. For example, Non-Patent Literature 1 describes a method for causing a robot device to learn, through reinforcement learning, operations for gripping an object based on image data obtained from a camera. This method at least partially automates a series of processing steps for teaching operations for gripping an object to a robot device and thus reduces the cost for teaching work to a robot device.” See also Par.0010 – autonomous; 0015, 0016, 0032, 0033, et al. 0297 – autonomous robot.)
Regarding claim 6,
The previously cited reference(s) teach the limitations of claim 1 which claim 6 depends. Lakshmanan also teaches to generate the feature vectors comprise further instructions that, upon execution by the one or more processors, cause the one or more processors to: calculate derivative values2 that represent the operational data and generate the feature vectors based on the derivative values. (Par. 0112: “…the data stream may include a combination of configuration and performance parameters, such as the reference parameters used to configure the robot or tool to perform the task…” Par. 0114 – 0123)
Regarding claims 10, 11, and 15, they are directed to a method of steps to implement the system or apparatuses set forth in claims 1, 2, and 6, respectively. Lakshmanan and Okawa teach the claimed system or apparatuses in claims 1, 2, and 6. Lakshmanan also teaches a data aggregator (Par. 0172: “The data aggregators 1426 may collect data from any number of the sensors 1428, and perform the back end processing function for the analysis. Examiner’s Note – Lakshmanan teaches 30 instances of data or edge aggregator/aggregation.) Therefore, Lakshmanan and Okawa teach the method of steps in claims 10, 11, and 15.
Claims 3 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Lakshmanan in view of Okawa in further view of Jean-Claude L. Franchitti (PG Pub. No. 20190171438), herein “Franchitti.”
Regarding claim 3,
The previously cited reference(s) teach the limitations of claim 1 which claim 3 depends. They do not teach types of devices correspond to different types of APIs. However, Franchitti teaches that the one or more APIs comprise a set of APIs that correspond to different device types for the OEM of the OEM devices. (Par. 0208: “As shown in FIG. 8, digital knowledge touchpoints are acted upon via various types of devices and through corresponding interfaces and/or APIs…” Examiner’s Note – Franchitti does not OEM devices that are manufacturing devices. However, one having ordinary skill in the art would know that different APIs can correspond to different devices, (that Franchitti teaches) and attribute the same logic to manufacturing devices.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have combined the system to train a machine learning model that using combined data (feature vectors) and input the data to a learning model as in Lakshmanan with using the output of the machine learning model to control an autonomous robot as in Okawa with using different APIs that correspond to different types of devices as in Franchitti in order to have different functionality or permissions related to different autonomous solutions (Par. 0150 and 0208)
Regarding claim 12, it is directed to a method of steps to implement the system or apparatuses set forth in claim 3. Lakshmanan, Okawa, and Franchitti teach the claimed system or apparatuses in claim 3. Therefore, Lakshmanan, Okawa, and Franchitti teach the method of steps in claim 12.
Claims 9 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Lakshmanan in view of Okawa in further view of Tremblay et al. (PG Pub. No. 20210118166), herein “Tremblay.”
Regarding claim 9,
The previously cited reference(s) teach the limitations of claim 1 which claim 9 depends. They do not teach different trained models for different devices. However, Tremblay teaches that the wherein the machine learning model is one of a plurality of machine learning models each trained for autonomous control of a different one of a plurality of device types of the OEM devices. (Par. 0050: “In at least one embodiment, a database of robot models 302 can include meshes, models, or other data specific to different types of robots, enabling renderer 306 to render an accurate representation of a specified type of robot in a specific pose. In at least one embodiment, when a neural network is to be trained for a specific type of robot, or autonomous object, a respective model and kinematic data can be provided as input, and control interface 308 can specify different poses for that robot. In at least one embodiment, a renderer can render representations of that type of robot in specified poses, and images can be captured or generated including these representations. In at least one embodiment, these synthetic images can then serve as training data for a neural network, as images include representations of a type of robot in specific poses, and corresponding pose data can serve as ground truth data for training. In at least one embodiment, these synthetic images and pose data can be stored to a database 310 for subsequent use in training a neural network.” Par. 0051: “In at least one embodiment, these synthetic images and pose data can be provided as input to a training module 312. In at least one embodiment, a base model 318 can be selected and trained using this and any other training data 316 in order to generate one or more trained machine learning models 314 that can be used for inferring pose of an object. In at least one embodiment, each robot for which a model is trained will have a corresponding set of weights that can be stored in a model repository 314.” Par. 0047)
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have combined the system to train a machine learning model that using combined data (feature vectors) and input the data to a learning model as in Lakshmanan with using the output of the machine learning model to control an autonomous robot as in Okawa with having different models based on the type of robot as in Tremblay in order to train models to specific features of a robot as different robots have different shapes, sizes, and configurations. (Par. 0047) .
Regarding claim 19, it is directed to a method of steps to implement the system or apparatuses set forth in claim 9. Lakshmanan, Okawa, and Tremblay teach the claimed system or apparatuses in claim 9. Therefore, Lakshmanan, Okawa, and Tremblay teach the method of steps in claim 19.
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Lakshmanan in view of Okawa in further view of Brown et al. (PG Pub. No. 20180357543), herein “Brown.”
Regarding claim 20,
The previously cited reference(s) teach the limitations of claim 1 which claim 20 depends. They an interface showing the model’s training status. However, Brown teaches generating a graphical user interface comprising a training status of the machine learning model. (Par. 0213: “The web site is configured as a browser-based tool for configuring and analyzing AI models stored in the AI engine. The website can be used for sharing, collaborating, and learning. Some information that can be accessed from the web site is a visualization of an AI model's training progress.” See also Par. 0138 that teaches an on screen status as training stopped or “Training Complete.”)
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have combined the system to train a machine learning model that using combined data (feature vectors) and input the data to a learning model as in Lakshmanan with using the output of the machine learning model to control an autonomous robot as in Okawa with training a model that is used for a robotics system wherein the status of the training for the robot can be viewed in a user browser as in Brown in order to allow a user to interface with the AI system and possibly allow an engineer to change the amount of computing resources necessary for the learner process. (Par. 0056 and 0062)
Allowable Subject Matter
Claims 4 and 5; and 13 and 14 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims pending resolving all intervening issues such as the double patenting rejection above. Reasons for allowance will be held in abeyance pending final recitation of the claims. The prior art does not disclose the elements of claim 1 and 3 and wherein the instructions to receive the operational data comprise further instructions that, upon execution by the one or more processors, cause the one or more processors to: receive a call via one of the one or more APIs corresponding to a device type associated with OEM data; receive the operational data via the one of the one or more APIs; and identify the device type based on the call. Claim 5 depends on claim 4 and therefore is also objected to as being allowable. Method claim 13 mirrors those elements of claim 4 and therefore also allowable if rewritten in independent form including all the limitations of the intervening and base claim. Claim 14 depends on claim 13 and therefore is also objected to as being allowable.
2. Claims 7 and 8; and claims 16, 17 and 18 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims pending resolving all intervening issues such as the double patenting rejection above. Reasons for allowance will be held in abeyance pending final recitation of the claims. The prior art does not disclose the elements of claims 1 and/or 10 and wherein the instructions comprise further instructions that, upon execution by the one or more processors, cause the one or more processors to: determine the machine learning model is sufficiently trained; and deploy the machine learning model to one or more programmable logic controllers (PLCs) for autonomously controlling the OEM devices the machine learning model is trained to control. Claim 8 depends from claim 7 and is therefore also allowable if rewritten to include the base claim and the intervening claim. Claims 17 and 18 are similar in scope to claims 7 and 8 and therefore are also objected to. Method claim 16 mirrors those elements of claim 7 and includes additional elements and therefore also allowable if rewritten in independent form including all the limitations of the base claim (claim 10).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Huber et al. (US PG Pub. No. 20230145448) is related to the instant application and teaches some elements of the independent claims wherein: a system to train machine learning models to perform autonomous control in an industrial automation environment, the system comprising: (Par. 0012, last line: “…training, by the one or more processors, the machine learning model based on the retrieved measurement data.” Par. 0011: “…by the one or more processors, an association between the machine learning model and the piece of building equipment, wherein performing the automated action comprises: identifying, by the one or more processors, an identification of the piece of building equipment based on the stored association between the machine learning model and the piece of building equipment; and generating, by the one or more processors, a record comprising an identification of the piece of building equipment, and wherein performing the automated action…”)
one or more processors; and one or more memories having stored thereon instructions that, upon execution by the one or more processors, cause the one or more processors to: (Par. 0016: “Another implementation of the present disclosure is a system comprising one or more memory devices configured to store instructions thereon that, when executed by one or more processors, cause the one or more processors to receive a plurality of measurements for one or more points that are associated with a piece of building equipment, the plurality of measurements measured during a first time period; execute a machine learning model using the plurality of measurements as an input to generate fault data for a plurality of time periods subsequent to the first time period…”)
Huber also teaches feature vectors that are input to a machine learning model. (Par. 0041).
Osborn et al. (US PG Pub No. 20230072423) discloses some elements of claim 7, wherein the system alerts a user when the system has been trained or when further training is needed.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHAD G ERDMAN whose telephone number is (571)270-0177. The examiner can normally be reached Mon - Fri 7am - 3pm or 4pm EST..
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kenneth Lo can be reached at (571) 272-9774. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/CHAD G ERDMAN/ Primary Examiner, Art Unit 2116
1 Examiner’s Note – Specification Par. 0038 and 0054 teach that feature vectors are a combination of values that represent performance metrics, variable ranges, etc. Lakshmanan teaches this in paragraphs 0113 and 0114.
2 Examiner’s Note – Specification paragraph 0038 states in respect with derivative values: “The derivative values may comprise numeric values that represent various aspects of the operational data. For example, a set of derivative values may represent average operating temperatures indicated by the OEM data.” Thus Lakshmanan teaches the combination in the cited paragraphs.
