DETAILED ACTION
Claims 1-40 (filed 06/11/2024) have been considered in this action. Claims 1-40 are newly filed.
Specification
The disclosure is objected to because of the following informalities:
Paragraph [0009] ends in an incomplete transitional phrase “between field devices and other devices and/or”
Paragraph [0038] contains an acronym “PA-DIM” without fully expanding the meaning of the acronym and thus its meaning is unclear
Appropriate correction is required.
Claim Objections
Claim 10 is objected to because of the following informalities:
The limitation “obtain attachments from target device ” is missing the article “a” or “the”
Claim 20 is objected to because of the following informalities:
The phrase “another element” is misspelled in the claim as “anther element”
Claim 24 is objected to because of the following informalities:
The limitation “web-based communication paradigm to communicate with communication interface” is missing a transitional word such as “a” or “the” before communication interface
Claim 29 is objected to because of the following informalities:
The limitation “storing a device package a computer readable medium” is missing the article “in”
The limitation “communicating from user interface engine” is missing the article “the” to refer to antecedent basis of the user interface engine previously established
Appropriate correction is required.
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 1-28 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.
Claim 1 recites the limitation "the computer readable medium" in the limitations describing the host device. There is insufficient antecedent basis for this limitation in the claim. As is claimed, “the computer readable medium” is a component of the device package, not the host device as claimed, and thus the host device does not have a “computer readable medium” from which antecedent basis can be used. It is unclear if “the computer readable medium” is intended to refer to the “computer readable memory” of the host device or not as the use of antecedent basis would suggest it is intended to refer to “the computer readable memory” of the host device and not the “computer readable medium” of the device engine. It is unclear how the computer readable medium and computer readable memory are related, as their functionality is seemingly separate yet are used improperly as interchangeable by the claim. In other words, the relationship between host device and “the computer readable medium” is unclear because “the computer readable medium” is recited as being a part of the device package, not the host device. Similarly claim 16 refers to “the computer readable medium” when limiting the host device while instead claiming the host system includes “one or more computer readable memories”.
Claims 2-15 and 17-28 are dependent upon claims 1 and 16 respectively, and thus inherit the rejection of claims 1 and 16 under 35 U.S.C. 112(b).
Claims 16-28 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.
Claim 16 recites the limitation "the processor" in limitations defined after the symbol (2) and (3). There is insufficient antecedent basis for this limitation in the claim. For the sake of compact prosecution, the examiner shall consider “the processor” as one of the one or more processors in the host device.
Claims 17-28 are dependent upon claim 16, and thus inherit the rejection of claim 16 under 35 U.S.C. 112(b).
Claim 2 is 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.
Claim 2 recites “the user interface rendering programming” and “the user interface logic” in its only limitation. There is insufficient antecedent basis for this limitation in the claim. It is unclear if “the user interface rendering programming” and “the user interface logic” is in reference to the first target device or second target device. It is unclear if this is intended to reference “user interface rendering programming and user interface logic for a second target device” because antecedent basis is not utilized properly.
Claims 6-7, 20 and 34 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 6, 20 and 34 each recites the limitation "the another element" and “the web based server” in their respective limitations. There is insufficient antecedent basis for this limitation in the claim. There is no previously established “another element” or “web based server” in any of the claims or independent claims upon which these claims are dependent. It is unclear how antecedent basis is to be interpreted.
Claim 7 is dependent upon claim 6, and thus inherits the rejection of claim 6 under 35 U.S.C. 112(b).
Claims 29-40 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.
Claim 29 recites “providing the device package to a host device including a computer readable memory, a processor and a graphical user interface terminal;”. It is unclear what the scope of this limitation is as the claim language alone does not clearly define whether the provided device package includes the computer readable memory, a processor and a graphical user interface, or if the host device itself includes the computer readable memory, a processor and a graphical user interface terminal. In other words, the ‘including’ phrase is not clearly established as having definite meaning in the claim. Both interpretations are valid but contradictory in their scope, and thus the scope of the claim is unclear. For the sake of compact prosecution, the examiner shall consider the including to modify the host device, so that the host device must include computer readable memory, a processor and a graphical user interface.
Claims 30-40 are dependent upon claim 29, and thus inherit the rejection of claim 29 under 35 U.S.C. 112(b).
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.
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.
Claim(s) 1, 2, 5, 29, 30, 33, 40 are rejected under 35 U.S.C. 103 as being unpatentable over Takeuchi (“General Information of FDT2 and FDI”, hereinafter Takeuchi) in view of Blevins et al. (WO 2005109124, hereinafter Blevins).
In regards to Claim 1, Takeuchi teaches “A device integration system for use in supporting a target device via an external communication link, the target device including a device engine having a device model and device operational logic wherein the device engine implements the device operational logic using the device model to control interactions with the target device, the device integration system comprising:” (Fig. 4 shows simplified system architecture with ethernet network connection and Profibus/hart connections; target device is not positively recited as a limiting part of the device integration system and is claimed as intended use and thus does not need to be shown via prior art) “a device package stored on a computer readable medium, the device package including user interface rendering programing and user interface logic for the target device;” ([page 934, abstract] FDI adopted device information model defined in OPC-UA, so that FDI client can access device model in the FDI server in the uniform way. The programmed user interface is defined in FDI as user interface plug-in (UIP) where some of host interfaces are derived from FDT2 specification [pg 937, col 2] The FDI package consists of Package Catalog, EDD, User Interface Plug-in and Attachment as shown inFigure 5. EDD is a binary file tokenized from EDDL descriptions. EDD has logically Device Definition, User Interface Description and Business Logic. The Device Definition provides definitions of variables and their attributes. The User Interface Description has menus and their presentation attributes shown in user interface. The Business Logic is used for relationship between variables and some methods; wherein user interface plug-in is a user interface rendering programing and business logic is user interface logic and package relates to a data object which obviously must be stored in some form of memory to exist) “a host device including a computer readable memory, a processor and a graphical user interface terminal” ([page 938 col 1] FDI host has server/client architecture as shown in Figure 6 where the FDI server consumes the Device Definition to create the Information Model and the Business Logic to make device data consistent and the FDI client consumes the User Interface Description and optional User Interface Plug-ins....FDI specification defines hosting services and UIP services. The hosting services are provided by the FDI client for use by the UIP such as save or load user settings, show message box or progress bar, open another UIP. UIP services are used by FDI client to control UIP such as activate or deactivate UIP and interaction of user action buttons. Some of these services use the same interface as defined in FDT2 specification. Their underlying technology is based on .NET for running environment and uses .NET data type for data exchange. [page 936 col 2] a host computer has Ethernet card to be used for initiation of field communication; wherein the host is a computer, and thus has processor and memory) “the host device further including, (1) a user interface engine stored in the computer readable medium and implemented on the processor to enable a user to communicate with the target device” ([page 935 col 1] Device DTM and communication DTM are used together to perform device communications. Between these DTMs there is protocol dependent information exchanged and FDT specification provides protocol annex for each protocol to define protocol specific profile (See Figure 2). [page 936 col 1] DTM business logic and DTM user interface can be placed in the separate PCs, where DTM business logic runs on the server machine and DTM user interface runs on client machine; wherein servers and clients are types of computers with memory (computer readable medium) and processor) “the user interface engine using the user interface rendering programming provided by the device package to render images on the graphical user interface terminal and using the user interface logic provided by the device package to control the operation of the user interface engine for communicating with the target device;” ([page 934 abstract] The programmed user interface is defined in FDI as user interface plug-in (UIP) where some of host interfaces are derived from FDT2 specification. EDDL descriptive application and optional UIP are packed into a single file entity as FDI device package, which will be consumed by FDI host application...A small FDI host application that consumes FDI device package is also a kind of device application and it can be wrapped into a DTM. Such DTM will be hosted by FDT2 Frame Application and execute device application provided with FDI device package. FDT2 Frame Application can host not only DTMs but also FDI device package using respective supporting DTM. [page 937 col 2] The FDI package consists of Package Catalog, EDD, User Interface Plug-in and Attachment as shown in Figure 5. EDD is a binary file tokenized from EDDL descriptions. EDD has logically Device Definition, User Interface Description and Business Logic. The Device Definition provides definitions of variables and their attributes. The User Interface Description has menus and their presentation attributes shown in user interface. The Business Logic is used for relationship between variables and some methods. The User Interface Plug-in is UI application based on FDT2 technology to provide advanced functions. The attachment can contain protocol specific file such as GSD file for PROFIBUS and CFF file for FOUNDATION fieldbus. It can also contain bitmaps used in the user interface and optionally device instruction manual and datasheets; wherein bitmaps are known image types) “and (2) a communication interface coupled to the user interface engine implemented on the processor that implements a communication paradigm that uses an information model that models field device data from multiple different field device communication protocols and that communicates using the communication paradigm over the external communication link” ([page 935 col 1] FDT specification is protocol independent between FDT Frame Application and DTM. A DTM can represent not only field devices but also communication interface devices including communication gateways. Device DTM and communication DTM are used together to perform device communications. Between these DTMs there is protocol dependent information exchanged and FDT specification provides protocol annex for each protocol to define protocol specific profile (See Figure 2). FDT has 16 protocol annexes for not only process automation but also factory automation communication protocols. Currently the following protocols are available; HART, PROFIBUS, PROFINET, FOUNDATION fieldbus, Modbus, IO-Link, CANopen, EtherCAT, Interbus, Sercos, CC-Link, DeviceNet, ControlNet, CompoNet, Ethernet/IP and ISA100.11a. [page 936 col 2] a host computer has Ethernet card to be used for initiation of field communication. A DTM for this Ethernet communication hardware is added at first. The Ethernet card sends data packets to a communication gateway where data packets are delivered to a PROFIBUS network. A DTM for the Ethernet/PROFIBUS gateway is added under the Ethernet communication DTM; [page 937 col 2] The attachment can contain protocol specific file such as GSD file for PROFIBUS and CFF file for FOUNDATION fieldbus. wherein the actually used protocol of the various protocols is the communication paradigm, and ethernet is the external communication link) “wherein the user interface engine of the host device communicates with the target device during online operation of the target device via the external communication link using the communication interface and the communication paradigm” ([page 937 col 1] The HART device DTM sends HART command to the PROFIBUS/HART gateway and the command is encapsulated into PROFIBUS data packet to be passed to the Ethernet/PROFIBUS gateway DTM. The gateway DTM wraps the packet with Ethernet data frame and
then pass it to the Ethernet communication DTM. From the HART device DTM to the Ethernet communication DTM, a HART command is relayed through the DTM objects. The Ethernet communication DTM initiates physical communication to pass the data packet to Ethernet port. From this point the data packet moves into the right side of the Figure 4 and then passed through the gateways and finally the HART command reaches the HART device. Response data initiated by the HART device is passed in the revise way through the gateways to reach the
Ethernet communication DTM and then passed; wherein commands imply the device being online).
Takeuchi fails to explicitly teach “a host device including … and a graphical user interface terminal”.
Blevins teaches “a host device including … and a graphical user interface terminal” ([0042] In the process plant 10 of Fig. 1, the workstation 20 includes a suite of operator interface applications and other data structures 32 which can be accessed by any authorized user (sometimes referred to herein as a configuration engineer and sometimes as an operator, although other types of users may exist as described herein below in connection with display layers customized for user type) to view and provide functionality with respect to devices, units, etc. connected within the process plant 10. The suite of operator interface applications 32 is stored in a memory 34 of the workstation 20 and each of the applications or entities within the suite of applications 32 is adapted to be executed on a processor 36 associated with the workstation 20. While the entire suite of applications 32 is illustrated as being stored in the workstation 20, some of these applications or other entities could be stored in and executed in other workstations or computer devices within or associated with the plant 10…. the suite of applications can provide display outputs to a display screen 37 associated with the workstation 20 or any other desired display screen or display device, including hand-held devices, laptops, other workstations, printers, etc.; [0102] The determination of which content layer to depict may be made by the execution engine 48 or the processor of any workstation or other device with access to the network, including, for instance, a rendering engine associated with a display device on which the process graphic display will be rendered. In this manner, the same display device (e.g., a handheld computer) may be utilized by different personnel that call for different content layers to be displayed).
It would have been obvious to a person having ordinary skill in the art before the effective file date of the claimed invention to have modified the system for device integration of a target device using a host/client that executes a user interface engine from packaged user interfaces for the target device as taught by Takeuchi with the use of a screen/terminal for displaying the user interface elements as taught by Blevins, because to PHOSITA, Takeuchi suggests such desires to display the user interface plug-in elements for the target device for user interaction because while not explicitly ever stating it because Takeuchi assumes the are in conversation with PHOSITA, which would not need such trivial details explicitly stated. Furthermore, both Takeuchi and Blevins relate in that they are system for supplying user interfaces for field devices, thus by using the display screen on the host/client of Blevins, it would be expected to improve the host/client of Takeuchi to actually display the user interface elements.
In regards to Claim 2, the combination of Takeuchi and Blevins teaches the device integration system as incorporated by claim 1 above. Takeuchi further teaches “The device integration system of claim 1, wherein the target device is a first target device, and further comprising, a second device package stored on a computer readable medium, the second device package including user interface rendering programing and user interface logic for a second target device different than the first target device and wherein the host device includes a second user interface engine implemented on the processor to enable a user to communicate with the second target device, the second user interface engine using the user interface rendering programming and the user interface logic of the second device package to render images on the graphical user interface terminal and to control the operation of the second user interface engine for communicating with the second target device using the communication interface and the communication paradigm” (Fig. 4 shows simplified system architecture with two supported devices, D using Profibus and E using HART and thus each would be expected to operate in the same way in relation to claim 1 albeit using different communication interfaces/protocols).
In regards to Claim 5, the combination of Takeuchi and Blevins teaches the device integration system as incorporated by claim 1 above. Takeuchi further teaches “The device integration system of claim 1, wherein the host device imports the user interface rendering programing and the user interface logic for the target device without importing a device engine that simulates the operation of the target device” ([page 934 abstract] A device application can be described in EDDL for its device profiles such as device parameters, simple methods and business logics in plain text format. FDI added an extension to support programmed user interface where EDDL is not enough to provide such functions and presentations. FDI adopted device information model defined in OPC-UA, so that FDI client can access device model in the FDI server in the uniform way. The programmed user interface is defined in FDI as user interface plug-in (UIP) where some of host interfaces are derived from FDT2 specification. EDDL descriptive application and optional UIP are packed into a single file entity as FDI device package, which will be consumed by FDI host application; wherein Takeuchi makes no reference of a simulation, and thus none is imported).
In regards to Claim 29, Takeuchi teaches “A method for performing device communication and configuration activities with respect to a target device via an external communication link, the target device including a device engine having a device model and device operational logic wherein the device engine implements the device operational logic using the device model to control interactions with the target device, the method comprising:” (Fig. 4 shows simplified system architecture with ethernet network connection and Profibus/hart connections; target device is not positively recited as a limiting part of the device integration method and is claimed as intended use and thus does not need to be shown via prior art) “storing a device package a computer readable medium, the device package including user interface rendering programing and user interface logic for the target device” ([page 934, abstract] FDI adopted device information model defined in OPC-UA, so that FDI client can access device model in the FDI server in the uniform way. The programmed user interface is defined in FDI as user interface plug-in (UIP) where some of host interfaces are derived from FDT2 specification [pg 937, col 2] The FDI package consists of Package Catalog, EDD, User Interface Plug-in and Attachment as shown inFigure 5. EDD is a binary file tokenized from EDDL descriptions. EDD has logically Device Definition, User Interface Description and Business Logic. The Device Definition provides definitions of variables and their attributes. The User Interface Description has menus and their presentation attributes shown in user interface. The Business Logic is used for relationship between variables and some methods; wherein user interface plug-in is a user interface rendering programing and business logic is user interface logic and package relates to a data object which obviously must be stored in some form of memory to exist) “providing the device package to a host device including a computer readable memory, a processor and a graphical user interface terminal;” (([page 938 col 1] FDI host has server/client architecture as shown in Figure 6 where the FDI server consumes the Device Definition to create the Information Model and the Business Logic to make device data consistent and the FDI client consumes the User Interface Description and optional User Interface Plug-ins....FDI specification defines hosting services and UIP services. The hosting services are provided by the FDI client for use by the UIP such as save or load user settings, show message box or progress bar, open another UIP. UIP services are used by FDI client to control UIP such as activate or deactivate UIP and interaction of user action buttons. Some of these services use the same interface as defined in FDT2 specification. Their underlying technology is based on .NET for running environment and uses .NET data type for data exchange. [page 936 col 2] a host computer has Ethernet card to be used for initiation of field communication; wherein the host is a computer, and thus has processor and memory) “executing a user interface engine on the host device that enables a user to communicate with the target device using the user interface rendering programming provided by the device package to render images on the graphical user interface terminal and using the user interface logic provided by the device package to control the operation of the user interface engine for communicating with the target device” (page 935 col 1] Device DTM and communication DTM are used together to perform device communications. Between these DTMs there is protocol dependent information exchanged and FDT specification provides protocol annex for each protocol to define protocol specific profile (See Figure 2). [page 936 col 1] DTM business logic and DTM user interface can be placed in the separate PCs, where DTM business logic runs on the server machine and DTM user interface runs on client machine; wherein servers and clients are types of computers with memory (computer readable medium) and processor; [page 934 abstract] The programmed user interface is defined in FDI as user interface plug-in (UIP) where some of host interfaces are derived from FDT2 specification. EDDL descriptive application and optional UIP are packed into a single file entity as FDI device package, which will be consumed by FDI host application...A small FDI host application that consumes FDI device package is also a kind of device application and it can be wrapped into a DTM. Such DTM will be hosted by FDT2 Frame Application and execute device application provided with FDI device package. FDT2 Frame Application can host not only DTMs but also FDI device package using respective supporting DTM. [page 937 col 2] The FDI package consists of Package Catalog, EDD, User Interface Plug-in and Attachment as shown in Figure 5. EDD is a binary file tokenized from EDDL descriptions. EDD has logically Device Definition, User Interface Description and Business Logic. The Device Definition provides definitions of variables and their attributes. The User Interface Description has menus and their presentation attributes shown in user interface. The Business Logic is used for relationship between variables and some methods. The User Interface Plug-in is UI application based on FDT2 technology to provide advanced functions. The attachment can contain protocol specific file such as GSD file for PROFIBUS and CFF file for FOUNDATION fieldbus. It can also contain bitmaps used in the user interface and optionally device instruction manual and datasheets; wherein bitmaps are known image types) “communicating from user interface engine of the host device to the device engine of the target device using a communication paradigm that uses an information model that models field device data from multiple different field device communication protocols” (([page 935 col 1] FDT specification is protocol independent between FDT Frame Application and DTM. A DTM can represent not only field devices but also communication interface devices including communication gateways. Device DTM and communication DTM are used together to perform device communications. Between these DTMs there is protocol dependent information exchanged and FDT specification provides protocol annex for each protocol to define protocol specific profile (See Figure 2). FDT has 16 protocol annexes for not only process automation but also factory automation communication protocols. Currently the following protocols are available; HART, PROFIBUS, PROFINET, FOUNDATION fieldbus, Modbus, IO-Link, CANopen, EtherCAT, Interbus, Sercos, CC-Link, DeviceNet, ControlNet, CompoNet, Ethernet/IP and ISA100.11a. [page 936 col 2] a host computer has Ethernet card to be used for initiation of field communication. A DTM for this Ethernet communication hardware is added at first. The Ethernet card sends data packets to a communication gateway where data packets are delivered to a PROFIBUS network. A DTM for the Ethernet/PROFIBUS gateway is added under the Ethernet communication DTM; [page 937 col 2] The attachment can contain protocol specific file such as GSD file for PROFIBUS and CFF file for FOUNDATION fieldbus. wherein the actually used protocol of the various protocols is the communication paradigm, and ethernet is the external communication link) “and that communicates using the communication paradigm over the external communication link to perform communication and configuration activities on the target device” (([page 937 col 1] The HART device DTM sends HART command to the PROFIBUS/HART gateway and the command is encapsulated into PROFIBUS data packet to be passed to the Ethernet/PROFIBUS gateway DTM. The gateway DTM wraps the packet with Ethernet data frame and then pass it to the Ethernet communication DTM. From the HART device DTM to the Ethernet communication DTM, a HART command is relayed through the DTM objects. The Ethernet communication DTM initiates physical communication to pass the data packet to Ethernet port. From this point the data packet moves into the right side of the Figure 4 and then passed through the gateways and finally the HART command reaches the HART device. Response data initiated by the HART device is passed in the revise way through the gateways to reach the Ethernet communication DTM and then passed; wherein commands imply the device being online; [page 937 col 2] EDDL and FDT technologies are used in the different host applications. It was often argued that EDDL and FDT were competitive each other. The both technologies are used for device configuration).
Takeuchi fails to explicitly teach “a host device including … a graphical user interface terminal”.
Blevins teaches “a host device including … and a graphical user interface terminal” ([0042] In the process plant 10 of Fig. 1, the workstation 20 includes a suite of operator interface applications and other data structures 32 which can be accessed by any authorized user (sometimes referred to herein as a configuration engineer and sometimes as an operator, although other types of users may exist as described herein below in connection with display layers customized for user type) to view and provide functionality with respect to devices, units, etc. connected within the process plant 10. The suite of operator interface applications 32 is stored in a memory 34 of the workstation 20 and each of the applications or entities within the suite of applications 32 is adapted to be executed on a processor 36 associated with the workstation 20. While the entire suite of applications 32 is illustrated as being stored in the workstation 20, some of these applications or other entities could be stored in and executed in other workstations or computer devices within or associated with the plant 10…. the suite of applications can provide display outputs to a display screen 37 associated with the workstation 20 or any other desired display screen or display device, including hand-held devices, laptops, other workstations, printers, etc.; [0102] The determination of which content layer to depict may be made by the execution engine 48 or the processor of any workstation or other device with access to the network, including, for instance, a rendering engine associated with a display device on which the process graphic display will be rendered. In this manner, the same display device (e.g., a handheld computer) may be utilized by different personnel that call for different content layers to be displayed).
It would have been obvious to a person having ordinary skill in the art before the effective file date of the claimed invention to have modified the method for device integration of a target device using a host/client that executes a user interface engine from packaged user interfaces for the target device as taught by Takeuchi with the use of a screen/terminal for displaying the user interface elements as taught by Blevins, because to PHOSITA, Takeuchi suggests such desires to display the user interface plug-in elements for the target device for user interaction because while not explicitly ever stating it because Takeuchi assumes the are in conversation with PHOSITA, which would not need such trivial details explicitly stated. Furthermore, both Takeuchi and Blevins relate in that they are system for supplying user interfaces for field devices, thus by using the display screen on the host/client of Blevins, it would be expected to improve the host/client of Takeuchi to actually display the user interface elements.
In regards to Claim 30, the combination of Takeuchi and Blevins teaches the device integration method as incorporated by claim 29 above. Takeuchi further teaches “The method of claim 29, wherein the target device is a first target device, and further comprising, storing a second device package on a computer readable medium, the second device package including user interface rendering programing and user interface logic for a second target device different than the first target device, providing the second device package to the host device, and executing at the host device, a second user interface engine using the user interface rendering programming and the user interface logic of the second device package to render images on the graphical user interface terminal and to control the operation of the second user interface engine and communicating from second user interface engine of the host device to a device engine of the second target device using the communication paradigm that uses an information model that models field device data from multiple different field device communication protocols and that communicates using the communication paradigm over the external communication link to perform communication and configuration activities on the second target device.” (Fig. 4 shows simplified system architecture with two supported devices, D using Profibus and E using HART and thus each would be expected to operate in the same way in relation to claim 1 albeit using different communication interfaces/protocols).
In regards to Claim 33, the combination of Takeuchi and Blevins teaches the device integration method as incorporated by claim 29 above. Takeuchi further teaches “The method of claim 29, wherein importing includes importing the user interface rendering programing and the user interface logic for the target device without importing a device engine that simulates the operation of the target device” ([page 934 abstract] A device application can be described in EDDL for its device profiles such as device parameters, simple methods and business logics in plain text format. FDI added an extension to support programmed user interface where EDDL is not enough to provide such functions and presentations. FDI adopted device information model defined in OPC-UA, so that FDI client can access device model in the FDI server in the uniform way. The programmed user interface is defined in FDI as user interface plug-in (UIP) where some of host interfaces are derived from FDT2 specification. EDDL descriptive application and optional UIP are packed into a single file entity as FDI device package, which will be consumed by FDI host application; wherein Takeuchi makes no reference of a simulation, and thus none is imported).
In regards to Claim 40, the combination of Takeuchi and Blevins teaches the device integration method as incorporated by claim 29 above. Takeuchi further teaches “The method of claim 29, including storing one or more target device configuration files in a standardized format in the host device” ([page 937 col 2] EDDL and FDT technologies are used in the different host applications. It was often argued that EDDL and FDT were competitive each other. The both technologies are used for device configuration. But EDDL covers basic device functions and on the other hand FDT covers additionally advanced functions. In this sense they are complementary each other The User Interface Plug-in is UI application based on FDT2 technology to provide advanced functions. The attachment can contain protocol specific file such as GSD file for PROFIBUS and CFF file for FOUNDATION fieldbus. It can also contain bitmaps used in the user interface and optionally device instruction manual and datasheets; wherein the GSD or CFF files are configuration files for using the different protocols, and are a known format of GSD/CFF).
Claims 3 and 31 are rejected under 35 U.S.C. 103 as being unpatentable over Takeuchi and Blevins as applied to claims 1 and 29 above, and further in view of Ardo et al. (English translation of DE 102014108126, hereinafter Ardo).
In regards to Claim 3, the combination of Takeuchi and Blevins teaches the device integration system as incorporated by claim 1 above.
The combination of Takeuchi and Blevins fails to teach “The device integration system of claim 1, wherein the host device includes a further communication interface that imports the device package as a file stored on a computer memory”.
Ardo teaches “The device integration system of claim 1, wherein the host device includes a further communication interface that imports the device package as a file stored on a computer memory” ([page 5] The inventive FDI device package 6 includes at least a minimal generic device description gDD and a user interface plug-in UIP. It is also conceivable that the FDI Device Package 6 In addition, further user interface plug-ins UIP and "attachments", for example in the form of data sheets, GSD files (files that are held in a data format for Profibus and Profinet devices) or the like. This FDI device package according to the invention 6 becomes in a first step in the FDI server 3 imported or loaded...However, other variants are also conceivable in which the DTM suitable for a specific field device F is loaded from a storage medium, for example a USB stick or also from a web server. Such a DTM typically consists both of a user interface, ie a graphical user interface, on which functions of the field device are displayed, as well as of a business logic 10 , which contains all functions that are not displayed in the graphical user interface, such as calculating coefficients).
It would have been obvious to a person having ordinary skill in the art before the effective file date of the claimed invention to have modified the device integration system in which device packages are imported and utilized by a host/client computer, with the storing of the device package that includes business logic and graphical interfaces over a USB interface as taught by Ardo, because it would gain the obvious benefit of allowing a user to physically handle and store the device package on a USB stick which offers improved security (a USB stick cannot be hacked while it is not plugged in, and thus cannot be changed) and affords long-term storage without requiring power (USB sticks are well-known to store files without electricity). By combining these elements, it can be considered taking the known method of using a USB stick to transfer the DTM of a device package including the business logic and graphical elements, and using those features to improve the host/clients of Takeuchi in a similar way that achieves predictable results.
In regards to Claim 31, the combination of Takeuchi and Blevins teaches the device integration method as incorporated by claim 29 above.
The combination of Takeuchi and Blevins fails to teach “The method of claim 29, including importing the device package as a file stored on a computer memory into the host device via a further communication interface that does not use the communication paradigm”.
Ardo teaches “The method of claim 29, including importing the device package as a file stored on a computer memory into the host device via a further communication interface that does not use the communication paradigm” ([page 5] The inventive FDI device package 6 includes at least a minimal generic device description gDD and a user interface plug-in UIP. It is also conceivable that the FDI Device Package 6 In addition, further user interface plug-ins UIP and "attachments", for example in the form of data sheets, GSD files (files that are held in a data format for Profibus and Profinet devices) or the like. This FDI device package according to the invention 6 becomes in a first step in the FDI server 3 imported or loaded...However, other variants are also conceivable in which the DTM suitable for a specific field device F is loaded from a storage medium, for example a USB stick or also from a web server. Such a DTM typically consists both of a user interface, ie a graphical user interface, on which functions of the field device are displayed, as well as of a business logic 10 , which contains all functions that are not displayed in the graphical user interface, such as calculating coefficients; wherein ethernet and USB are inherently different interfaces).
It would have been obvious to a person having ordinary skill in the art before the effective file date of the claimed invention to have modified the device integration system in which device packages are imported and utilized by a host/client computer, with the storing of the device package that includes business logic and graphical interfaces over a USB interface as taught by Ardo, because it would gain the obvious benefit of allowing a user to physically handle and store the device package on a USB stick which offers improved security (a USB stick cannot be hacked while it is not plugged in, and thus cannot be changed) and affords long-term storage without requiring power (USB sticks are well-known to store files without electricity). By combining these elements, it can be considered taking the known method of using a USB stick to transfer the DTM of a device package including the business logic and graphical elements, and using those features to improve the host/clients of Takeuchi in a similar way that achieves predictable results.
Claims 4, 7, and 32 are rejected under 35 U.S.C. 103 as being unpatentable over Takeuchi and Blevins as applied to claims 1 and 29 above, and further in view of Diancin et al. (English translation of DE-102020133570, hereinafter Diancin).
In regards to Claim 4, the combination of Takeuchi and Blevins teaches the device integration method as incorporated by claim 1 above.
The combination of Takeuchi and Blevins fails to teach “The device integration system of claim 1, wherein the host device imports the device package from a memory on the target device via the communication interface”.
Diancin teaches “The device integration system of claim 1, wherein the host device imports the device package from a memory on the target device via the communication interface” ([page 6] An FDI server 92 can be adapted to FDI device packages 90 to import and manage the contents of the FDI device packages 90 to read and interpret and, when initiated, to create a series of graphical instructions that can be used with the FDI server 92 communicatively coupled FDI client 94 enable access to a process controller function and read device parameter values. The FDI server 92 can be an FDI-EDD engine 100 for reading the in the FDI device packages 90 included EDD 18th included, with the FDI server 92 graphical user interfaces 102 like views, that the FDI client can create 94 be available. The FDI client 94 can with the FDI server 92 communicate in order to retrieve the graphic instructions in the form of, for example, XML-based representations and to render these graphics on a display device for a user. It is in this regard that the FDI client functions 94 like an HMI similar to the one in 1 shown. The FDI client 94 can also use the user interface plug-in (UIP) 82 of the FDI device package 90 for a specific device 22nd import and run. As explained, certain functions and graphical interfaces can be used by the UIP 82 implemented outside of the UID 33 default values are, or improvements for those from the UID 33 provide predetermined functions. In general, the FDI server can 92 be a workstation, process controller, field device, or other computing device that is communicatively coupled to an electronic device that is implemented by an EDD 18 or FDI device package 90 is described).
It would have been obvious to a person having ordinary skill in the art before the effective file date of the claimed invention to have modified the system with an FDI host/server that imports and utilizes device packages as taught by Takeuchi, with the use of a field device as a server for serving the device package as taught by Diancin, because it would gain the obvious benefit of having the device package included in the field device, and thus the device package would not need to be separately provided, such as on a USB stick or hosted on a file server. By combining these elements, it can be considered taking the known field device of Takeuchi, and modifying it so the field device stores the device package so it can be imported/provided to other host as taught by Diancin in a known way that achieves predictable results.
In regards to Claim 7, the combination of Takeuchi and Blevins teaches the device integration method as incorporated by claim 1 above.
The combination of Takeuchi and Blevins fails to teach “The device integration system of claim 6, wherein the another element of the target device is a file server”.
Diancin teaches “The device integration system of claim 6, wherein the another element of the target device is a file server” ([page 6] In the FDI system, the EDD 18th for a device in a standardized FDI device package 90 be encapsulated. An FDI device package 90 can be an EDD 18th , a user interface plug-in (UIP) 82 and attachments 83 that are specific to an electronic device. In this system, every device 22nd of the FDI system 70 through an FDI device package 90 shown. In general, the device can 22nd Any device in a process plant that uses an FDI package 90 is described. The UIP 82 of the FDI device package 90 can generally enable host machine specific graphics and processing functionality beyond the capabilities achieved using a single UID 33 in EDD 18th can be described. For example, the UIP 82 enable host machine specific graphics and processing functionality that goes beyond what is in the UID 33 the EDD 18th can be specified and interpreted by the EDD engine. The attachments 83 of the FDI device package 90 may contain device-related graphics and images, registration certificates, data sheets, user manuals and communication protocol specification files such as GSD (General Station Description), CFF (Common File Format), etc.; wherein attachments such as user manuals are files and thus are provided as a file server when accessed).
It would have been obvious to a person having ordinary skill in the art before the effective file date of the claimed invention to have modified the device integration system of Takeuchi with the use of running a file server on a target device as taught by Diancin because it would allow a target device to afford a person to retrieve files, such as the GSD and CFF protocol files of Diancin to afford improved communications. By using a field device as a file server, it allows files in the field device to be retrieved by other hosts/clients in the system. By combining these elements, it can be considered taking the known use of a field device as a file server as taught by Diancin, and implementing those functions in the field devices of Takeuchi in a known way that achieves predictable results.
In regards to Claim 32, the combination of Takeuchi and Blevins teaches the device integration method as incorporated by claim 29 above.
The combination of Takeuchi and Blevins fails to teach “The method of claim 29, including importing the device package from a memory on the target device via the communication interface”.
Diancin teaches “The method of claim 29, including importing the device package from a memory on the target device via the communication interface” ([page 6] An FDI server 92 can be adapted to FDI device packages 90 to import and manage the contents of the FDI device packages 90 to read and interpret and, when initiated, to create a series of graphical instructions that can be used with the FDI server 92 communicatively coupled FDI client 94 enable access to a process controller function and read device parameter values. The FDI server 92 can be an FDI-EDD engine 100 for reading the in the FDI device packages 90 included EDD 18th included, with the FDI server 92 graphical user interfaces 102 like views, that the FDI client can create 94 be available. The FDI client 94 can with the FDI server 92 communicate in order to retrieve the graphic instructions in the form of, for example, XML-based representations and to render these graphics on a display device for a user. It is in this regard that the FDI client functions 94 like an HMI similar to the one in 1 shown. The FDI client 94 can also use the user interface plug-in (UIP) 82 of the FDI device package 90 for a specific device 22nd import and run. As explained, certain functions and graphical interfaces can be used by the UIP 82 implemented outside of the UID 33 default values are, or improvements for those from the UID 33 provide predetermined functions. In general, the FDI server can 92 be a workstation, process controller, field device, or other computing device that is communicatively coupled to an electronic device that is implemented by an EDD 18 or FDI device package 90 is described).
It would have been obvious to a person having ordinary skill in the art before the effective file date of the claimed invention to have modified the system with an FDI host/server that imports and utilizes device packages as taught by Takeuchi, with the use of a field device as a server for serving the device package as taught by Diancin, because it would gain the obvious benefit of having the device package included in the field device, and thus the device package would not need to be separately provided, such as on a USB stick or hosted on a file server. By combining these elements, it can be considered taking the known field device of Takeuchi, and modifying it so the field device stores the device package so it can be imported/provided to other host as taught by Diancin in a known way that achieves predictable results.
Claims 10 and 37 are rejected under 35 U.S.C. 103 as being unpatentable over Takeuchi and Blevins as applied to claim 1 above, and further in view of Diancin et al. (English translation of DE-102020133570, hereinafter Diancin) and Ardo et al. (English translation of DE 102014108126, hereinafter Ardo).
In regards to Claim 10, the combination of Takeuchi and Blevins teaches the device integration method as incorporated by claim 1 above.
Takeuchi further teaches “The device integration system of claim 1, … wherein the host device … to obtain attachments from target device” ([page 937 col 2] Device vendors provide device application with a FDI package. The FDI package consists of Package Catalog, EDD, User Interface Plug-in and Attachment as shown in Figure 5. EDD is a binary file tokenized from EDDL descriptions. EDD has logically Device Definition, User Interface Description and Business Logic. The Device Definition provides definitions of variables and their attributes. The User Interface Description has menus and their presentation attributes shown in user interface. The Business Logic is used for relationship between variables and some methods)
The combination of Takeuchi and Blevins fails to teach “wherein the device package is stored on the target device and wherein the host device uses web based communications to obtain the user interface rendering programming and the user interface logic of the device package…”.
Diancin teaches “wherein the device package is stored on the target device” ([page 6] An FDI server 92 can be adapted to FDI device packages 90 to import and manage the contents of the FDI device packages 90 to read and interpret and, when initiated, to create a series of graphical instructions that can be used with the FDI server 92 communicatively coupled FDI client 94 enable access to a process controller function and read device parameter values.... In general, the FDI server can 92 be a workstation, process controller, field device, or other computing device that is communicatively coupled to an electronic device that is implemented by an EDD 18 or FDI device package 90 is described.
The combination of Takeuchi, Blevins and Diancin fails to teach “and wherein the host device uses web based communications to obtain the user interface rendering programming and the user interface logic of the device package”.
Ardo teaches “and wherein the host device uses web based communications to obtain the user interface rendering programming and the user interface logic of the device package” ([page 6] However, other variants are also conceivable in which the DTM suitable for a specific field device F is loaded from a storage medium, for example a USB stick or also from a web server. Such a DTM typically consists both of a user interface, ie a graphical user interface, on which functions of the field device are displayed, as well as of a business logic 10 , which contains all functions that are not displayed in the graphical user interface, such as calculating coefficients; wherein a web server is a web based communications utilized to obtain the user interface program and business logic).
It would have been obvious to a person having ordinary skill in the art before the effective file date of the claimed invention to have modified the system for importing a device package that includes user interface rendering programming and business logic with the use of a web server for serving the interface rendering programming and business control logic as taught by Ardo, because it would gain the obvious benefit of allowing different forms to communication, especially common ones such that those used by the web (http, ftp, etc.). By combining these elements, it can be considered taking the known method of running a web server on a field device so that interface files and business logic can be retrieved, and incorporating these features into the field devices of Takeuchi in a known way that achieves predictable results.
In regards to Claim 37, the combination of Takeuchi and Blevins teaches the device integration method as incorporated by claim 29 above.
The combination of Takeuchi and Blevins fails to teach “The method of claim 29, wherein the device package is stored on the target device and further including using web based communications to obtain the user interface rendering programming and the user interface logic of the device package from the target device.”.
Diancin teaches “wherein the device package is stored on the target device” ([page 6] An FDI server 92 can be adapted to FDI device packages 90 to import and manage the contents of the FDI device packages 90 to read and interpret and, when initiated, to create a series of graphical instructions that can be used with the FDI server 92 communicatively coupled FDI client 94 enable access to a process controller function and read device parameter values.... In general, the FDI server can 92 be a workstation, process controller, field device, or other computing device that is communicatively coupled to an electronic device that is implemented by an EDD 18 or FDI device package 90 is described.
The combination of Takeuchi, Blevins and Diancin fails to teach “and further including using web based communications to obtain the user interface rendering programming and the user interface logic of the device package from the target device”.
Ardo teaches “and further including using web based communications to obtain the user interface rendering programming and the user interface logic of the device package from the target device” ([page 6] However, other variants are also conceivable in which the DTM suitable for a specific field device F is loaded from a storage medium, for example a USB stick or also from a web server. Such a DTM typically consists both of a user interface, ie a graphical user interface, on which functions of the field device are displayed, as well as of a business logic 10 , which contains all functions that are not displayed in the graphical user interface, such as calculating coefficients; wherein a web server is a web based communications utilized to obtain the user interface program and business logic).
It would have been obvious to a person having ordinary skill in the art before the effective file date of the claimed invention to have modified the system for importing a device package that includes user interface rendering programming and business logic with the use of a web server for serving the interface rendering programming and business control logic as taught by Ardo, because it would gain the obvious benefit of allowing different forms to communication, especially common ones such that those used by the web (http, ftp, etc.). By combining these elements, it can be considered taking the known method of running a web server on a field device so that interface files and business logic can be retrieved, and incorporating these features into the field devices of Takeuchi in a known way that achieves predictable results.
Claims 6, 8, 9 and 34-36 are rejected under 35 U.S.C. 103 as being unpatentable over Takeuchi and Blevins as applied to claims 1 and 29 above, and further in view of Sangi (US 20180088548, hereinafter Sangi).
In regards to Claim 6, the combination of Takeuchi and Blevins teaches the device integration system as incorporated by claim 1 above.
Takeuchi further teaches “wherein the host device communicates via the communication interface with the device engine within the target device using the communication paradigm” ([page 936 col 2] a host computer has Ethernet card to be used for initiation of field communication. A DTM for this Ethernet communication hardware is added at first. The Ethernet card sends data packets to a communication gateway where data packets are delivered to a PROFIBUS network. A DTM for the Ethernet/PROFIBUS gateway is added under the Ethernet communication DTM…. From the HART device DTM to the Ethernet communication DTM, a HART command is relayed through the DTM objects. The Ethernet communication DTM initiates physical communication to pass the data packet to Ethernet port. From this point the data packet moves into the right side of the Figure 4 and then passed through the gateways and finally the HART command reaches the HART device. Response data initiated by the HART device is passed in the revise way through the gateways to reach the Ethernet communication DTM and then passed through the gateway DTMs to the HART device DTM).
The combination of Takeuchi and Blevins fails to teach “The device integration system of claim 1, wherein the host device further includes a web server, and wherein the user interface engine uses web-based programming and a web based communication paradigm, …and communicates with the another element of the target device using the web based server”.
Sangi teaches “wherein the host device further includes a web server, and wherein the user interface engine uses web-based programming and a web based communication paradigm, …and communicates with the another element of the target device using the web based server” ([0033] The plant control systems 20 may include technologies as wireless systems and protocols, remote transmission, logging and data historian, mobile interfaces and controls, and embedded web-servers. Preferably, the plant control systems 20 becomes centralized at plant level, easing to realize the ability to log in by remote equipment and the process control system 10. [0036] The supervisory control and data acquisition unit 12, in the present case, addresses amongst other things the process of monitoring and processing data analysis. The supervisory control and data acquisition unit 12 can be realized as pure, web-based system. The backbone of the supervisory control and data acquisition unit 12 can be realized using OPC UA (OPC Unified Architecture), which allows the system to handle and communicate structured data from the PLC layer to the plant process engine 11, wherein the plant process engine 11 can, for example, be realized as processor-based and/or process-driven unit or system or more general based on normal computer hardware, as a PC (Personal Computer)… OPC UA supports two protocols, one being a binary protocol and the other the normal Web Service protocol (http). Additionally, OPC UA works completely transparent to any Application-programming interface (API). Typically, the binary protocol offers the best performance/least overhead, takes minimum resources (no XML Parser, Simple Object Access Protocol (SOAP) and Hypertext Transfer Protocol (HTTP) required, which is important for embedded devices), offers best interoperability (binary is explicitly specified and allows fewer degrees of freedom during implementation) and uses a single arbitrarily choosable TCP port for communication easing tunneling or easy enablement through a firewall; wherein http is the web-based programming and TCP is the web-based communication [0039] Supervisory control and data acquisition unit 12 (SCADA) may use an integrated web server for the plant creator unit 14 and the Human Machine Interface (HMI).).
It would have been obvious to a person having ordinary skill in the art before the effective file date of the claimed invention to have modified the host system that communicates with a target device using a configured communication paradigm/protocol as taught by Takeuchi, with the use of running a web-server on a host connected to the target device so that another element of the target device can be served via the web-based server for client devices as taught by Sangi, because it would gain the stated benefit of Sangi, namely “[0018] the disclosure also has the same advantage for field device integration (FDI). Two standards used today for the configuration of field devices are Electronic Device Description Language (EDDL), which works according to the principle that the configuration parameters of a field device are defined by a description file and that the configuration is performed on this basis, and Field Device Tool (FDT), which works according to the principle that the equipment manufacturer provides a software component for a general configuration tool with the device. Both standards can easily be integrated via the common standard use OPC UA by the inventive method and system. Generally, the present method and system allows for an interoperability of all kind of standards at the semantic level based on the OPC UA transport protocol”. By combining these elements, it can be considered taking the known method of hosting a web-server on a device connected to a field device so that the field device can have data accessed via the web server, and using it to improve the host of Takeuchi in a known way that achieves predictable results.
In regards to Claim 8, the combination of Takeuchi and Blevins teaches the device integration system as incorporated by claim 1 above.
The combination of Takeuchi and Blevins fails to teach “The device integration system of claim 1, wherein the host device further includes a web server, and wherein the user interface engine uses web-based programming and a web-based communication paradigm, wherein the web server communicates with the device engine within the target device via both the web server and the communication interface, wherein the web server uses the web-based communication paradigm to communicate with the communication interface, and the communication interface communicates with the target device via the external communication link using the communication paradigm.”
Sangi teaches “The device integration system of claim 1, wherein the host device further includes a web server, and wherein the user interface engine uses web-based programming and a web-based communication paradigm” ([0036] The plant control systems 20 may include technologies as wireless systems and protocols, remote transmission, logging and data historian, mobile interfaces and controls, and embedded web-servers. [0039] The supervisory control and data acquisition unit 12 can be based 100% on web technology. As illustrated by FIG. 5, the main data gateway of the supervisory control and data acquisition unit 12 is based on OPC UA, which enables to communicate structured data from the process control system 10/41, e.g. realized on a PC, to the PLC 201 and vice versa. For PLC types, which do not support the OPC UA the driver or interpreter 204 is used in order to translate the protocol. The complete system may at least consist of the following elements: (i) The supervisory control and data acquisition unit 12 as server (running on PC based hardware) is connected to the PLC via OPC UA directly or via an OPC driver. Supervisory control and data acquisition unit 12 (SCADA) may use an integrated web server for the plant creator unit 14 and the Human Machine Interface (HMI). The supervisory control and data acquisition unit 12 itself can act not only as an OPC UA client but also as the OPC UA server, which is used to communicate with the PLC 201, the controller, i.e. the plant controller unit 13, the system of the supervisory control and data acquisition unit 12, a possible archive tool and others, (ii) The plant creator unit 14, which is the tool for the engineers to design and configure the actual plant; (iii) A runtime HMI with which the end user supervises and controls the plant 30) “wherein the web server communicates with the device engine within the target device via both the web server and the communication interface, wherein the web server uses the web-based communication paradigm to communicate with the communication interface, and the communication interface communicates with the target device via the external communication link using the communication paradigm” ([0018] the process control system is connected via an OPC UA network including an OPC UA server with at least one programmable logic controller (PLC) of the plant control system, wherein the operation of the plant and the operational units are controlled by means of the plant control system including the programmable logic controller (PLC) via the plurality of interlocked elements, in that the process control system includes a plant process engine with a library of selectable process control command records for each type of plant control system operatable by the independent process control system, … the transport layer between the OPC UA client of the process control system and the OPC UA client of the plant control system being extended bidirectionally by means of a defined bit sequence containing encoded programmable logic controller (PLC) messages, and the OPC UA clients being OPC UA network nodes in the OPC UA network with the OPC UA server, in that for steering and controlling the plant, the process control system transmits programmable logic controller (PLC) messages to the plant control system by encoding the PLC messages for the OPC UA transport layer and transmitting it in the OPC UA transport layer by means of the defined bit sequence, in that the plant control system decodes the PLC command messages by means of the interpreter from the defined bit sequence and transmits the decoded PLC command messages to the corresponding PLC for execution[0036] The base services of the OPC UA communication protocol are abstract method structures, which are protocol independent and provide the basis for OPC UA functionality. But for all its interoperability, the transport layer of OPC UA merely puts this structure into a protocol, which means it serializes/deserializes the data and transmits it over the network. Two protocols are specified for this purpose. One is a binary TCP protocol, optimized for high performance and the second is Web service-oriented. In its core, OPC UA is a mere information transport structure, whereas the OPC information model is based on a Full Mesh Network with corresponding nodes. The nodes can include any kind of meta information. These nodes can own attributes for read access (DA, HDA), commands, and triggered events that can be transmitted (AE, DataAccess, DataChange). Nodes hold for process data as well all other types of metadata, whereas the transmitted data and/or metadata are not type-specific transmittable. OPC UA supports two protocols, one being a binary protocol and the other the normal Web Service protocol (http). Additionally, OPC UA works completely transparent to any Application-programming interface (API). Typically, the binary protocol offers the best performance/least overhead, takes minimum resources (no XML Parser, Simple Object Access Protocol (SOAP) and Hypertext Transfer Protocol (HTTP) required, which is important for embedded devices), offers best interoperability (binary is explicitly specified and allows fewer degrees of freedom during implementation) and uses a single arbitrarily choosable TCP port for communication easing tunneling or easy enablement through a firewall; wherein the binary/TCP is a communication paradigm, while the HTTP and web-based communications are over the ethernet port/communication link).
It would have been obvious to a person having ordinary skill in the art before the effective file date of the claimed invention to have modified the host system that communicates with a target device using a configured communication paradigm/protocol as taught by Takeuchi, with the use of running a web-server on a host connected to the target device so that another element of the target device can be served via the web-based server for client devices as taught by Sangi, because it would gain the stated benefit of Sangi, namely “[0018] the disclosure also has the same advantage for field device integration (FDI). Two standards used today for the configuration of field devices are Electronic Device Description Language (EDDL), which works according to the principle that the configuration parameters of a field device are defined by a description file and that the configuration is performed on this basis, and Field Device Tool (FDT), which works according to the principle that the equipment manufacturer provides a software component for a general configuration tool with the device. Both standards can easily be integrated via the common standard use OPC UA by the inventive method and system. Generally, the present method and system allows for an interoperability of all kind of standards at the semantic level based on the OPC UA transport protocol”. By combining these elements, it can be considered taking the known method of hosting a web-server on a device connected to a field device so that the field device can have data accessed via the web server, and using it to improve the host of Takeuchi in a known way that achieves predictable results.
In regards to Claim 9, the combination of Takeuchi, Blevins and Sangi teaches the device integration system as incorporated by claim 8 above. Sangi further teaches “The device integration system of claim 8, wherein web server is communicatively coupled to the communication interface and tunnels web based messages through the communication interface using the communication paradigm” ([0036] Typically, the binary protocol offers the best performance/least overhead, takes minimum resources (no XML Parser, Simple Object Access Protocol (SOAP) and Hypertext Transfer Protocol (HTTP) required, which is important for embedded devices), offers best interoperability (binary is explicitly specified and allows fewer degrees of freedom during implementation) and uses a single arbitrarily choosable TCP port for communication easing tunneling or easy enablement through a firewall).
In regards to Claim 34, the combination of Takeuchi and Blevins teaches the device integration method as incorporated by claim 33 above.
Takeuchi further teaches “communicating from the host device to the device engine within the target device using the communication paradigm” ([page 936 col 2] a host computer has Ethernet card to be used for initiation of field communication. A DTM for this Ethernet communication hardware is added at first. The Ethernet card sends data packets to a communication gateway where data packets are delivered to a PROFIBUS network. A DTM for the Ethernet/PROFIBUS gateway is added under the Ethernet communication DTM…. From the HART device DTM to the Ethernet communication DTM, a HART command is relayed through the DTM objects. The Ethernet communication DTM initiates physical communication to pass the data packet to Ethernet port. From this point the data packet moves into the right side of the Figure 4 and then passed through the gateways and finally the HART command reaches the HART device. Response data initiated by the HART device is passed in the revise way through the gateways to reach the Ethernet communication DTM and then passed through the gateway DTMs to the HART device DTM).
The combination of Takeuchi and Blevins fails to teach “The method of claim 33, further including using a web-based programming and a web based communication paradigm within the user interface engine and including … and communicating with the another element of the target device using the web based server”.
Sangi teaches “The method of claim 33, further including using a web-based programming and a web based communication paradigm within the user interface engine and including … and communicating with the another element of the target device using the web based server” ([0033] The plant control systems 20 may include technologies as wireless systems and protocols, remote transmission, logging and data historian, mobile interfaces and controls, and embedded web-servers. Preferably, the plant control systems 20 becomes centralized at plant level, easing to realize the ability to log in by remote equipment and the process control system 10. [0036] The supervisory control and data acquisition unit 12, in the present case, addresses amongst other things the process of monitoring and processing data analysis. The supervisory control and data acquisition unit 12 can be realized as pure, web-based system. The backbone of the supervisory control and data acquisition unit 12 can be realized using OPC UA (OPC Unified Architecture), which allows the system to handle and communicate structured data from the PLC layer to the plant process engine 11, wherein the plant process engine 11 can, for example, be realized as processor-based and/or process-driven unit or system or more general based on normal computer hardware, as a PC (Personal Computer)… OPC UA supports two protocols, one being a binary protocol and the other the normal Web Service protocol (http). Additionally, OPC UA works completely transparent to any Application-programming interface (API). Typically, the binary protocol offers the best performance/least overhead, takes minimum resources (no XML Parser, Simple Object Access Protocol (SOAP) and Hypertext Transfer Protocol (HTTP) required, which is important for embedded devices), offers best interoperability (binary is explicitly specified and allows fewer degrees of freedom during implementation) and uses a single arbitrarily choosable TCP port for communication easing tunneling or easy enablement through a firewall; wherein http is the web-based programming and TCP is the web-based communication [0039] Supervisory control and data acquisition unit 12 (SCADA) may use an integrated web server for the plant creator unit 14 and the Human Machine Interface (HMI).).
It would have been obvious to a person having ordinary skill in the art before the effective file date of the claimed invention to have modified the host system that communicates with a target device using a configured communication paradigm/protocol as taught by Takeuchi, with the use of running a web-server on a host connected to the target device so that another element of the target device can be served via the web-based server for client devices as taught by Sangi, because it would gain the stated benefit of Sangi, namely “[0018] the disclosure also has the same advantage for field device integration (FDI). Two standards used today for the configuration of field devices are Electronic Device Description Language (EDDL), which works according to the principle that the configuration parameters of a field device are defined by a description file and that the configuration is performed on this basis, and Field Device Tool (FDT), which works according to the principle that the equipment manufacturer provides a software component for a general configuration tool with the device. Both standards can easily be integrated via the common standard use OPC UA by the inventive method and system. Generally, the present method and system allows for an interoperability of all kind of standards at the semantic level based on the OPC UA transport protocol”. By combining these elements, it can be considered taking the known method of hosting a web-server on a device connected to a field device so that the field device can have data accessed via the web server, and using it to improve the host of Takeuchi in a known way that achieves predictable results.
In regards to Claim 35, the combination of Takeuchi and Blevins teaches the device integration method as incorporated by claim 33 above.
The combination of Takeuchi and Blevins fails to teach “The method of claim 33, further including using web-based programming and a web-based communication paradigm in the user interface engine, and communicating with the device engine within the target device via both the web-based communication paradigm and the communication paradigm”
Sangi teaches “The method of claim 33, further including using web-based programming and a web-based communication paradigm in the user interface engine” ([0036] The plant control systems 20 may include technologies as wireless systems and protocols, remote transmission, logging and data historian, mobile interfaces and controls, and embedded web-servers. [0039] The supervisory control and data acquisition unit 12 can be based 100% on web technology. As illustrated by FIG. 5, the main data gateway of the supervisory control and data acquisition unit 12 is based on OPC UA, which enables to communicate structured data from the process control system 10/41, e.g. realized on a PC, to the PLC 201 and vice versa. For PLC types, which do not support the OPC UA the driver or interpreter 204 is used in order to translate the protocol. The complete system may at least consist of the following elements: (i) The supervisory control and data acquisition unit 12 as server (running on PC based hardware) is connected to the PLC via OPC UA directly or via an OPC driver. Supervisory control and data acquisition unit 12 (SCADA) may use an integrated web server for the plant creator unit 14 and the Human Machine Interface (HMI). The supervisory control and data acquisition unit 12 itself can act not only as an OPC UA client but also as the OPC UA server, which is used to communicate with the PLC 201, the controller, i.e. the plant controller unit 13, the system of the supervisory control and data acquisition unit 12, a possible archive tool and others, (ii) The plant creator unit 14, which is the tool for the engineers to design and configure the actual plant; (iii) A runtime HMI with which the end user supervises and controls the plant 30) “and communicating with the device engine within the target device via both the web-based communication paradigm and the communication paradigm” ([0018] the process control system is connected via an OPC UA network including an OPC UA server with at least one programmable logic controller (PLC) of the plant control system, wherein the operation of the plant and the operational units are controlled by means of the plant control system including the programmable logic controller (PLC) via the plurality of interlocked elements, in that the process control system includes a plant process engine with a library of selectable process control command records for each type of plant control system operatable by the independent process control system, … the transport layer between the OPC UA client of the process control system and the OPC UA client of the plant control system being extended bidirectionally by means of a defined bit sequence containing encoded programmable logic controller (PLC) messages, and the OPC UA clients being OPC UA network nodes in the OPC UA network with the OPC UA server, in that for steering and controlling the plant, the process control system transmits programmable logic controller (PLC) messages to the plant control system by encoding the PLC messages for the OPC UA transport layer and transmitting it in the OPC UA transport layer by means of the defined bit sequence, in that the plant control system decodes the PLC command messages by means of the interpreter from the defined bit sequence and transmits the decoded PLC command messages to the corresponding PLC for execution[0036] The base services of the OPC UA communication protocol are abstract method structures, which are protocol independent and provide the basis for OPC UA functionality. But for all its interoperability, the transport layer of OPC UA merely puts this structure into a protocol, which means it serializes/deserializes the data and transmits it over the network. Two protocols are specified for this purpose. One is a binary TCP protocol, optimized for high performance and the second is Web service-oriented. In its core, OPC UA is a mere information transport structure, whereas the OPC information model is based on a Full Mesh Network with corresponding nodes. The nodes can include any kind of meta information. These nodes can own attributes for read access (DA, HDA), commands, and triggered events that can be transmitted (AE, DataAccess, DataChange). Nodes hold for process data as well all other types of metadata, whereas the transmitted data and/or metadata are not type-specific transmittable. OPC UA supports two protocols, one being a binary protocol and the other the normal Web Service protocol (http). Additionally, OPC UA works completely transparent to any Application-programming interface (API). Typically, the binary protocol offers the best performance/least overhead, takes minimum resources (no XML Parser, Simple Object Access Protocol (SOAP) and Hypertext Transfer Protocol (HTTP) required, which is important for embedded devices), offers best interoperability (binary is explicitly specified and allows fewer degrees of freedom during implementation) and uses a single arbitrarily choosable TCP port for communication easing tunneling or easy enablement through a firewall; wherein the binary/TCP is a communication paradigm, while the HTTP and web-based communications are over the ethernet port/communication link).
It would have been obvious to a person having ordinary skill in the art before the effective file date of the claimed invention to have modified the host system that communicates with a target device using a configured communication paradigm/protocol as taught by Takeuchi, with the use of running a web-server on a host connected to the target device so that another element of the target device can be served via the web-based server for client devices as taught by Sangi, because it would gain the stated benefit of Sangi, namely “[0018] the disclosure also has the same advantage for field device integration (FDI). Two standards used today for the configuration of field devices are Electronic Device Description Language (EDDL), which works according to the principle that the configuration parameters of a field device are defined by a description file and that the configuration is performed on this basis, and Field Device Tool (FDT), which works according to the principle that the equipment manufacturer provides a software component for a general configuration tool with the device. Both standards can easily be integrated via the common standard use OPC UA by the inventive method and system. Generally, the present method and system allows for an interoperability of all kind of standards at the semantic level based on the OPC UA transport protocol”. By combining these elements, it can be considered taking the known method of hosting a web-server on a device connected to a field device so that the field device can have data accessed via the web server, and using it to improve the host of Takeuchi in a known way that achieves predictable results.
In regards to Claim 36, the combination of Takeuchi, Blevins and Sangi teaches the device integration system as incorporated by claim 35 above. Sangi further teaches “The method of claim 35, further including tunnelling web based messages from the user interface of the host device to the target device through the communication interface using the communication paradigm” ([0036] Typically, the binary protocol offers the best performance/least overhead, takes minimum resources (no XML Parser, Simple Object Access Protocol (SOAP) and Hypertext Transfer Protocol (HTTP) required, which is important for embedded devices), offers best interoperability (binary is explicitly specified and allows fewer degrees of freedom during implementation) and uses a single arbitrarily choosable TCP port for communication easing tunneling or easy enablement through a firewall).
Allowable Subject Matter
Claims 11-28 and 38-39 are found allowable in terms of prior art.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Lutz et al. (US 20170176982) – teaches the use of FDI using FDT/DTM in the starting up of an industrial automation network
Nixon et al. (US 20240231333) – teaches the use of a compute fabric for virtualizing a process plant
Stump et al. (US 20230091919) – teaches the use of both online and offline routines for field devices and discovery of outdated versions
Wagener et al. (US 20170093621) – teaches the configuration and implementation of a plant using FDI-based packages
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JONATHAN M SKRZYCKI whose telephone number is (571)272-0933. The examiner can normally be reached M-Th 7:30-3:30.
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, Ken 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.
/JONATHAN MICHAEL SKRZYCKI/Examiner, Art Unit 2116
Prosecution Insights