DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Specification
The use of the term Java, JavaScript etc, which is a trade name or a mark used in commerce, has been noted in this application. The term should be accompanied by the generic terminology; furthermore the term should be capitalized wherever it appears or, where appropriate, include a proper symbol indicating use in commerce such as ™, SM , or ® following the term.
Although the use of trade names and marks used in commerce (i.e., trademarks, service marks, certification marks, and collective marks) are permissible in patent applications, the proprietary nature of the marks should be respected and every effort made to prevent their use in any manner which might adversely affect their validity as commercial marks.
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.
Claim(s) 1-6, 8-13 and 15-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Nixon et al US 2024/0231333 in view of Nixon et al USPN 11256238.
Regarding claims 1, 8 and 15
Nixon et al teaches (‘333)
machine-readable instructions and programmable circuitry to at least one of instantiate or execute the machine-readable instructions to [0103] the NGPCAS 100 includes a compute fabric 102 communicatively connected to a plurality (e.g., a pool) of physical devices 105, 108. The plurality or pool of physical devices 105, 108 includes devices that perform physical functions utilized to control an industrial or automation process provided by an enterprise. For example, the plurality of physical devices 105, 108 may include field devices such as valves, valve positioners, actuators, switches, regulators, sensors, (e.g., temperature, pressure, level and flow rate sensors), spectrometric devices, pumps, motors, transmitters, and the like, some of which may be intelligent field devices. Some of the physical devices 105, 108 may have respective on-board processors, memories, and computer-executable instructions stored on the memories, where the stored computer-executable instructions are executable by the on-board processors to perform, for example, control and/or other types of calculations, alarming functions, and/or other functionality associated with controlling the industrial or automation process using the physical device 105, 108. Physical devices 105, 108 may responsively operate and/or change their behavior based on control signals and/or other instructions received from the compute fabric 102, as is described in more detail elsewhere herein];
import a device model for an industrial device [0260] FIG. 5D depicts an example EDID 562 that may be embedded on a hardware device. The EDID 562 may include only or at least a unique identifier 564. However, in instances in which the EDID 562 includes multiple pieces of information, the information may be stored on the device as a series of values. Example optional values (indicated by the dotted line boxes) that may be included in the EDID 562 include values indicative of: the owner/enterprise/customer 565 associated with the device, the model 566 of the device, a facility 567 associated with the device, a geographical region 568 associated with the device, a manufacturer 569 of the device, a registry 570 associated with the device, one or more options 571 present on the device, the manufacturing date 572 of the device, etc];
update the source code based on the device model [0090] the tool may determine that the process plant requires retuning in a manner that requires an updated copy of one or more control algorithms. In that event, the tool proceeds (with input from the operator) to create updated control algorithms. The updated control algorithms are instantiated in the compute fabric, but are not initially placed in control of the process plant. Instead, the updated control algorithms are implemented in parallel (e.g., in simulation mode) with the active control algorithms to ensure that they will not adversely affect the operation of the process plant and will, in fact, improve the operation of the process plant. The operator then switches control of the process to the new control algorithms instantaneously (e.g., without interrupting the process) when satisfied that the updated control modules will function properly];
generate an executable output of the source code [0106] as shown in FIG. 1A, the physical components 135, 138 at each location 115, 118 communicatively connect to the compute fabric 102 via one or more transport networks 130. The one or more networks 130 may include one or more wired and/or wireless networks. Further, the one or more networks 130 may typically include one or more packet networks, such as one or more Ethernet-compatible packet networks, each of which may or may not include an advanced physical layer (APL). As such, the physical I/O interfaces 125, 128 enable the I/O data or information generated by the physical devices 105, 108 to be delivered in packetized form via the one or more transport networks 130. For example, the physical I/O interfaces 125, 128 may convert the I/O data or information generated by the physical devices 105, 108 into packets, may wrap the I/O data or information in packets, or may otherwise transform the I/O data or information into a packetized format for delivery to the compute fabric 102 via the packet network(s) 130]. Nixon et al teaches (‘333) device model and source code but does not teach explicitly import source code for an industrial device however, Nixon et al teaches (‘238) (column 5, line 65, in any event, these other systems are, in many cases, dedicated systems that perform data collection, calculations and reporting in a manner that is separate from the process control system. In these cases, these systems require their own infrastructure, wiring, communication paths, communication protocols, etc. In some cases, such as in plant asset management systems, these systems may communicate with and use some or all of the process control field devices. However, in these instances, the applications, servers, or other data collection devices must communicate with the field devices via the process controller using the various specialized field device protocols and physical layers installed for the field devices, to obtain data from the field devices, to send messages to the field devices, and to perform other activities with respect to the field devices. Again, in these cases, the process controllers (and typically, one or more I/O devices) are involved in and are responsible for performing communications with the field devices to support these other systems, and the field devices themselves have no specific knowledge of or ability to directly support these other systems. This technique puts the process controller in the middle of and responsible for performing communications with the field devices to support other applications or uses besides process control, such as maintenance activities, continuous monitoring, metering, etc. This additional load can make the process controller less effective or can lead to lost or slow communications with a particular field device because the process controller needs to prioritize which communications are necessary or needed in any particular situation. Moreover, this situation makes the field devices much less effective at supporting multiple uses). Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate industrial device. The modification would have been obvious because one of ordinary skill in the art would have been motivated to combine teaching into generating device for industrial purpose improve efficiency, reduce costs, enhance safety, and enable predictive maintenance, while supporting scalable, data-driven operations.
Regarding claims 2, 9 and 16
Nixon et al teaches (‘238)
the executable output is an application binary (column 24, line 39, thus, as will be understood, the highly versatile field devices and field device network architectures described herein support a wide range of application scenarios. The data required in these scenarios is often different. In contrast to control applications, which require measurement parameters, unit codes, and status information, condition monitoring applications require information about the operation and health of the device. For example, for valves the control data includes the valve output value (also referred to as the target or valve set point) and its actual position along with their unit codes and status information. On the other hand, the valve condition monitoring data includes the valve set point, travel, drive, instrument air, travel percent per reversal, temperature and other measurements. The feature of providing binary… would be obvious for the reasons set forth in the rejection of claim 1.
Regarding claims 3, 10 and 17
Nixon et al teaches (‘333)
the executable output is a firmware for the industrial device [0376] when implemented in software, any of the applications, modules, etc. described herein may be stored in any tangible, non-transitory computer readable memory such as on a magnetic disk, a laser disk, solid state memory device, molecular memory storage device, or other storage medium, in a RAM or ROM of a computer or processor, etc. Although the example systems disclosed herein are disclosed as including, among other components, software and/or firmware executed on hardware, it should be noted that such systems are merely illustrative and should not be considered as limiting. For example, it is contemplated that any or all of these hardware, software, and firmware components could be embodied exclusively in hardware, exclusively in software, or in any combination of hardware and software. Accordingly, while the example systems described herein are described as being implemented in software executed on a processor of one or more computer devices, persons of ordinary skill in the art will readily appreciate that the examples provided are not the only way to implement such systems]. The feature of providing firmware…would be obvious for the reasons set forth in the rejection of claim 1.
Regarding claims 4, 11 and 18
Nixon et al teaches (’333)
the executable output is a device container image [0177] generally speaking, containerized or micro-encapsulated software components or MEEEs/granules (e.g., at the application layer 412, the HCI adaptor layer 430, and the software defined networking layer 410) are included in the set of containerized/micro-encapsulated components 140 of the NGPCAS 100 and, as such, are isolated from other containerized/micro-encapsulated services and applications (e.g., other containerized/micro-encapsulated components 140) that are executing on the same node Ny. As such, the terms “configured container,” “container image,” and “containerized component” are utilized interchangeably herein and, for ease of discussion but not for limitation purposes, are generally and categorically utilized herein to refer to any one or more suitable types of instantiated, micro-encapsulated execution environments or granules, such as software containers, virtual machines, software agents, scripts, functions, calls, actors (e.g., lightweight processes such as Erlang, Scala, Akka, etc.), unikernels (e.g., machine images which run on bare metal and contain all components necessary to execute an application, including the operating system component), other types of bare metal software (e.g., software running directly on hardware without any intermediate managing software, such as a hypervisor or other type of container/encapsulation manager), and/or other types of micro-encapsulated execution environments or granules]. The feature of providing container… would be obvious for the reasons set forth in the rejection of claim 1.
Regarding claims 5, 12 and 19
Nixon et al teaches (‘333)
the executable output includes an application toolchain [0071] a system provider provides and manages a compute fabric serving one or more enterprises, and provides a variety of tools and programs for configuring, commissioning, controlling, and monitoring one or more process plants using the compute fabric. These tools and programs include tools for configuring control modules and control strategies to control the process plant, tools for configuring operator workstations to monitor and control the process plant, tools for performing asset management (e.g., tracking calibration, maintenance, etc.), and tools for instantiating and managing the control modules that, after being configured and instantiated in the compute fabric, ultimately control process plant, among others. Each enterprise included in a plurality of enterprises accesses and makes use of the compute fabric and the available tools and programs to implement one or more enterprise-owned and/or -operated industrial processes in one or more respective process plants. Each of the process plants implements various aspects of its process control via a variety of containerized applications and services instantiated in the compute fabric. These include control algorithms, input-output, and security functions, among others, and the use of the containerized applications and services may facilitate various quality-of-service (QoS) features, including load balancing, fault tolerance, and redundancy implemented and managed by either the system provider or the enterprise, or by the enterprise with assistance from the provider.] The feature of providing tool… would be obvious for the reasons set forth in the rejection of claim 1.
Regarding claims 6, 13 and 20
Nixon et al teaches (‘333)
the source code is a generic device template application [0339] the enterprise explorer region 1032 further includes a template library explorer 1033 that allows the user to navigate between template objects, each of which may be usable to configure and arrange new instances of sites, process modules, field devices, control loops, I/O networks, etc. For example, by interacting with a bioreactor template shown in the library explorer 1033, the user may summon a “Create Unit Wizard” region 1034 enabling the user to define, from the preconfigured bioreactor template, a bioreactor to be configured for one or more of the physical sites of the enterprise as defined in the region 1032. The template for the bioreactor may, for example, define bioreactor properties such as process material inputs/outputs, operating parameters of the bioreactor, etc. Continuing from FIG. 10C, FIG. 10D depicts an example deployment GUI 1040 enabling the user to deploy a configured process entity to the compute fabric operated by the enterprise (e.g., to deploy a new bioreactor to one or more physical sites operated by the compute fabric as shown in FIG. 10C). The deployment GUI 1040 includes controls to enable the user to create new control modules associated with operation of the bioreactor (“create module,” e.g., to define operational setpoints, alarms, event handlers, historization of data, etc.)].
Allowable Subject Matter
Claims 7 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.
Relevant Prior Art
US 11644809 B2 Stump et al teaches the present disclosure is directed to systems, methods and devices for facilitating object-based cross-domain industrial automation control. An object library comprising a plurality of objects may be maintained. One or more of the objects may represent physical counterparts for use in an industrial automation process. Each object of the plurality of objects in the object library may have at least one property that an automated control device operation can be programmed to act on. Each object of the plurality of objects may also have at least one property that a human machine interface component can utilize in generating display elements corresponding to the objects for display on the human machine interface. When modifications to objects in the object library are received, those modifications may be automatically deployed and incorporated in controller logic and HMI graphics and control.
US 10761504 B2 Riedl teaches a method for modifying an industrial control program is provided, the industrial control program comprising a first program element having a safety classification and a second program element not having the safety classification. The method comprises: identifying, in program source code of the first program element, a call to the second program element, and generating a modified program source code, comprising replacing, in the program source code, the call to the second program element by an auxiliary program element, the auxiliary program element being compliant with the safety classification.
US 7233834 B2 McDonald, Jr. et al teaches disclosed are modeling and process control techniques for manufacturing products. More specifically, computer-aided modeling techniques are described that allow the manufacturer to predict a profile for a multivariate output that is necessary to achieve a target performance property for a manufactured product.
Ren et al teaches The Internet of Things (IoT) is revolutionizing the industry. Powered by pervasive embedded devices, the Industrial IoT (IIoT) provides a unique solution for retrieving and analyzing data near the source in real-time. Many emerging techniques, such as Tiny Machine Learning (TinyML) and Complex Event Processing (CEP), are actively being developed to support decision making at the edge, shifting the paradigm from centralized processing to distributed computing. However, distributed computing presents management challenges, as IoT devices are diverse and constrained, and their number is growing exponentially. The situation is even more challenging when various on-device applications (so-called artifacts) are deployed across decentralized IoT networks. Questions to be addressed include howto discover an appropriate function, whether that function can be executed on a certain device, and how to orchestrate a cross-platform service. To tackle these challenges, we propose an approach for the scalable management of on-device applications among distributed IoT devices. By leveraging theW3CWeb of Things (WoT), the capabilities of each IoT device, or more precisely, its interaction patterns, can be semantically expressed in a Thing Description (TD). In addition, we introduce semantic modeling of on-device applications to supplement an TD with additional information regarding applications on the device. Specifically, we demonstrate two examples of semantic modeling: neural networks (NN) and CEP rules. The ontologies are evaluated by answering a set of competency questions. By hosting the enriched semantic knowledge of the entire IoT system in a Knowledge Graph (KG), we can discover and interoperate edge devices and artifacts across the decentralized network.This can reduce fragmentation and increase the reusability of IoT components. We demonstrate the feasibility of our concept on an industrial workstation consisting of a conveyor belt and several IoT devices. Finally, the requirements for constructing an IoT semantic management system are discussed.
Langiu et al teaches Updating the software running on constrained IoT devices such as low-power sensors and actuators in a secure and efficient way is an open problem. The limited computational, memory, and storage capabilities of these devices, together with their small energy budget, indeed, restrict the number of features that can be embedded into an update system and make it also difficult to build a generic and compact solution. As a result, existing update systems for constrained IoT devices are often not portable, do not perform a proper verification of the downloaded firmware, or focus only on a single phase of the update process, which exposes them to security threats and calls for new solutions. In this paper we present UpKit, a portable and lightweight software update framework for constrained IoT devices encompassing all phases of the update process: from the generation and signature of a new firmware, to the transmission of the latter to an IoT device, its verification and installation. UpKit employs a novel update architecture that is agnostic to how new firmware images are distributed and that introduces a double-signature process to guarantee the
freshness of a new firmware. This, together with an additional verification step, allows also to reject invalid software at an early stage and to prevent an unnecessary reboot of thedevice. We keep UpKit’s design modular and provide an opensource implementation for several operating systems, hardware platforms, as well as cryptographic libraries. We further include support for differential updates and flexible memory slots, which allows to significantly increase the efficiency of the update process. An experimental evaluation shows that UpKit can be used to efficiently update highly-constrained IoT devices, and that it has a comparable memory footprint to state-of-theart solutions, despite the introduction of several features.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Anil Khatri whose telephone number is (571)272-3725. The examiner can normally be reached M-F 8:30-5:00.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Wei Zhen can be reached at 571-272-3708. 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.
/ANIL KHATRI/Primary Examiner, Art Unit 2191
Prosecution Insights