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 .
The application of Emerson et al. for a “process automation alarms for distributed control nodes” filed on June 25, 2025 has been examined.
This application claims priority to a 371 of PCT/IB2023/063299, which is filed on December 27, 2023.
The PCT/IB2023/063299 is a CON of 18/090,333 filed on December 28, 2022, now US# 12,406,570.
The PCT/IB2023/063299 is a CON of 18/090,282 filed on December 28, 2022, now US# 12,562,956.
The PCT/IB2023/063299 is a CON of 18/090,342 filed on December 28, 2022, now US# 12,455,561.
A preliminary amendment to the claims 22-61 has been entered and made of record.
Claims 22-61 are cancelled.
Claims 1-21 are pending.
Specification
The disclosure is objected to because of the following informalities: Under cross references to related applications CON status needs to be updated. This application claims priority to a 371 of PCT/IB2023/063299, which is filed on December 27, 2023.
The PCT/IB2023/063299 is a CON of 18/090,333 filed on December 28, 2022, now US# 12,406,570.
The PCT/IB2023/063299 is a CON of 18/090,282 filed on December 28, 2022, now US# 12,562,956.
The PCT/IB2023/063299 is a CON of 18/090,342 filed on December 28, 2022, now US# 12,455,561.
Claim Objections
Claim 10 is objected to because of the following informalities: “alarm monitoring” in line 4 should be “alarm monitoring.”. An appropriate correction is required.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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.
Claims 1, 6-11 and 15-21 are rejected under 35 U.S.C. 103 as being unpatentable Inoue et al. (JP2002062933) in view of Wu et al. (CN111416731) (hereinafter “Wu’s 731”).
Regarding Claim 1, Inoue et al. disclose a method (page 3 paragraphs 0023 to page 4 paragraph 0027; see Figures 1 to 10) comprising:
receiving, via an alarm configuration interface, one or more instances of user interface input that collectively define (i.e. development of the input/output condition, diagnostic condition, and setting parameter definition description may be performed using a text-based tool such as an editor. In addition, it becomes easier to use if an application excellent in GUI (Graphical User Interface) that operates on a PC is prepared and the condition can be set by operating a mouse or the like) (page 9 paragraph 0082):
one or more conditions to be used for a process automation alarm (i.e. Input/output conditions, diagnostic conditions, and setting parameters are set according to the application. Input/output defines the format of the data group used for input/output. Diagnostic conditions include, for example: ・Comparison of collected data with constants, ・Comparison of collected data with other data based on a predefined relational expression) (page 8 paragraph 0076; page 9 paragraph 0078), and
a function block identifier of a function block, of a process automation system, via which the conditions are to be monitored (i.e. the setting parameter is a parameter that can be changed by digital communication after downloading the diagnostic function block, and is typically a constant for diagnosis, a coefficient of a relational expression, an operation mode setting (operation, non-operation, etc.) and so on. The time-series data storage means stores the data specified at each set time interval in the memory (storage means 26) (page 8 paragraph 0072 to 0077; see Figures 7 and 8);
responsive to receiving the instances of user interface input (i.e. development of the input/output condition, diagnostic condition, and setting parameter definition description may be performed using a text-based tool such as an editor. In addition, it becomes easier to use if an application excellent in GUI (Graphical User Interface) that operates on a PC is prepared and the condition can be set by operating a mouse or the like) (page 9 paragraphs 0080 to 0082):
generating an alarm configuration file that specifies the conditions (i.e. input/output conditions, diagnostic conditions, and parameter definitions are described using a description formula or a programming language. The programming language may be a language specialized for the diagnostic function block or may be based on a general high-level language such as C language or BASIC language) (page 9 paragraphs 0080 to 0082), and
storing the alarm configuration file in association with the function block identifier for the function block (i.e. the high-level computer 1 manages alarms. It is considered that the generated alarm is managed by a system (typically called “device management system” or the like) in the host computer 1 along with other general process alarms and device alarms. This is performed not only with time-series management of device alarms but also with device parameter changes and repair history. It is assumed that the system also manages the change history of the diagnostic conditions and parameters of the diagnostic function block 7) (page 9 paragraph 0085; see Figure 7);
subsequent to storing the alarm configuration file in association with the function block identifier (i.e. the data required for diagnosis is connected after the download is completed. This is similar to the normal connection setting of input/output data between function blocks. Specifically, in the case of a Foundation Fieldbus (Foundation Fieldbus) protocol, input/output settings on an application such as a link object (Link Object) and a VCR (Virtual Communication Relationship) and communication are set. Make connection settings) (page 9 paragraphs 0084 to 0085):
determining that a distributed control node (DCN) of the process automation system locally utilizes the function block, identified by the function block identifier, in alarm monitoring (i.e. the diagnostic function block 7 is built in the actuator 4, but it can be present in any device on the field bus 5. Data necessary for diagnosis can be collected through the field bus 5, and therefore may be provided in another device (field device) such as the sensor 3 or the I/O 2. It is also possible to give the diagnostic result output of a certain diagnostic function block 7 as an input to another diagnostic function block 7) (page 9 paragraph 0083-0084); and
transmitting, via a network of the process automation system, the retrieved alarm configuration file to the DCN in response to determining that the DCN utilizes the process automation function block, identified by the function block identifier, in alarm monitoring (i.e. the input/output conditions, diagnostic conditions, and parameter definitions described are compiled into a format that the diagnostic function block can understand, and then downloaded to the diagnostic function block. Or, if the device has the ability to understand, download the text data directly to the diagnostic function block without compiling. The simplest way to download is to use fieldbus communication online to download from the higher-level control system 1 shown in FIG. 7 via I/O2, but offline to connect a separate communication line to each device. It is also possible to connect and download) (page 9 paragraph 0080 to 0085; see Figure 9),
wherein transmitting the retrieved alarm configuration file causes the DCN to implement alarm monitoring that conforms to the retrieved alarm configuration file (i.e. the data required for diagnosis is connected after the download is completed. This is similar to the normal connection setting of input/output data between function blocks. Specifically, in the case of a Foundation Fieldbus (Foundation Fieldbus) protocol, input/output settings on an application such as a link object (Link Object) and a VCR (Virtual Communication Relationship) and communication are set. Make connection settings) (page 9 paragraph 0080 to 0085; see Figure 9).
However, Inoue et al. did not explicitly disclose storing in the database and retrieving the alarm configuration file from the database based on it being stored in association with the function block identifier.
In the same field of endeavor of a field device in an alarm system, Wu’s 731 teach that storing in the database (i.e. store the operation record in the database) (page 2 paragraph 10; page 4 paragraph 12; see Figure 1) and retrieving the alarm configuration file from the database based on it being stored in association with the function block identifier (i.e. the index value of each alarm scheme in the cloud alarm file library is unique. After the domain experts update and upgrade the original alarm scheme in the cloud alarm file library, the update thread is awakened, and the update thread is found in the MySQL database according to the index value For edge nodes that have used the original alarm scheme, the update thread is responsible for sending information to all involved edge nodes, and the edge node resends a new configuration request, executes the process of configuring the alarm scheme again, and completes the upgrade process of the alarm program) (page 2 paragraphs 11-12; page 4 paragraph 12; see Figure 1) in order to complete the linking operation of multiple different functional programs.
At the time of the effective filing date of the current application, it would have been obvious to a person of ordinary skill in the art to recognize the need for storing the operation record in the database and retrieving from the alarm database taught by Wu’s 731 in the method to configure the control system of the diagnostic function is to collect information from the device of Inoue et al. because storing the operation record in the database and retrieving from the alarm database would provide a customized alarm program for monitoring complex alarm conditions in the alarm monitoring system.
Regarding Claims 6-9, Inoue et al. in view of Wu’s 731 disclose the method of claim 1, Inoue et al. disclose wherein receiving, via the alarm configuration interface, the instances of user interface input that collectively define the one or more conditions and the function block identifier, comprises: receiving one or more initial of the instances of user interface input that define the function block identifier; and receiving one or more subsequent of the instances of user interface input that define the conditions to be used for the process automation alarm (i.e. development of the input/output condition, diagnostic condition, and setting parameter definition description may be performed using a text-based tool such as an editor. In addition, it becomes easier to use if an application excellent in GUI (Graphical User Interface) that operates on a PC is prepared and the condition can be set by operating a mouse or the like. Also, in the case of setting a typical diagnostic format in advance, for example, the relational expression between the control valve opening and the flow rate, and judging the abnormality from the data of the control valve opening and the flow rate when the process is actually operating will be easier to use if a template is prepared in advance and consideration is given to inputting conditions to the minimum necessary) (page 9 paragraph 0082).
Regarding Claims 10-11, Inoue et al. in view of Wu’s 731 disclose the method of claim 1, Inoue et al. disclose wherein determining that the DCN locally utilizes the function block in alarm monitoring comprises: determining, based on a pre-stored association of the DCN to the function block, that the DCN locally utilizes the function block in alarm monitoring (i.e. the high-level computer 1 manages alarms. It is considered that the generated alarm is managed by a system (typically called “device management system” or the like) in the host computer 1 along with other general process alarms and device alarms. This is performed not only with time-series management of device alarms but also with device parameter changes and repair history. It is assumed that the system also manages the change history of the diagnostic conditions and parameters of the diagnostic function block 7) (page 9 paragraph 0083-0085).
Referring to claims 15 and 21, Inoue et al. in view of Wu’s 731 disclose a method and a system, although different in scope from the claim 1, the claims 15 and 21 contain similar limitations in that the claim 1 already addressed above therefore claims 15 and 21 are also rejected for the same obvious reasons given with respect to claim 1.
Referring to claims 16-20, Inoue et al. in view of Wu’s 731 disclose the method of claim 15, wherein generating the graphical output that is dependent on the selection of the function block identifier comprises: generating the graphical output in dependence on a function block type that is specified by the function block identifier (i.e. development of the input/output condition, diagnostic condition, and setting parameter definition description may be performed using a text-based tool such as an editor. In addition, it becomes easier to use if an application excellent in GUI (Graphical User Interface) that operates on a PC is prepared and the condition can be set by operating a mouse or the like. Also, in the case of setting a typical diagnostic format in advance, for example, the relational expression between the control valve opening and the flow rate, and judging the abnormality from the data of the control valve opening and the flow rate when the process is actually operating will be easier to use if a template is prepared in advance and consideration is given to inputting conditions to the minimum necessary) (page 9 paragraph 0082).
Claims 12-13 are rejected under 35 U.S.C. 103 as being unpatentable Inoue et al. (JP2002062933) in view of Wu et al. (CN111416731) (hereinafter “Wu’s 731”) as applied to claim 1, and further in view of Wu et al. (CN11508214) (hereinafter “Wu’s 214”).
Regarding Claim 12, Inoue et al. in view of Wu’s 731 disclose the method of claim 1, however, Inoue et al. in view of Wu’s 731 did not explicitly disclose wherein transmitting the retrieved alarm configuration file to the DCN in response to determining that the DCN utilizes the process automation function block, comprises:
transmitting, to the DCN, an initial communication that indicates availability of an
updated alarm configuration file;
receiving, from the DCN and after the initial communication, an alarm configuration request from the DCN; and
transmitting the retrieved alarm configuration file to the DCN in response to receiving the alarm configuration request from the DCN.
In the same field of endeavor of a field device in an alarm system, Wu’s 214 teaches that transmitting the retrieved alarm configuration file to the DCN in response to determining that the DCN utilizes the process automation function block, comprises:
transmitting, to the DCN, an initial communication that indicates availability of an
updated alarm configuration file; receiving, from the DCN and after the initial communication, an alarm configuration request from the DCN (i.e. Send an alarm configuration request to the cloud server. Wherein, the alarm configuration request includes at least one alarm device information. In this step, the edge device sends an alarm configuration request to the cloud server, and correspondingly, the cloud server receives the alarm configuration request sent by the edge device) (page 3 lines 25 to 37; see Figure 1); and
transmitting the retrieved alarm configuration file to the DCN in response to receiving the alarm configuration request from the DCN (i.e. Send the alarm program to the edge device.
In this step, the cloud server sends the determined corresponding alarm program to the edge device, and correspondingly, the edge device receives the alarm program) (page 4 lines 16 to 22; see Figure 1) in order to run alarm program of the alarm device.
At the time of the effective filing date of the current application, it would have been obvious to a person of ordinary skill in the art to recognize the need for sending the alarm configuration request to the cloud server and sending the alarm program to the edge device to implement alarm control of the alarm device taught by Wu’s 214 in the method to configure the control system of the diagnostic function is to collect information from the device of Inoue et al. in view of Wu’s 731 because sending the alarm configuration request to the cloud server and sending the alarm program to the edge device to implement alarm control of the alarm device would provide a customized alarm program for the control system.
Regarding Claim 13, Inoue et al. in view of Wu’s 731 disclose the method of claim 1, Wu’s 214 disclose wherein the function block identifier is specific to the function block and is not assigned to any other function block of the process automation system (i.e. wherein the alarm configuration request comprises information of each alarm device, such as alarm device identification, alarm device type, alarm type, wherein the alarm device identification for unique identification alarm device, such as available number 0001, 0002 identification, alarm device type, such as in the base station environment, alarm device type can be base station box, storage battery group and so on, alarm type comprises fire alarm, voltage alarm and so on) page 3 line37 to 44).
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable Inoue et al. (JP2002062933) in view of Wu et al. (CN111416731) (hereinafter Wu’s 731) as applied to claim 1, and further in view of Berger et al. (US# 9,100,301).
Regarding Claim 14, Inoue et al. in view of Wu’s 731 disclose the method of claim 1, however, Inoue et al. in view of Wu’s 731 did not explicitly disclose further comprising:
authenticating a user that provides the one or more instance of user interface input;
wherein storing, in the database, the alarm configuration file in association with the
function block identifier is further in response to authenticating the user.
In the same field of endeavor of a manage an alarm system, Berger et al. teaches that disclose further comprising: authenticating a user that provides the one or more instance of user interface input; wherein storing, in the database, the alarm configuration file in association with the function block identifier is further in response to authenticating the user (i.e. an alarm cataloger 122. The example alarm cataloger 122 of FIG. 1 extracts alarm configurations from the monitoring agents 106 executing on the servers 104. In some examples, the alarm cataloger 122 extracts an alarm configuration by instructing a monitoring agent 106 to generate a package including the alarm configuration information and to send the package to the alarm cataloger 122 and/or to the alarm linkage database 114. For example, the package may be a text file or an eXtensible Markup Language (XML) document) (column 9 lines 31 to 45; column 12 lines 1 to 13; see Figures 6 and 9).
At the time of the effective filing date of the current application, it would have been obvious to a person of ordinary skill in the art to recognize the need for authenticating the user and storing the alarm configuration file taught by Berger et al. in the method to configure the control system of the diagnostic function is to collect information from the device of Inoue et al. in view of Wu’s 731 because authenticating the user and storing the alarm configuration file would improve security in the alarm program for the control system.
Allowable Subject Matter
Claims 2-5 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Referring to claim 2, the following is a statement of reasons for the indication of allowable subject matter: the prior art either alone or in combination fails to disclose or suggest limitations that wherein determining that the DCN locally utilizes the function block in alarm monitoring comprises:
receiving, via the network of the process automation system, an alarm configuration
request transmitted by the DCN, and
determining that the DCN locally utilizes the function block in alarm monitoring
responsive to the alarm configuration request including the function block identifier; and
wherein retrieving the alarm configuration file from the database and transmitting the retrieved alarm configuration file to the DCN are responsive to receiving the alarm configuration request.
Claims 3-5 depend either directly or indirectly upon independent claim 2; therefore, these claims are also allowed by virtue of their dependencies.
Any comments considered necessary by applicant must be submitted no later than the payment of the issue fee and, to avoid processing delays, should preferably accompany the issue fee. Such submissions should be clearly labeled “Comments on Statement of Reasons for Allowance.”
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Refer to the enclosed PTO-892 for details.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NAM V NGUYEN whose telephone number is 571-272-3061. Fax number is (571) 273-3061. The examiner can normally be reached on 8:00AM-5:00PM Monday to Friday.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Quan-Zhen Wang can be reached on 571-272-3114. The fax phone numbers for the organization where this application or proceeding is assigned are 571-273-8300 for regular communications.
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).
/NAM V NGUYEN/
Primary Examiner, Art Unit 2685
