DETAILED ACTION
This Action is in response to the Preliminary Amendment for Application Number 18571470 received on 12/18/2023.
Claims 1-12 are presented for examination.
The effective filing date for this application is 6/18/2021.
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 § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 3, and 5-12 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 3 and 8 recite the limitation, “wherein the standardized interface is defined according to the VDI/VDE/NAMUR 2658 standard”. Since this standard includes multiple, evolving versions and has undergone revisions ( e.g. drafts vs official releases), the claim scope is unclear because it does not explicitly define which version/revision that the claim is referring.
Claim 5 recites the limitation, “wherein the service component has at least one interface to further service components for a superordinate automation function that accesses subordinate automation functions encapsulated in the further service component”. The limitation initially recites “further service components” (plural), and then later refers to “the further service component” (singular). As such, there is insufficient antecedent basis for this limitation in the claim. For examination purposes, the limitation will be interpreted to recite “the further service components”, in order to remain consistent with the preceding recitation.
Claim 6 recites an apparatus comprising “the at least one monitoring component” and “at least one service component”. The last limitation of claim 6 then describes the apparatus as being configurable. That is, the last limitation appears to recite what the apparatus can be used or function to do, but provides no structure of the apparatus to actually perform the function. It is therefore unclear how the function of configuring relates to the structure of claimed apparatus. Claims 7-12 are rejected for the same reasons by virtue of their dependencies to claim 6.
Claims 10, 11, and 12 each recite the limitation, “the associated monitoring component.” As there is no previous recitation of “an associated monitoring component”, there is insufficient antecedent basis for the limitation in the claims.
Claim 10 recites the limitation, “The apparatus of claim 6, wherein the at least one physical element and the associated monitoring component are implemented in a same controller, and communication takes place between the monitoring component and a control component using interfaces inside the controller”, which is found indefinite as to how the limitation affects the scope of the claimed “apparatus”. The limitation of claim 10 newly recites “a same controller” but there is no indication as to how this “same controller” relates, structurally to the “apparatus” of claim 6.
Claim 11 recites the limitation, “The apparatus of claim 6, wherein the at least one physical element and the associated monitoring component are not implemented in a same controller, and communication takes place between the monitoring component and a control component via a cross-controller interface using a provider/consumer approach”, which is found indefinite as to how the limitation affects the scope of the claimed “apparatus”. The limitation of claim 11 newly recites “a same controller” but there is no indication as to how this “same controller” relates to the “apparatus” of claim 6.
Claim 12 recites the limitation, “The apparatus of claim 6, wherein the at least one physical element and the associated monitoring component are not implemented in a same controller, and communication takes place between the monitoring component and a control component via a cross-controller interface”, which is found indefinite as to how the limitation affects the scope of the claimed “apparatus”. The limitation of claim 12 newly recites “a same controller” but there is no indication as to how this “same controller” relates to the “apparatus” of claim 6.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 6-12 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because claim 6 is directed to an “apparatus”, the apparatus comprising “the at least one monitoring component” and “at least one service component”, both of which cover software embodiments. As such, the claimed “apparatus” covers software embodiments. Claims 7-12 are rejected for the same reasons applied above.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-2, 4-7, and 9-12 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Chauvet et al. (US 20180024537).
Regarding claim 1, Chauvet disclosed a method in a distributed automation system comprising at least one physical element, for coupling functional control of the distributed automation system to the at least one physical element using at least one automation function (Chauvet, [0053], With respect to SDA technology, Chaubet disclosed, “The transformed OT architecture enables network configuration and automation function/application deployments on the fly at the system level through the use of virtualization (e.g., of services, applications) technologies, configurable devices and/or networking technologies.”; Chauvet disclosed SDA technology for simplifying deployment and configuration of automation functions and/or applications; [0056], Chauvet disclosed SDA architecture and standards enable the convergence of information technology (IT) and operational transformation (OT) systems; Chauvet [0054], Chauvet disclosed examples of physical elements that make up the automation architecture), wherein the distributed automation system comprises automation software that is subdivided into two parts, the two parts comprising hardware-specific logic for at least one monitoring component, and function-specific logic for at least one service component (Chauvet, [0068]-[0070], Chauvet disclosed smart connected devices that monitor and/or control devices, sensors, and/or actuators, the smart connected devices having firmware; see also [0080], “Controllers orchestrate and monitor some or all of the resources of the system”; [0098], Chauvet disclosed, “each type of equipment has its own specific software (also called tool or software tool) using which the equipment can be configured, parameterized and/or programmed”; See also [0099] in which Chauvet disclosed, through the SDA system, the user can see the entire machine 701 and process equipment 702, and can configure, parameterize and/or program those machine and process equipment 701, 702 without having to separately launch or invoke equipment type specific software; [0104] “functional unit template library 724; [0105], “a user can select an equipment from a topology view to parameterize. The parameterization component 728 can automatically launch a parameterization interface (e.g., menu) of a parameterization software associated with the equipment”; Paragraph [0105] also disclosed a programming component that launches a programming interface of a programming software associated with a selected equipment; [0110] fog server hosting compute nodes/VMs which can be a smart connected device; [0117], “the host management component 916 can utilize one or more host virtualization technologies to provide a virtualization infrastructure on which an automation system can be run and/or managed” and can “create virtualized instances of a device (e.g., software implementation of the device on a virtual machine), application or function in the automation system. The virtualized device runs as a software only instance in an environment that presents to the virtual device an abstraction of the physical hardware isolated from the host system.”), the method comprising:
abstracting functionality of the at least one physical element in a monitoring component and mapping a real interface of the at least one physical element to a previously standardized interface (Chauvet, Fig. 5, [0077], Chauvet disclosed the SDA system includes a control plane including controllers that provide a” standardized set of interfaces” to the applications in the application plane 575 to access and/or manage the resources in the resource plane 582 of the system; That is, these controllers provide the interface for the physical elements of the resource plane to be interfaced with the SDA system, and therefore map the physical element’s interface(s) to the standardized interfaces, such that the physical elements/resources can be programmed/configured via the SDA; See also Fig. 7A which “is a block diagram illustration interaction between solution software and automation equipment in traditional automation systems and in the SDA environment” and [0097]-[0105] in providing a common framework 742 to interface between the SDA and Equipment; [0117], “the host management component 916 can utilize one or more host virtualization technologies to provide a virtualization infrastructure on which an automation system can be run and/or managed” and can “create virtualized instances of a device (e.g., software implementation of the device on a virtual machine), application or function in the automation system. The virtualized device runs as a software only instance in an environment that presents to the virtual device an abstraction of the physical hardware isolated from the host system.” See also [0136]);
assigning the at least one physical element to a placeholder having a same standardized interface as the at least one physical element (Chauvet, [0110], Chauvet disclosed compute nodes executing hosts which can be VMs, and can execute a guest that includes an application or application function or any software implementation of a physical device, component, or functional unit, to which the compute nodes provide connectivity between the virtualized entities and the physical world. In some embodiments, a compute node can be a smart connected device, which can have a physical part and a virtual part. For example, the compute node 820-N can be a smart connected device 815 which can execute a host 802-B running a guest 804. The same smart connected device 815 can also have a physical sensor/actuator 814. The compute node 820-N as other compute nodes can connect to the data/OT network 865.”; See [0117], “the host management component 916 can utilize one or more host virtualization technologies to provide a virtualization infrastructure on which an automation system can be run and/or managed” and can “create virtualized instances of a device (e.g., software implementation of the device on a virtual machine), application or function in the automation system. The virtualized device runs as a software only instance in an environment that presents to the virtual device an abstraction of the physical hardware isolated from the host system.”; That is, Chauvet disclosed assigning a virtualized instance i.e. placeholder, to a physical device, for interfacing with that physical device, to allow for the management/configuration of the device via the SDA, as explained above);
encapsulating the at least one automation function in a service component having at least a first interface to the at least one physical element and at least one further communication interface (Chauvet, [0117], “the host management component 916 can utilize one or more host virtualization technologies to provide a virtualization infrastructure on which an automation system can be run and/or managed” and can “create virtualized instances of a device (e.g., software implementation of the device on a virtual machine), application or function in the automation system. The virtualized device runs as a software only instance in an environment that presents to the virtual device an abstraction of the physical hardware isolated from the host system.”; See [0084] a “virtualized component is a logical equivalent of a physical device or a portion of the physical device it represents, implemented as a software entity to run inside of the fog server 605. Virtualized components 645 can also include software components such as applications and/or application functions on a host“; [0086] virtualized component management); and
communicating between the at least one physical element and the service component or the placeholder (Chauvet, [0117], “the host management component 916 can utilize one or more host virtualization technologies to provide a virtualization infrastructure on which an automation system can be run and/or managed” and can “create virtualized instances of a device (e.g., software implementation of the device on a virtual machine), application or function in the automation system. The virtualized device runs as a software only instance in an environment that presents to the virtual device an abstraction of the physical hardware isolated from the host system.” [0145], Chauvet disclosed, “After the functional unit has been created or provisioned and the networking infrastructure is configured accordingly, the system software can then be used to configure and program the components of the functional unit” and “In some embodiments, configuring the functional unit can also include configuring the associated physical components of the functional unit”; See also [0148]-[0149] describing the configuration of components and the utilization of the network subsystem in which the “fog server subsystem utilizes the physical and/or virtual network components to communicate with physical components (e.g., field devices) of the automation system to control operation and management of the automation system”),
wherein a physical element of the at least one physical element is configurable at any time during a runtime of the distributed automation system using a communication interface (Chauvet, [0053], “The transformed OT architecture enables network configuration and automation function/application deployments on the fly“; [0129], “The configuring component 908 can facilitate configuration of the virtualized instances and/or physical devices under the management of the fog server.“; It is evident that such configuration utilizes a communication interface of the network subsystem).
Regarding claim 2, Chauvet disclosed the method of claim 1, wherein the at least one physical element comprises functionality of a sensor or an actuator in the distributed automation system (Chauvet, [0002] “automation devices including field devices including sensors and actuators”; see also [0049], [0058] or [0059] or [0183] “sensors” and “actuators”).
Regarding claim 4, Chauvet disclosed the method of claim 1, wherein the communication interface operates according to the OPC UA standard (Chauvet, [0072], “OPC UA”).
Regarding claim 5, Chauvet disclosed the method of claim 1, wherein the service component has at least one interface to further service components for a superordinate automation function that accesses subordinate automation functions encapsulated in the further service component (Chauvet, [0110], “Each of the compute nodes 820-1, 820-2, 820-3, . . . , 820-N can execute a number of hosts 802-1, . . . , 802-N and associated virtual networks 820. These hosts can be virtual machines, containers or bare metals. Each host in turn can execute a guest 804. A guest 804 can include an application, an application function (i.e., a piece or portion of an application corresponding to or performing a function), or any software implementation of a physical device, component or functional unit. In some embodiments, a host 802-1 can execute another host 802-A which in turn can run a guest. For example, the host 802-1 of compute node 820-3 can be a virtual machine on which a container 802-A is instantiated to run guest 804. The virtual networks 820 connect from within the compute nodes (e.g., 820-1, 820-2, . . . ) through external interfaces (e.g., Ethernet ports) to the external physical networks (e.g., Data/OT network 865).”; The limitation “for a superordinate automation function that accesses subordinate automation functions encapsulated in the further service component” amounts to a limitation of intended use).
Regarding claim 6, Chauvet disclosed an apparatus for coupling functional control in a distributed automation system using at least one automation function in the distributed automation system comprising physical elements (Chauvet, [0053], With respect to SDA technology, Chaubet disclosed, “The transformed OT architecture enables network configuration and automation function/application deployments on the fly at the system level through the use of virtualization (e.g., of services, applications) technologies, configurable devices and/or networking technologies.”; Chauvet disclosed SDA technology for simplifying deployment and configuration of automation functions and/or applications; [0056], Chauvet disclosed SDA architecture and standards enable the convergence of information technology (IT) and operational transformation (OT) systems; [0054], Chauvet disclosed examples of physical elements that make up the automation architecture), wherein the distributed automation system comprises automation software that is subdivided into two parts, the two parts comprising hardware-specific logic for at least one monitoring component, and function-specific logic for at least one service component (Chauvet, [0068]-[0070], Chauvet disclosed smart connected devices that monitor and/or control devices, sensors, and/or actuators, the smart connected devices having firmware; see also [0080], “Controllers orchestrate and monitor some or all of the resources of the system”; [0098], Chauvet disclosed, “each type of equipment has its own specific software (also called tool or software tool) using which the equipment can be configured, parameterized and/or programmed”; See also [0099] in which Chauvet disclosed, through the SDA system, the user can see the entire machine 701 and process equipment 702, and can configure, parameterize and/or program those machine and process equipment 701, 702 without having to separately launch or invoke equipment type specific software; [0104] “functional unit template library 724; [0105], “a user can select an equipment from a topology view to parameterize. The parameterization component 728 can automatically launch a parameterization interface (e.g., menu) of a parameterization software associated with the equipment”; Paragraph [0105] also disclosed a programming component that launches a programming interface of a programming software associated with a selected equipment; [0110] fog server hosting compute nodes/VMs which can be a smart connected device; [0117], “the host management component 916 can utilize one or more host virtualization technologies to provide a virtualization infrastructure on which an automation system can be run and/or managed” and can “create virtualized instances of a device (e.g., software implementation of the device on a virtual machine), application or function in the automation system. The virtualized device runs as a software only instance in an environment that presents to the virtual device an abstraction of the physical hardware isolated from the host system.”), the apparatus comprising:
the at least one monitoring component that comprises an abstraction of functionality of at least one physical element of the physical elements and a mapping of a real interface of the at least one physical element to a previously standardized interface (Chauvet, Fig. 5, [0077], Chauvet disclosed the SDA system includes a control plane including controllers that provide a” standardized set of interfaces” to the applications in the application plane 575 to access and/or manage the resources in the resource plane 582 of the system; That is, these controllers provide the interface for the physical elements of the resource plane to be interfaced with the SDA system, and therefore map the physical element’s interface(s) to the standardized interfaces, such that the physical elements/resources can be programmed/configured via the SDA; See also Fig. 7A which “is a block diagram illustration interaction between solution software and automation equipment in traditional automation systems and in the SDA environment” and [0097]-[0105] in providing a common framework 742 to interface between the SDA and Equipment; [0117], “the host management component 916 can utilize one or more host virtualization technologies to provide a virtualization infrastructure on which an automation system can be run and/or managed” and can “create virtualized instances of a device (e.g., software implementation of the device on a virtual machine), application or function in the automation system. The virtualized device runs as a software only instance in an environment that presents to the virtual device an abstraction of the physical hardware isolated from the host system.” See also [0136]),
wherein the at least one physical element is assignable to a placeholder having a same standardized interface as the at least one physical element (Chauvet, [0110], Chauvet disclosed compute nodes executing hosts which can be VMs, and can execute a guest that includes an application or application function or any software implementation of a physical device, component, or functional unit, to which the compute nodes provide connectivity between the virtualized entities and the physical world. In some embodiments, a compute node can be a smart connected device, which can have a physical part and a virtual part. For example, the compute node 820-N can be a smart connected device 815 which can execute a host 802-B running a guest 804. The same smart connected device 815 can also have a physical sensor/actuator 814. The compute node 820-N as other compute nodes can connect to the data/OT network 865.”; See [0117], “the host management component 916 can utilize one or more host virtualization technologies to provide a virtualization infrastructure on which an automation system can be run and/or managed” and can “create virtualized instances of a device (e.g., software implementation of the device on a virtual machine), application or function in the automation system. The virtualized device runs as a software only instance in an environment that presents to the virtual device an abstraction of the physical hardware isolated from the host system.”; That is, Chauvet disclosed assigning a virtualized instance i.e. placeholder to a physical device, for interfacing with that physical device, to allow for the management/configuration of the device via the SDA, as explained above);
encapsulating the at least one automation function in a service component having at least a first interface to the at least one physical element and at least one further communication interface (Chauvet, [0117], “the host management component 916 can utilize one or more host virtualization technologies to provide a virtualization infrastructure on which an automation system can be run and/or managed” and can “create virtualized instances of a device (e.g., software implementation of the device on a virtual machine), application or function in the automation system. The virtualized device runs as a software only instance in an environment that presents to the virtual device an abstraction of the physical hardware isolated from the host system.”); and
at least one service component that has an encapsulation of the at least one automation function and comprises at least one interface to the at least one physical element and at least one further communication interface that enables communication between the at least one physical element and the at least one service component (Chauvet, [0117], “the host management component 916 can utilize one or more host virtualization technologies to provide a virtualization infrastructure on which an automation system can be run and/or managed” and can “create virtualized instances of a device (e.g., software implementation of the device on a virtual machine), application or function in the automation system. The virtualized device runs as a software only instance in an environment that presents to the virtual device an abstraction of the physical hardware isolated from the host system.”; [0145], Chauvet disclosed, “After the functional unit has been created or provisioned and the networking infrastructure is configured accordingly, the system software can then be used to configure and program the components of the functional unit” and “In some embodiments, configuring the functional unit can also include configuring the associated physical components of the functional unit”; See also [0148]-[0149] describing the configuration of components and the utilization of the network subsystem in which the “fog server subsystem utilizes the physical and/or virtual network components to communicate with physical components (e.g., field devices) of the automation system to control operation and management of the automation system”),
wherein the apparatus is configurable at any time during runtime of the distributed automation system using a communication interface (Chauvet, [0053], “The transformed OT architecture enables network configuration and automation function/application deployments on the fly“; [0129], “The configuring component 908 can facilitate configuration of the virtualized instances and/or physical devices under the management of the fog server.“; It is evident that such configuration utilizes a communication interface of the network subsystem).
Regarding claim 7, Chauvet disclosed the apparatus of claim 6, wherein the at least one physical element comprises functionality of a sensor or an actuator in the distributed automation system (Chauvet, [0002] “automation devices including field devices including sensors and actuators”; see also [0049], [0058] or [0059] or [0183] “sensors” and “actuators”).
Regarding claim 9, Chauvet disclosed the apparatus of claim 6, wherein the communication interface operates according to the OPC UA standard (Chauvet, [0072], “OPC UA”).
Regarding claim 10, Chauvin disclosed the apparatus of claim 6, wherein the at least one physical element and the associated monitoring component are implemented in a same controller, and communication takes place between the monitoring component and a control component using interfaces inside the controller (Chauvet, Fig 8, 820-N, Smart Connected Device 815; [0047], [0068], [0070], [0082], Chauvet disclosed “smart connected devices” that incorporate both the physical element and monitoring component; See [0110], “The virtual networks 820 connect from within the compute nodes (e.g., 820-1, 820-2, . . . ) through external interfaces (e.g., Ethernet ports) to the external physical networks (e.g., Data/OT network 865). Virtual networks 820 reside inside the compute nodes (e.g., 820-1, 820-2, . . . ) and provide connectivity between the virtualized entities and the physical world. In some embodiments, a compute node can be a smart connected device, which can have a physical part and a virtual part. For example, the compute node 820-N can be a smart connected device 815 which can execute a host 802-B running a guest 804. The same smart connected device 815 can also have a physical sensor/actuator 814.“; The smart connected device includes both physical and virtual parts interfaced with each other within the smart device; See above citations for communications therebetween).
Regarding claim 11, Chauvin disclosed the apparatus of claim 6, wherein the at least one physical element and the associated monitoring component are not implemented in a same controller, and communication takes place between the monitoring component and a control component via a cross-controller interface using a provider/consumer approach (Chauvet, Fig 8, 820-1 through 820-3, [0110], Chauvet disclosed, “The virtual networks 820 connect from within the compute nodes (e.g., 820-1, 820-2, . . . ) through external interfaces (e.g., Ethernet ports) to the external physical networks (e.g., Data/OT network 865). Virtual networks 820 reside inside the compute nodes (e.g., 820-1, 820-2, . . . ) and provide connectivity between the virtualized entities and the physical world).
Regarding claim 12, Chauvin disclosed the apparatus of claim 6, wherein the at least one physical element and the associated monitoring component are not implemented in a same controller, and communication takes place between the monitoring component and a control component via a cross-controller interface (Chauvet, Fig 8, 820-1 through 820-3, [0110], Chauvet disclosed, “The fog server is comprised of a control and management infrastructure called the controller nodes 810-1, 810-2 along with the associated compute nodes 820-1, 820-2, 820-3, . . . , 820-N. Each of the compute nodes 820-1, 820-2, 820-3, . . . , 820-N can execute a number of hosts 802-1, . . . , 802-N and associated virtual networks 820. These hosts can be virtual machines, containers or bare metals. Each host in turn can execute a guest 804. A guest 804 can include an application, an application function (i.e., a piece or portion of an application corresponding to or performing a function), or any software implementation of a physical device, component or functional unit. In some embodiments, a host 802-1 can execute another host 802-A which in turn can run a guest. For example, the host 802-1 of compute node 820-3 can be a virtual machine on which a container 802-A is instantiated to run guest 804.” Chauvet also disclosed, “The virtual networks 820 connect from within the compute nodes (e.g., 820-1, 820-2, . . . ) through external interfaces (e.g., Ethernet ports) to the external physical networks (e.g., Data/OT network 865). Virtual networks 820 reside inside the compute nodes (e.g., 820-1, 820-2, . . . ) and provide connectivity between the virtualized entities and the physical world; See also Fig. 5, SDA communication involves utilization of communication between the resource plane and the application via a cross-controller interface).
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.
Claim(s) 3 and 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chauvet et al. (US 20180024537) in view of Badar et al., "Intelligent Edge Control with Deterministic-IP based Industrial Communication in Process Automation," 2019 15th International Conference on Network and Service Management (CNSM), Halifax, NS, Canada, 2019, pp. 1-7, doi: 10.23919/CNSM46954.2019.9012680.
Regarding claims 3 and 8, Chauvet disclosed the method of claim 1 and apparatus of claim 6, but did not explicitly disclose wherein the standardized interface is defined according to the VDI/VDE/NAMUR 2658 standard.
Badar disclosed the utilization of the automation of a production module using VDI/VDE/NAMUR 2658 and is thus a Module Type Package (MTP) [23] compliant Production Module. That is Badar disclosed that the utilization of the VDI/VDE/NAMUR 2658 standard was well known at the time the invention was filed.
Therefore it would have been obvious to one of ordinary skill in the art at the time the invention was filed to utilize the VDI/VDE/NAMUR 2658 standard, as disclosed by Badar, for the standard interface in Chauvet, thereby allowing seamless software integration into modular production plants.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JERRY B DENNISON whose telephone number is (571)272-3910. The examiner can normally be reached M-F 8:30-5:50.
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, Hadi Armouche can be reached at 571-270-3618. 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.
/JERRY B DENNISON/Primary Examiner, Art Unit 2409