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 .
Response to Arguments
Applicant's arguments filed 3/6/3026 have been fully considered but they are not persuasive.
The applicant first states that amended claims 1 and 13 create an instance of a configuration for the field device from both device description information of the field device, and from a template configuration. The applicant then states that Hokeness only applies a template, and Kumar analyzes device description files for parameter mining to be collated or consolidated in a tabular data structure. The examiner respectfully disagrees.
The applicant is directed to the updated rejection below that addresses this. However, the statement made by the applicant of what Kumar teaches is not completely understood with how that would apply to the claim limitations of creating an instance and setting values of configuration parameters in the instance to default values given by device description information. Kumar does teach of a parameter miner in par. 20 which mines a device description file and consolidates it into a tabular data structure, but how would that teach against “creating an instance” and “setting values of configuration parameters in the instance to default values” given by the device description information? If anything, it would support that these values are provided from the device description information through the mining. The teaching that the device description information is consolidated into a tabular data structure doesn’t take away from the fact that the device description information is still being provided. The breadth of the claims do not limit this teaching as provided by Kumar.
The applicant further states that Hokeness doesn’t appear to distinguish between unset and already set parameters to selectively override only some of them [the parameters]. The examiner respectfully disagrees.
The applicant is directed to the updated rejection below that addresses this. Further, the claim never states “only some of” the parameters will be overwritten. Regardless, Hokeness does teach in par. 24 that “while the bulk commissioning of the field devices may occur simultaneously, it may also occur sequentially…thus…the bulk commissioning or configuration of the field devices will result in the operation being automatically performed, either in parallel or sequence on the specified field device.” This would clearly imply, or it could be obvious, that not all of the field devices would need to be commission and/or be configured.
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 4 and 16 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 1 and 13 were amended to state that the default values are given by the device description information and the template. Claims 4 and 16 (which are dependent on claims 1 and 13, respectively) state that the values are given by the device description information and/or from the template. These claims contradict one another due to claims 4 and 16 stating that the default values can be provided in an alternate form, whereas claims 1 and 13 state the default values will be provided by both.
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.
Claims 1-4, 6, 8-16, 18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Hokeness et al. (WO 2015/035024), as provided in the IDS filed on 3/20/2023, in view of Kumar et al. (2016/0291563).
As per claims 1 and 13, Hokeness teaches a computer and a computer-implemented method for configuring a field device for use in an industrial plant (Pars. 5 and 16), comprising:
creating, from a template configuration, T, stored in association with the field device and/or in association with a type of the field device, an instance of a configuration for the field device (Par. 22);
setting values of configuration parameters in the instance to default values given by the template T (Hokeness teaches that a user can generate a configuration process (that includes a set of device parameters (values)) for a field device by providing a template as well as an instance, and that in creating the template, the user can easily define and implement suitable corporate standards (Pars. 22, 24; Par. 16 also describes providing a generic (default) configuration as well);
obtaining, from a data store (database) distinct from a semantic library, values of configuration parameters stored in association with the field device (Hokeness teaches that the field device configurations (which include parameters (values)) are stored in an asset management system database, where an asset management system receives the stored configurations from the database and automatically applies the configurations to the field devices – Pars. 22-24; Hokeness doesn’t teach of a semantic library (see Kumar below – Fig. 1, pars. 8-10 – semantic dictionary, which is clearly distinct from device description file of the field device), so the asset management system database taught by Hokeness would be distinct from such a library);
writing each value obtained from the data store to a configuration parameter in the instance…wherein writing comprises populating unset configuration parameters and selectively overriding already set configuration parameters with new values; and provisioning the field device with the instance of the configuration (Hokeness teaches that the field device configurations (which include parameters (values)) are stored in an asset management system database, where an asset management system receives the stored configurations from the database and automatically applies the configurations to the field devices – Pars. 22-24. Specifically, par. 24 teaches that “a bulk commissioning of the field devices is performed wherein each individual device is provided with the configuration information stored in the user template that is mapped to that respective field device.” The fact that the field devices are “commissioned” and “provided” with configuration information clearly teaches that either the field devices do not have configuration parameters (are unset) and/or any configuration parameters that they do have will be overwritten. Hokeness further teaches that a user can view the differences between the configuration information set forth in the field device and that specified in the applicable user configuration, and can further identify the devices with “incorrect” device configuration settings (Par. 31). That is, devices that have incorrect configuration settings have not yet been set from the template, and in order to correct these configuration settings, the correct (new) configuration settings will override the incorrect (already set) configuration settings).
However, Hokeness doesn’t teach determining semantic meanings of configuration parameters in the instance by obtaining, from a semantic library, a semantic meaning stored in association with the field device and with a name of each respective configuration parameter, and writing each value to a configuration parameter in the instance whose semantic meaning matches the semantic meaning associated with the value.
Kumar teaches a method of replacing a first field device with a second field device, wherein it retrieves a device description file associated with the first field device, identifies parameters (values) for mapping, generates a first object (instance) by mapping parameters of the second field device to a parameter from identified parameters based on a first index, where the first index is determined based on semantic similarity (matching), using a semantic analyzer, between a name of the parameter (semantic meaning) of the second field device and a name of the identified parameter using a semantic dictionary (library) (Fig. 1, Pars. 8-11, 21, 26, 27, 31, 33). Kumar further teaches that once the configuration file is generated, it is then transmitted to the second field device (that is, the configuration file is written to the second field device) for commissioning operation of the second field device (Par. 8).
It would have been obvious to a person skilled in the art at the time the invention was filed to include the teachings of Kumar of configuring a field device into the method/computer taught by Hokeness. This would have been obvious because both Hokeness and Kumar are in the same field of endeavor of configuring field devices, and Kumar’s method allows for seamless reusability of field device configuration files and easy comparison when configuring a second field device (Pars. 5, 42).
Hokeness also doesn’t specifically teach that the instance and the values of the configuration parameters are from device description information of the field device.
Kumar teaches that when a first field device is being replaced by a second field device that a device description file associated with the first field device is received and analyzed (Par . 8). Kumar further teaches that the parameters from the device description file can be identified using a lookup table (Par. 11).
It would have been obvious to a person skilled in the art at the time the invention was filed to include the teachings of Kumar of retrieving configuration parameters of a field device using a device description file associated with the first field device into the method/computer taught by Hokeness. This would have been obvious because 1) Hokeness clearly teaches that the device configuration information can be provided by a template or generic configuration for the field devices (Par. 16), and 2) Kumar clearly teaches that it is well known to copy the configuration of a previous field device into a new field device when replacing the previous field device (Pars. 2, 3, 8). Based on Hokeness implying that generic configuration can be provided outside of a template, and Kumar teaching that it is well known to retrieve a device description file from the device itself or from another means (lookup table) associated with the field device, a person skilled in the art would have understood that using a template (like that taught by Hokeness) is not the only option to retrieve configuration parameters of a field device.
As per claims 2 and 14, Kumar teaches the method/computer of claims 1 and 13, wherein the device description information comprises an Electronic Device Description, EDD, and/or a Device Package, DP, of the field device (Abstract, Pars. 43 – even though Kumar doesn’t define the acronym, EDD, in par. 43, it does stand for Electronic Device Description, which is also well known as described by the applicant’s admission in par. 4 of the specification).
As per claims 3 and 15 Hokeness teaches the method/computer of claims 1 and 13, wherein setting the values of configuration parameters in the instance includes setting the values to the default values given by the device description information, and wherein, for one and the same configuration parameter, a value obtained from the template T takes precedence over a default value given by the device description information (Hokeness teaches that template or generic (default) configurations can be provided (Par. 16), and further teaches that a user can employ an asset management system to configure field devices using a template, in which device parameters are customized by the user (Pars. 16, 22). Since only one of a template or generic configuration can be provided to a device, and since a user can customize their own configuration, it is clearly implied that the customized configuration would indeed take precedence over the generic (default) configuration).
At a minimum, it would have been obvious to a person skilled in the art that the configuration customized the user would take precedence since it allows a user to employ corporate standards that can be easily defined and implemented across a process plant unit, across the entire plant, or across an entire enterprise (Hokeness – Par. 16).
As per claims 4 and 16, Kumar teaches the method/computer of claims 1 and 13, wherein, for one and the same configuration parameter, a value obtained from the data store takes precedence over a default value given by the device description information, and/or over a value obtained from the template T (Kumar teaches analyzing the device description file, generating a first object by mapping parameters of a filed device to a parameter from identified parameters based on a first and second index, and then generating a configuration file based on the device description file and the generated first object (Par. 8). The first index is determined based on semantic similarity between a name of the parameter of a field device and a name of a parameter from an identified parameter using a semantic dictionary (data store) (Par. 9). It is clear that any values of configuration parameters are from what is described above and not a default value given by the device description information, hence the process described above takes precedence.
As per claims 6 and 18, Hokeness teaches the method/computer of claims 1 and 13, wherein multiple field devices that are connected to a network of the industrial plant are provisioned in bulk (Figs. 2, 3 and 6, Pars. 22, 23).
As per claims 8 and 20, Hokeness teaches the method/computer of claims 1 and 13, further comprising prompting a user for input of a value of a configuration parameter that is required for startup of the field device but not provided by any of the device description information, the template T, and the data store (Par. 22 – Hokeness teaches that a user is able to generate a user configuration process where the user provides a template/user configuration…wherein a user configuration is a set of device parameters customized by a user to be used as a model for other device configurations. Par. 18 describes that workstations each have a user interface that includes a screen and a user input device, and par. 21 describes that a user, seated at a workstation, can interact with the asset management system in order to perform a variety of high-level functions relative to the field devices. These teachings could read on this claim limitation due to the breadth of the claims. For example, “prompting a user for input of a value of a configuration parameter” could fall under any type of “interacting” that the user is doing with asset management system through the user interface taught by Hokeness. Also, configuration parameters for field devices are essential for startup. Last, the fact that the user configurations can be “customized” and appear to be in addition to or in place of a template (such as “template/user configuration” taught by Hokeness), would be provided directly from the user and not provided by any of the device description information, the template and the data store).
As per claim 9, Hokeness teaches the method of claim 1, wherein the field device is a device that is in direct physical interaction with an industrial plant, and/or with an industrial process executed on this industrial plant. (Fig. 6, Pars. 16, 27).
As per claim 10, Kumar teaches the method of claim 9, wherein the field device is a sensor device that is disposed to supply at least one measurement value of a physical quantity to a distributed control system, DCS, of the industrial plant, and/or an actor device that is to enact a control command received from the DCS on the plant (Pars. 4, 36).
As per claim 11, Hokeness teaches the method of claim 1, wherein the method steps of creating and provisioning are performed by an Asset Management System, AMS, of the industrial plant (Pars. 21-24).
As per claim 12, Hokeness teaches the method of claim 1, further comprising executing at least one industrial process on the industrial plant with the participation of the field device (Fig. 6, Pars. 16, 27).
Claims 7 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Hokeness et al. in view of Kumar et al., as applied to claims 1, 6, 13 and 18 above, and further in view of Meyer et al. (2010/0293363).
As per claims 7 and 19, Hokeness and Kumar do not teach wherein the provisioning of the multiple field devices with instances of configurations is performed in response to a predetermined condition regarding a load on the network being met.
Meyer teaches of a method for configuring field devices on a field bus, wherein the loads placed on the communication links are minimized (Abstract, Par. 7). Meyer further teaches that resource-limited field devices on a field bus with a highly restricted bandwidth (predetermined condition) requires special techniques in order to be able to download changes in configuration data and parameter data to the field devices (Par. 6). This is done by having a configuration tool configure process automation functions, including the configuration and parameters of the field device, before any communications link has been established with the field devices (Par. 9).
It would have been obvious at the time the invention was filed to include the teachings of Meyer in the method/computer taught by Hokeness and Kumar above. This would have been obvious because Hokeness, Kumar and Meyer are all in the same field of endeavor of configuring field devices, and Meyer further points out that when there are resource-limited field devices on a field bus with a highly restricted bandwidth (predetermined condition), that this requires special techniques for configuring these devices (par. 6). A person skilled in the art would have looked toward the teaching of Meyer to accomplish this.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SCOTT T BADERMAN whose telephone number is (571) 272-3644. The examiner can normally be reached 6:00AM - 3:00PM, M-Th., every other Friday off.
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 Cottingham, can be reached at 571-272-1400. 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.
/SCOTT T BADERMAN/Supervisory Patent Examiner, Art Unit 2118
Prosecution Insights