DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office correspondence is in response to the application number 18/290802 filed on January 21, 2024.
Preliminary Amendment
Prior to examination on the merits, Applicant has requested amendments to the claims for examination. The amendments are accepted.
Claims 1 – 8 and 10 – 17 are amended.
Claim 9 is cancelled.
Claims 18 – 19 are added.
Claims 1 – 8 and 10 – 19 are pending.
Authorization for Internet Communications
The examiner encourages Applicant to submit an authorization to communicate with the examiner via the Internet by making the following statement (from MPEP 502.03):
“Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with the undersigned and practitioners in accordance with 37 CFR 1.33 and 37 CFR 1.34 concerning any subject matter of this application by video conferencing, instant messaging, or electronic mail. I understand that a copy of these communications will be made of record in the application file.”
Please note that the above statement can only be submitted via Central Fax (not Examiner's Fax), Regular postal mail, or EFS Web using PTO/SB/439.
Priority
This Application is the National Stage filing under 35 U.S.C. § 371 of PCT Application Ser. No. PCT/EP2022/068820 filed on July 2, 2022 which claims the benefit of European Patent Application 21187022 filed with the European Patent Office on July 21, 2021. The applicant has provided certified priority documents and the applicant is entitled to a priority date of 7/21/2021.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on February 8, 2024 was filed on or after the mailing date of the application on January 21, 2024. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Drawings
The drawings (Fig. 1) are objected to as failing to comply with 37 CFR 1.84(p)(5) because they do not include the following reference sign(s) mentioned in the description:.
Aggregator component 104 as described in ¶ [0037]
Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
The drawings (Fig. 1) are objected to as failing to comply with 37 CFR 1.84(p)(5) because they include the following reference character(s) not mentioned in the description:
Dashed Box 300
Corrected drawing sheets in compliance with 37 CFR 1.121(d), or amendment to the specification to add the reference character(s) in the description in compliance with 37 CFR 1.121(b) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
35 USC § 101 Analysis – Judicial Exception
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.
The claimed invention is directed to statutory subject matter and are not rejected under 35 USC 101 because of a judicial exception.. The claimed subject matter is integrated into a practical application under prong 2 of the Step 2A analysis as documented in MPEP 2016.04(d). The claims are directed to non-abstract improvements in computer related technology. A claim is non-statutory when it is directed to a judicial exception (e.g. either one of mathematical concepts, mental processes, or certain methods of organizing human activity) without significantly more. The claimed invention is not directed to a judicial exception. Instead, the claimed invention is directed to a technological improvement for providing services to a service consumer by sequence control components in a sequence control environment, in particular applicable to industrial automation systems. The claimed invention’s components includes an OPC UA client requesting a service that is assigned to a OPC UA server, which is formed by a sequence control component that can be loaded into the sequence control environment and executed there. The server can be addressed by a proxy of a subnet comprising the sequence control environment and accepting service requests from the client. The proxy has a connection to a central directory service that transmits the addressing information valid within the subnet to the proxy. The claimed invention performs an algorithm using said components which is: assigning, each of the services, at least one server component that is formed by a sequence control component that is loadable into the sequence control environment and executed at the sequence control environment, and further accepting, by at least one proxy component of a subnet comprising the sequence control environment. requests from a service consumer, transmitting, by a central directory service component. addressing information valid within the subnet to the at least one proxy component. Therein, registering the at least one server component on the central directory service component with internal connection data of the central directory service component, including network addresses and ports visible to the at least one server component. Thereafter, determining globally valid access information assigned to external network addressing information of the at least one server component that is valid within the subnet, and modifying the internal connection data using the determined external network addressing information in the central directory service component so that the at least one proxy component is operable to forward service requests corresponding to modified addressing information to the server component. The ordered combination of the elements and limitations bound the claimed invention to a specific and useful improvement for providing services in an industrial automation system. Therein, the claimed invention is statutory under 35 USC 101.
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 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 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 10 and 11 are rejected under 35 U.S.C. 103 as being un-patentable over Hood et al. (U.S. 8782249 B1; herein referred to as Hood) in view of Keating (U.S. 2022/0100585 A1; herein referred to as Keating)
In regard to claim 1, Hood teaches A method for providing services to a service consumer by sequence control components in a sequence control environment (Col 4: Lines 58 – 67; Col 5: Lines 1 – 37 “ . . . FIG. 1 illustrates a system 100 that incorporates a message engine 104 to normalize messaging of various messaging protocols and formats in accordance with an aspect of the subject innovation. The message engine 104 can provide a consistent interface, among a plurality of application(s) 106 and/or modules (s) 108, (where m and n are integers), wherein events are sent/received consistently across the industrial plant. In general, the term module can refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution, as well as an elecro-mechanical component. For example, a module can be, but is not limited to, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and a computer. By way of illustration, an application running on a server and/or the server can be a module. In addition, a module can include one or more subcomponents. . . . Accordingly, the industrial controller(s) 110 that reside on the factory floor can interact with the message engine 104 to facilitate normalizing a communication based on a common industrial protocol 101. For example, the industrial controller 110 can be employed to control a certain cell/unit or procedure, which can be desirably tested and/or debugged. Particularly, the industrial controller 110 can include at least a portion of control logic that is employed to implement such procedures within the system. Moreover, the industrial controller 110 can be a programmable logic controller (PLC). PLCs are small computers that are employed for automating real-world processes (e.g., controlling machinery within an industrial environment). Typically, PLCs are microprocessor-based devices with modular or integral input/output circuitry, wherein such circuitry is utilized to monitor status of field connected sensor inputs, and is further utilized to control output actuators according to a logic program. While PLCs can be employed within the system 100 as an industrial controller, it is to be understood that any suitable industrial control device can be employed in connection with the subject invention. For example, any suitable microprocessor and/or microcontroller can be utilized within the system 100 as an industrial controller. . . “), the method comprising:
assigning, each of the services (e.g. applications), at least one server component that is formed by a sequence control component that is loadable into the sequence control environment and executed at the sequence control environment (e.g. industrial controller) (see Fig. 1 110, Col 1: Lines 61-67; Col 2: Lines 1-22 “ . . . Moreover, control systems commonly employ one or more industrial controllers. A typical industrial controller is a special purpose processing device for controlling (e.g., via an automated and a semi-automated means) industrial processes, machines, manufacturing equipment, plants, and the like. Such controllers can execute a control program or routine in order to measure one or more process variables or inputs representative of a status of a controlled process and/or effectuate outputs associated with control of the process. For example, an output module can interface directly with a controlled process by providing an output from memory to an actuator such as a motor, drive, valve, solenoid, and the like. In distributed control systems, controller hardware configuration can be facilitated by separating the industrial controller into a number of control elements, each of which can perform a different function. Particular control modules needed for the control task can be connected together on a common backplane within a rack and/or through a network or other communications medium. Various control modules can also be spatially distributed along a common communication link in several locations. Data can be communicated with these remote modules over a common communication link, or network, wherein any or all modules on the network communicate via a common and/or an industrial communications protocol. Controllers within a control system can communicate with each other, with controllers residing in other control systems and/or with systems and/or applications outside of a control environment (e.g., business related systems and applications). . . .”) ;
accepting, by at least one proxy component (e.g. message engine 300) of a subnet comprising the sequence control environment (e.g. industrial controller) (see Fig. 2 Col 5:Lines 38 – 65 “ . . . FIG. 2 illustrates a message engine 204 that further includes an optimization component 206. Such optimization component 206 can typically determine nature of the communications among different parts (e.g., a control module of the system, and a software program resident in a module of the application layer, operative interface layer), and in general determine whether the message is critical and should be sent in real-time, the message is not critical and a longer duration for exchange is acceptable, for example. Moreover, the optimization component 206 can determine if various applications do share a same communication protocol (e.g., are matchable based on a same policy), and hence no translation is necessary therebetween. Hence, an application and a module can readily communicate via the message engine. It is to be appreciated that the message engine 204 of the subject innovation can typically reside in any part of the system (e.g., within a software system, a control module and the like.) In general, the message engine of the subject innovation can facilitate providing a cohesive assembly of manufacturing system(s), to enable incremental integration of devices to the manufacturing system. Moreover, data mapping can be facilitated and higher level information interfaces (as compared to raw data interfaces) can be implemented. Additionally, a messaging system (e.g., a bus 208) can be configured, deployed and managed based on quality of service metrics (e.g., data volume, turnaround time, latency, redundancy, reliability and the like) from a common administration environment . . . “)), requests from a service consumer (see Fig. 13, Col 15:Lines 35 – 47 “ . . . The industrial controller 1305 further includes an integration component 1385 with a TCP/IP adapter 1390, which can provide a TCP/IP gateway between the devices 1325, 1330, 1340-1355 and 1365-1375 and the message engine 1395. The message engine 1395 can be a computer, server, cluster, or service oriented architecture (SOA) designed and utilized to couple and facilitate interaction between business and/or consumer trading partners. For example, two businesses that employ disparate operating systems and/or applications can utilize the message engine 1395 to exchange messages across internal and external networked computer systems. . . .”), transmitting, by a central directory service component, addressing information valid within the subnet to the at least one proxy component (see Fig. 3 Col 9: Lines 9-56 “ . . . FIG. 3 illustrates a further aspect of the subject innovation, wherein an adapter 304 is implemented as part of the message engine 300 to provide for communication with an OPC (Object Linking and Embedding-OLE interfaces that expose data from a variety of sources for process control) that can be hooked up to the message engine. Moreover, a registration component 308 can register applications/modules with the message engine, to facilitate locating them for a communication therebetween. The registration component 308 can further interact with a directory 310 that can be employed in a data driven architecture. This directory 310 can provide a logical depiction to the user of the devices in the factory, e.g., based upon a Unified Plant Model (UPM) that is built upon industry standards such as S88, S95. Such logical UPM depiction can further be tailored to the vernacular and plant organization of the customers industry. The directory function can translate the logical view of the factory into physical locations and addresses needed for the required data access and associations to take place. Additionally, in a data driven architecture the directory 310 can provide a logical view of the factory while resolving and/or providing necessary associations to physical location and/or device addressing information. The types of information required could include physical location of the data source/owner, physical location of the data subscriber, communications address for data source/owner and communications addresses for attributed data that can exist at multiple levels, for example. When data is required, addressing and associations to that data can be made with the directory 310 of the system. For example, the user can select the data using a logical UPM depiction of the plant. Depending upon the application requesting the data, as well as the role and requirements of the user, the directory interface can provide the appropriate addressing information to the required data. In some cases, such as automation device to automation device communications, the addressing might point directly to the data source/owner. In other cases, such as ERP human resources applications, the association may be to a proxy server of the attributed data so as to isolate the servicing of the data requests from the real time control processing of the automation device that is the data source. It is to be appreciated that the physical location associated with the data can be that of the data source/owner while the communication address may be that of some other device on the network that is performing the role of adding attributes to the data or acting as a proxy server for that data . . .”) ;
registering the at least one server component on the central directory service component with internal connection data of the central directory service component (see Col 3 Lines 27 – 39 “ . . . accordingly, in the industrial setting an application and a module can readily communicate via the message engine. It is to be appreciated that such message engine can typically reside in any part of the system (e.g., within a software system, a control module and the like.) In a related aspect, an adapter is implemented as part of the message engine to provide for communication with external industry and open standards such as for example, an OPC (OLE interfaces that expose data from a variety of sources for process control), OPC UA, JMS and the like, which can be hooked up to the message engine. Moreover, a registration component can register applications/modules with the message engine, to facilitate locating them for a communication therebetween . . .”), including network addresses (Col 6: Lines 57-67 “ . . . Attributes associated with data can be added as such data is distributed throughout a network. Data can be sent to one or more locations such as server or a proxy server (not shown). Accordingly, the location (e.g., address) of the data can be employed to determine various attributes associated with data from a particular data source. For example, data sent to server can provide attributes to data received such as formatting, schemas, scaling, factoring, units and the like. The attributed data sent from the server can be sent to additional locations such as proxy server, wherein additional attributes can be associated with the data . . .”)
determining globally valid access information assigned to external network addressing information of the at least one server component that is valid within the subnet (see Fig. 7 Col 9: Lines 16-55 “ . . . FIG. 7 illustrates an exemplary messaging exchange between control systems and applications (e.g., software applications), via a message engine(s) 710 in accordance with an aspect of the subject innovation. The system 700 facilitates messaging with and/or within an industrial automation environment. The system 700 includes a message engine(s) 710, which normalizes messaging of various messaging protocols and formats, and supplies a mechanism to reliably exchange messages (e.g., information, data, requests, queries, control signals, and the like) with a control system 720. For example, in one aspect, the message engine 710 can function as an application interface and provide common access points between applications (e.g., 720 and 740.) As illustrated, in the messaging exchange system 700 applications can interact with messaging systems by interfaces exposed by the message engines (710), wherein such message engine(s) exchange information between sender and receiver. As such, the presentation of the messaging infrastructure can be consistent with each user's role and location. For example, the control program associated with the control system 720 can send a message via the `SendMessage` instruction and the software application receives a message via a `RecieveMessage` function. Conversely a software application (e.g., within 740) can send a message via a `SendMessage` function and the control program of the control system 720 receives a message via the `ReceiveMessage` instruction. The systems can also employ a same set of application level constructs. It is to be appreciated that the messaging infrastructure can vary in functionality, and various levels of functionality can be provided depending on the host environments and associated system. Moreover, each messaging level can support a support a common configuration interface and presentation of public interfaces, allowing consistent presentation of management consoles for messaging across the system. Hence, at each level, message engines 710 can provide consistent external interfaces to products at that level, and can bridge across to other networks providing the necessary data/security mappings and conversions between the networks. Moreover, data can be replicated across applications in the same machine or across machines . . .”);
Hood fails to explicitly teach,
However Keating teaches and ports visible to the at least one server component (see ¶ [0032] “ . . . Registration module 214 may register resources associated with cloud computing services, operator pattern services provided by the cloud computing services, and each resource modification associated with the containerized environment. In some implementations, registration module 214 may store resource data in resource database 202. For example, registration module 214 may perform a serialization operation and translate the resource data into a data interchange format, where the resource data is defined as an attribute-value pair (also known as a name-value pair, a key-value pair, or a field-value pair) or any other serializable value. In some implementations, each resource entry (serialized value) in resource database 202 may include a unique identifier of the resource and a current state of the resource. For example, for a container hosting a website on port 80, the serialized value may include a unique identifier associated with the container networking port, and the current status or state of the container networking port (e.g., assigned to port 80). The serialized value (e.g., attribute-value pair) may be deterministic and not based on any external variables, such as the current time. . . .”) ; and
modifying the internal connection data using the determined external network addressing information in the central directory service component so that the at least one proxy component is operable to forward service requests corresponding to modified addressing information to the server component (see Fig. 2 ¶ [0029] “ . . . Memory 201 may include a resource database 202, an operation pattern service database 204, and a modifications database 206. Resource database 202 may store data associated with resources and their modifiable parameters as related to the cloud computing environment. Resources may have many parameters (e.g., a network interface may have configurable network address, subnet mask, default gateway, etc.), that may be modified. For example, the resource may include resource identification data, resource property data, resource functions data, resource address data, resource parameter data, resource status data, etc. The resources may include, but are not limited to, CPU resources, memory resources, input/output (I/O) resources, network resources, node resources, pod resources, container resources, or any other hardware or software based resources associated with any components of the cloud computing environment. The operator pattern service database 204 may store data associated with operator patterns services (e.g., operator pattern service identifications, associated containers, functions, etc.). The modifications database 206 may store data associated with modifications performed on resources. In some embodiments, one or more of resource database 202, operator pattern database 204, and modifications database 206 may be structured in a data interchange format . . . “; see Fig. 2 ¶ [0031] “ . . . Detection module 212 may detect modifications requested (e.g., a resource modification request) or performed by computing processes, such as an operator pattern services, to resources associated with the cloud computing environment. As noted above, in some implementations, the cloud computing environment may be a containerized environment, where nodes can include pods, and where each pod can include one or more containers that can be used to execute applications within the environment . . .”).
It would have been obvious to one skilled in the art, before the effective filing date of the applicant’s claimed invention to incorporate a method and system for modifying service requests when addressing conflicts are detected, as taught by Keating, into a method and system for service request exchange in an industrial control system employing a message engine that acts as a proxy to communicate service information between clients and servers in the industrial system, as taught by Hood. Such incorporation provides a means of detecting conflicting service requests and modifying said conflicting request so that the system continues operations without interruption.
In regard to claim 10, Hood teaches A system for providing services by sequence control components in a sequence control environment (see Col 4: Lines 58 – 67; Col 5: Lines 1 – 37 as described for the rejection of claim 1 and is incorporated herein) , the system comprising:
at least one server component assigned to each of the services (e.g. applications) , the at least one server component being formed by a sequence control component that is loadable into the sequence control environment and executed at the sequence control environment (e.g. industrial controller) (see Fig. 1 110, Col 1: Lines 61-67; Col 2: Lines 1-22 as described for the rejection of claim 1 and is incorporated herein);
at least one proxy component (e.g. message engine 300) of a subnet comprising the sequence control environment (e.g. industrial controller) (see Fig. 2 Col 5:Lines 38 – 65 as described for the rejection of claim 1 and is incorporated herein), the at least one proxy component being configured for accepting requests from a service consumer(see Fig. 13, Col 15:Lines 35 – 47 as described for the rejection of claim 1 and is incorporated herein) ;
a central directory service component configured for transmitting external network addressing information valid within the subnet to the at least one proxy component (see Fig. 3 Col 9: Lines 9-56 as described for the rejection of claim 1 and is incorporated herein)
for accepting registration of the at least one server component with internal connection data of the at least one server component (see Col 3 Lines 27 – 39 as described for the rejection of claim 1 and is incorporated herein) , including network addresses (see Col 6: Lines 57-67 as described for the rejection of claim 1 and is incorporated herein)and replacing the internal connection data with determined external network addressing information (see Fig. 7 Col 9: Lines 16-55 as described for the rejection of claim 1 and is incorporated herein)
Hood fails to explicitly teach,
However Keating teaches and ports visible to the at least one server component (see ¶ [0032] as described for the rejection of claim 1 and is incorporated herein)
wherein the at least one proxy component is configured to forward service access requests corresponding to modified addressing information to the server components (see Fig. 2 ¶ [0029], ¶ [0031] as described for the rejection of claim 1 and is incorporated herein).
The motivation to combine Keating with Hood is described for the rejection of claim 1 and is incorporated herein.
In regard to claim 11, the combination of Hood and Keating teaches wherein the at least one proxy component is configured as an OPC UA proxy with Local Discovery Server functionality (see Hood Fig. 3 Col 6: Lines 9 – 37 “ . . . FIG. 3 illustrates a further aspect of the subject innovation, wherein an adapter 304 is implemented as part of the message engine 300 to provide for communication with an OPC (Object Linking and Embedding-OLE interfaces that expose data from a variety of sources for process control) that can be hooked up to the message engine. Moreover, a registration component 308 can register applications/modules with the message engine, to facilitate locating them for a communication therebetween. The registration component 308 can further interact with a directory 310 that can be employed in a data driven architecture. This directory 310 can provide a logical depiction to the user of the devices in the factory, e.g., based upon a Unified Plant Model (UPM) that is built upon industry standards such as S88, S95. Such logical UPM depiction can further be tailored to the vernacular and plant organization of the customers industry. The directory function can translate the logical view of the factory into physical locations and addresses needed for the required data access and associations to take place. Additionally, in a data driven architecture the directory 310 can provide a logical view of the factory while resolving and/or providing necessary associations to physical location and/or device addressing information. The types of information required could include physical location of the data source/owner, physical location of the data subscriber, communications address for data source/owner and communications addresses for attributed data that can exist at multiple levels, for example. . . .”).
Claims 2 – 8 and 12 – 19 are rejected under 35 U.S.C. 103 as being un-patentable over Hood et al. (U.S. 8782249 B1; herein referred to as Hood) in view of Keating (U.S. 2022/0100585 A1; herein referred to as Keating) as applied to claims 1, 10, and 11 in further view of Moeller (U.S. 2021/0216306 A1; herein referred to as Moeller).
In regard to claim 2, the combination of Hood, Keating, and Moeller teaches further comprising: receiving, by the at least one proxy component a service request (see Hood Fig. 7 Col 9: Lines 16-32 “ . . . FIG. 7 illustrates an exemplary messaging exchange between control systems and applications (e.g., software applications), via a message engine(s) 710 in accordance with an aspect of the subject innovation. The system 700 facilitates messaging with and/or within an industrial automation environment. The system 700 includes a message engine(s) 710, which normalizes messaging of various messaging protocols and formats, and supplies a mechanism to reliably exchange messages (e.g., information, data, requests, queries, control signals, and the like) with a control system 720. For example, in one aspect, the message engine 710 can function as an application interface and provide common access points between applications (e.g., 720 and 740.) As illustrated, in the messaging exchange system 700 applications can interact with messaging systems by interfaces exposed by the message engines (710), wherein such message engine(s) exchange information between sender and receiver . . .”) and
checking a first unencrypted part (e.g. unencrypted form) of the service request (see Moeller Fig. 2A ¶ [0060] “ . . . Each gateway may include a security module (e.g., in a hardware layer of a controller described in the '628 patent), which may be used to perform any of a variety of data security operations, including encrypting portions of communications from/to SIIDs or other devices to/from gateways, encrypting portions of such information received at a gateway in an unencrypted form, or any of a variety of other functions described herein. For example, the gateway 120 may include a security module 127 having a trusted platform module (TPM) or secure element (SE) and/or other components . . .”) , such that it is determined whether a recipient addressed within the service request is the central directory service component (see Hood Fig. 3 Col 6: Lines 18-37 “ . . . The registration component 308 can further interact with a directory 310 that can be employed in a data driven architecture. This directory 310 can provide a logical depiction to the user of the devices in the factory, e.g., based upon a Unified Plant Model (UPM) that is built upon industry standards such as S88, S95. Such logical UPM depiction can further be tailored to the vernacular and plant organization of the customers industry. The directory function can translate the logical view of the factory into physical locations and addresses needed for the required data access and associations to take place. Additionally, in a data driven architecture the directory 310 can provide a logical view of the factory while resolving and/or providing necessary associations to physical location and/or device addressing information. The types of information required could include physical location of the data source/owner, physical location of the data subscriber, communications address for data source/owner and communications addresses for attributed data that can exist at multiple levels, for example. . . “), and that the service request is forwarded to a receiver so that subsequent service requests are answered by the central directory service component (see Hood Fig. 3 Col 6: Lines 38 – 56 “ . . . When data is required, addressing and associations to that data can be made with the directory 310 of the system. For example, the user can select the data using a logical UPM depiction of the plant. Depending upon the application requesting the data, as well as the role and requirements of the user, the directory interface can provide the appropriate addressing information to the required data. In some cases, such as automation device to automation device communications, the addressing might point directly to the data source/owner. In other cases, such as ERP human resources applications, the association may be to a proxy server of the attributed data so as to isolate the servicing of the data requests from the real time control processing of the automation device that is the data source. It is to be appreciated that the physical location associated with the data can be that of the data source/owner while the communication address may be that of some other device on the network that is performing the role of adding attributes to the data or acting as a proxy server for that data. . . .”).
It would have been obvious to one skilled in the art, before the effective filing date of the applicant’s claimed invention to incorporate a method and system for securely deploying a software component to a control device of an industrial control system, as taught by Moeller, into a method and system for service request exchange in an industrial control system employing a message engine that acts as a proxy to communicate service information between clients and servers in the industrial system, and the ability to modify service requests when addressing conflicts are detected, as taught by the combination of Hood and Keating. Such incorporation provides a level of security for moving services in the industrial system.
In regard to claim 3, the combination of Hood, Keating, and Moeller teaches further comprising:
receiving, by the at least one proxy component, a service request (see Hood Fig. 7 Col 9: Lines 16-32 “ . . . FIG. 7 illustrates an exemplary messaging exchange between control systems and applications (e.g., software applications), via a message engine(s) 710 in accordance with an aspect of the subject innovation. The system 700 facilitates messaging with and/or within an industrial automation environment. The system 700 includes a message engine(s) 710, which normalizes messaging of various messaging protocols and formats, and supplies a mechanism to reliably exchange messages (e.g., information, data, requests, queries, control signals, and the like) with a control system 720. For example, in one aspect, the message engine 710 can function as an application interface and provide common access points between applications (e.g., 720 and 740.) As illustrated, in the messaging exchange system 700 applications can interact with messaging systems by interfaces exposed by the message engines (710), wherein such message engine(s) exchange information between sender and receiver . . .”) with a first unencrypted part contained within the service request(see Moeller Fig. 2A ¶ [0060] “ . . . Each gateway may include a security module (e.g., in a hardware layer of a controller described in the '628 patent), which may be used to perform any of a variety of data security operations, including encrypting portions of communications from/to SIIDs or other devices to/from gateways, encrypting portions of such information received at a gateway in an unencrypted form, or any of a variety of other functions described herein. For example, the gateway 120 may include a security module 127 having a trusted platform module (TPM) or secure element (SE) and/or other components . . .”) ;
checking whether a recipient addressed within the service request is a services server (see Hood Col 6 Lines 38 – 56 “ . . . When data is required, addressing and associations to that data can be made with the directory 310 of the system. For example, the user can select the data using a logical UPM depiction of the plant. Depending upon the application requesting the data, as well as the role and requirements of the user, the directory interface can provide the appropriate addressing information to the required data. In some cases, such as automation device to automation device communications, the addressing might point directly to the data source/owner. In other cases, such as ERP human resources applications, the association may be to a proxy server of the attributed data so as to isolate the servicing of the data requests from the real time control processing of the automation device that is the data source. It is to be appreciated that the physical location associated with the data can be that of the data source/owner while the communication address may be that of some other device on the network that is performing the role of adding attributes to the data or acting as a proxy server for that data . . .”);
determining address information of the corresponding internal services server (See Hood Col 6: Lines 57 -67 “ . . . Attributes associated with data can be added as such data is distributed throughout a network. Data can be sent to one or more locations such as server or a proxy server (not shown). Accordingly, the location (e.g., address) of the data can be employed to determine various attributes associated with data from a particular data source. For example, data sent to server can provide attributes to data received such as formatting, schemas, scaling, factoring, units and the like. . . .”) ; and
continuing establishment of a connection to the determined address information of the internal server component (see Hood Col 6: Lines 64 – 67; Col 7: Lines 1- 6 “ . . . The attributed data sent from the server can be sent to additional locations such as proxy server, wherein additional attributes can be associated with the data. Thus, data sent from a particular source can accumulate attributes as it is sent throughout a network architecture. Additionally, attributes can be substituted and/or reduced as data is directed to desired portions of a network. Data can be replicated such that identical copies of data (e.g., attributed, original, etc.) can be located on the same or disparate networks in multiple locations.. . . “).
The motivation to combine Moeller with the combination of Hood and Keating is described for the rejection of claim 2 and is incorporated herein. Additionally, Moeller provides for an unencrypted part of the service request to be used to determine a recipient identity.
In regard to claim 4, the combination of Hood, Keating, and Moeller teaches further comprising monitoring, by the at least one proxy component, the connection for transmission of further unsecured service requests (see Hood Fig. 6 Col 8: Lines 60 – 67; Col 9: Lines 1 -15 “ . . . FIG. 6 illustrates a related methodology of facilitating message exchange as part of a factory automation platform. Initially and at 610, a message bus that interacts with message engines is interoperated among a plurality of modules and applications. Such message engines can leverage directory and other UPM services to locate other message engines and their configurations as well as supported messages. The message engine(s) activities can relate to Filtering, Bridging, Routing, Propagation, Transformation and Monitoring of messages events in a customer's manufacturing system, for example. Next, and at 620 message engine scenarios can be determined for the factory automation platform, wherein these scenarios can be employed to map third party product/devices with the factory automation platform. Subsequently, and at 630 messages from various protocols can be normalized to provide a consistent interface where events and modules are sent/received across the system and message bus. Accordingly, and at 640 a common configuration of quality e.g., events, command, event, alarm, scenarios, transactions and messages) can be provided that supports a reference of self-describing messaging. For example, messages for a library can be defined (and restored) for material, equipment, and the other industrial components for a factory . . . “)
In regard to claim 5, the combination of Hood, Keating and Moeller teaches further comprising answering, by the at least one proxy component., the service request without forwarding (e.g. because a conflict is determined)the service request to the services server (see Keating ¶¶ [0043-0045] “ . . . the server or client device may receive, from a second computing process running on the computing platform, a second resource modification request to modify the resource. The second resource modification request may specify the resource identification. Thus, the server or client may determine that the second resource modification request is made to the same resource. The second computing process may be another operator pattern service. The second computing process may also operate in a control loop. At block 308, the server or client device may determine, using the resource modification record, whether the second resource modification request conflicts with the first resource modification request. For example, the server or client may determine whether the second resource modification request is modifying the same resource as the first resource modification request. At block 310, responsive to determining that the second resource modification request conflicts with the first modification request, the server or client device may generate a notification. For example, the server or client device may notify a managing process of the computing platform of a resource modification conflict with respect to the resource. The managing process may implement a node manager, a cluster manager, etc. In some implementations, the server or client device may perform a periodic query of the database to determine whether multiple computing process are making conflicting modifications to a resource. . . “).
The motivation to combine the references is described in claims 1 and 2 and is incorporated herein. Additionally, Keating enables not processing a service request by the proxy if the request generates a conflict.
In regard to claim 6, the combination of Hood, Keating and Moeller teaches further comprising forwarding, by the at least one proxy component, the service request to the directory service component which answers the service request with correct address information on behalf of the addressed services server (see Hood Col 6: Lines 38 – 56 “ . . . When data is required, addressing and associations to that data can be made with the directory 310 of the system. For example, the user can select the data using a logical UPM depiction of the plant. Depending upon the application requesting the data, as well as the role and requirements of the user, the directory interface can provide the appropriate addressing information to the required data. In some cases, such as automation device to automation device communications, the addressing might point directly to the data source/owner. In other cases, such as ERP human resources applications, the association may be to a proxy server of the attributed data so as to isolate the servicing of the data requests from the real time control processing of the automation device that is the data source. It is to be appreciated that the physical location associated with the data can be that of the data source/owner while the communication address may be that of some other device on the network that is performing the role of adding attributes to the data or acting as a proxy server for that data. . . .”).
In regard to claim 7, the combination of Hood, Keating and Moeller teaches wherein the services server is addressable via the at least one proxy component (see Hood Col 6: Lines 38 – 56 “ . . . When data is required, addressing and associations to that data can be made with the directory 310 of the system. For example, the user can select the data using a logical UPM depiction of the plant. Depending upon the application requesting the data, as well as the role and requirements of the user, the directory interface can provide the appropriate addressing information to the required data. In some cases, such as automation device to automation device communications, the addressing might point directly to the data source/owner. In other cases, such as ERP human resources applications, the association may be to a proxy server of the attributed data so as to isolate the servicing of the data requests from the real time control processing of the automation device that is the data source. It is to be appreciated that the physical location associated with the data can be that of the data source/owner while the communication address may be that of some other device on the network that is performing the role of adding attributes to the data or acting as a proxy server for that data. . . .”)
In regard to claim 8, the combination of Hood, Keating and Moeller teaches wherein each of the services comprises a directory service component (see Hood Col 2: Lines 46-64 “ . . . The subject innovation provides for systems and/or methods that facilitate messaging capabilities within a plant (e.g., a unified plant model--UPM) via employing a message engine that normalizes messaging of various messaging protocols and formats, wherein various systems of such plant can map thereto--and provide a consistent interface where events are sent/received consistently across the system. Accordingly, such messaging engines can facilitate communication (e.g., via preferred channels) to other services/products, wherein consistent configuration and management of messaging is supplied across the system. In a related aspect the message engine can supply a common configuration of quality (e.g., events, command, event, alarm, scenarios, transactions and messages) and provide support for a reference and self-describing messaging (in addition to non-self describing messaging.) Moreover, the message engine(s) can leverage directory and other UPM services to locate other message engines and their configurations as well as supported messages. . . .”) , and the registering of the at least one server component on the central directory service component assigned to the respective service takes place with the internal connection data of the central directory service component (see Fig. 3 Col 6: Lines 9 -56 “ . . . The registration component 308 can further interact with a directory 310 that can be employed in a data driven architecture. This directory 310 can provide a logical depiction to the user of the devices in the factory, e.g., based upon a Unified Plant Model (UPM) that is built upon industry standards such as S88, S95. Such logical UPM depiction can further be tailored to the vernacular and plant organization of the customers industry. The directory function can translate the logical view of the factory into physical locations and addresses needed for the required data access and associations to take place. Additionally, in a data driven architecture the directory 310 can provide a logical view of the factory while resolving and/or providing necessary associations to physical location and/or device addressing information. The types of information required could include physical location of the data source/owner, physical location of the data subscriber, communications address for data source/owner and communications addresses for attributed data that can exist at multiple levels, for example. When data is required, addressing and associations to that data can be made with the directory 310 of the system. For example, the user can select the data using a logical UPM depiction of the plant. Depending upon the application requesting the data, as well as the role and requirements of the user, the directory interface can provide the appropriate addressing information to the required data. In some cases, such as automation device to automation device communications, the addressing might point directly to the data source/owner. In other cases, such as ERP human resources applications, the association may be to a proxy server of the attributed data so as to isolate the servicing of the data requests from the real time control processing of the automation device that is the data source. It is to be appreciated that the physical location associated with the data can be that of the data source/owner while the communication address may be that of some other device on the network that is performing the role of adding attributes to the data or acting as a proxy server for that data. . . “) , including network addresses (see Hood Col 14: Lines 35 -39 “ . . . Message destinations can be fully qualified address, or can be a publication to a logical topic. If the destination is a logical topic the message engine can locate subscribers to the topic and dispatch the message to the service interfaces associated with the subscribers . . .”) and ports visible to the at least one server component (see Keating ¶ [0032] “ . . . Registration module 214 may register resources associated with cloud computing services, operator pattern services provided by the cloud computing services, and each resource modification associated with the containerized environment. In some implementations, registration module 214 may store resource data in resource database 202. For example, registration module 214 may perform a serialization operation and translate the resource data into a data interchange format, where the resource data is defined as an attribute-value pair (also known as a name-value pair, a key-value pair, or a field-value pair) or any other serializable value. In some implementations, each resource entry (serialized value) in resource database 202 may include a unique identifier of the resource and a current state of the resource. For example, for a container hosting a website on port 80, the serialized value may include a unique identifier associated with the container networking port, and the current status or state of the container networking port (e.g., assigned to port 80). The serialized value (e.g., attribute-value pair) may be deterministic and not based on any external variables, such as the current time. . . .”).
The motivation to combine the references is described for the rejections of claims 1 and 2 and is incorporated herein. Additionally, Keating enables ports to be assigned in a service request.
In regard to claim 12, the combination of Hood, Keating, and Moeller teaches wherein the at least one proxy component is configured to: receive a service request (see Hood Fig. 7 Col 9: Lines 16-32 as described for the rejection of claim 2 and is incorporated herein);
check a first unencrypted part(e.g. unencrypted form) contained within the service request (see Moeller Fig. 2A ¶ [0060] as described for the rejection of claim 2 and is incorporated herein) such that it is determined whether a recipient addressed within the service request is the central directory service component (see Hood Fig. 3 Col 6: Lines 18-37 as described for the rejection of claim 2 and is incorporated herein) ; and
forward the service request to a receiver, so that subsequent service requests are answered by the central directory service component (see Hood Fig. 3 Col 6: Lines 38 – 56 as described for the rejection of claim 2 and is incorporated herein).
The motivation to combine the references is described for the rejection of claim 2 and is incorporated herein.
In regard to claim 13, , the combination of Hood, Keating, and Moeller teaches wherein the at least one proxy component is configured to (see Hood Fig. 7 Col 9: Lines 16-32 as described for the rejection of claim 3 and is incorporated herein):
receive an unencrypted part of the service request (see Moeller Fig. 2A ¶ [0060] as described for the rejection of claim 3 and is incorporated herein)
check whether the recipient addressed within the service request is a services server (see Hood Col 6 Lines 38 – 56 as described for the rejection of claim 3 and is incorporated herein)
determine the address information of the corresponding internal services server(See Hood Col 6: Lines 57 -67 as described for the rejection of claim 3 and is incorporated herein) ; and
continue establishment of a connection to the determined address information of the internal services server (see Hood Col 6: Lines 64 – 67; Col 7: Lines 1- 6 as described for the rejection of claim 3 and is incorporated herein).
The motivation to combine Moeller with the combination of Hood and Keating is described for the rejection of claim 3 and is incorporated herein.
In regard to claim 14, the combination of Hood, Keating, and Moeller teaches wherein the at least one proxy component is configured for monitoring a connection for transmission of further unencrypted parts of a service request (see Hood Fig. 6 Col 8: Lines 60 – 67; Col 9: Lines 1 -15 as described for the rejection of claim 4 and is incorporated herein)
In regard to claim 15, the combination of Hood, Keating and Moeller teaches wherein the at least one proxy component configured for answering the service request without forwarding the service request (e.g. because a conflict is determined) to the services server (see Keating ¶¶ [0043-0045] as described for the rejection of claim 5 and is incorporated herein).
The motivation to combine the references is described in claim 5 and is incorporated herein.
In regard to claim 16, the combination of Hood, Keating and Moeller teaches wherein the at least one proxy component configured for forwarding the service request to the central directory service component which answers the service request with correct address information on behalf of the addressed services server (see Hood Col 6: Lines 38 – 56 as described for the rejection of claim 6 and is incorporated herein)
In regard to claim 17, the combination of Hood, Keating and Moeller teaches wherein the services server is addressable via the at least one proxy component (see Hood Col 6: Lines 38 – 56 as described for the rejection of claim 7 and is incorporated herein).
In regard to claim 18, the combination of Hood, Keating and Moeller teaches wherein the services server is addressable via only one previously specified port of the at least one proxy component (see Keating ¶ [0035] “ . . . where an operator pattern service requests modification of a networking port on a container (currently hosting a website on port 80) to port 8080, the registration module 214 may determine or receive as input the identification of the operator pattern service, determine or receive as input the identification of the resource, determine or receive as input the serialized current state of the resource (e.g., assigned to port 80), and determine or receive as input the serialized modified state of the resource (e.g., assigned to port 8080). The registration module 214 may then determine a difference between the serialized current state of the resource and the serialized modified state of the resource. The difference may be converted to a list of deterministic values that represent each element of the difference. The registration module 214 may then map the list of deterministic values to the identification of the resource and the identification of the operator pattern service. The mapping(s) may be stored in modification database 206. In other implementations, other registration methods may be used by the registration module 214. Each modification performed by each operator pattern service to each resource may be registered in modifications database 206. . . .”).
The motivation to combine the references is described for the rejections of claim 1 and claim 2 and is incorporated herein. Additionally, Keating provides that a previous defined port can be modified.
In regard to claim 19, the combination of Hood, Keating and Moeller teaches wherein the services server is addressable via only one previously specified port of the at least one proxy component (see Keating ¶ [0035] as described for the rejection of claim 18 and is incorporated herein.)
The motivation to combine the references is described for claim 18 and is incorporated herein.
Conclusion
There are prior art made of record which are not relied upon but are considered pertinent to applicant’s disclosure. They are listed on the PTO-892 accompanying this action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAMES N FIORILLO whose telephone number is (571)272-9909. The examiner can normally be reached on 7:30 - 5 PM Mon - Fri..
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, John A. Follansbee can be reached on 571-272-3964. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/JAMES N FIORILLO/Primary Examiner, Art Unit 2444