T 1565/11 (Process control / FISHER-ROSEMOUNT SYSTEMS, INC.) of 3.7.2018

Summary of Facts and Submissions

I. This appeal is against the decision of the examining division to refuse the European patent application No.08165064.0 pursuant to Article 97(2) EPC on the ground of lack of inventive step (Article 56 EPC).

II. In this decision reference was made inter alia to the following documents :

WO 2004/109415 A1 (D1) and

US 2005/0038565 (D2).

The examining division in summary reasoned that claim 1 defined an administrative scheme for process control which was implemented on a data processing system including field devices. This underlying technical infrastructure was known, for example, from D1 or D2.

III. In the statement setting out the grounds of appeal, dated 24 June 2011, the appellant requested that the decision under appeal be set aside and that a patent be granted on the basis of the main or first auxiliary request, filed therewith.

IV. In a communication accompanying the summons to oral proceedings, the Board set out its preliminary opinion that the invention appeared not to involve an inventive step (Article 56 EPC). The Board also communicated its preliminary objections under Articles 84 and 123(2) EPC.

V. In a reply, dated 16 May 2018, the appellant filed a new main, first and second auxiliary request, including amendments seeking to overcome the lack of clarity and added subject-matter objections, together with arguments in favour of inventive step.

VI. At the oral proceedings, the appellant confirmed its requests that the decision under appeal be set aside and a patent be granted on the basis of the main request, first or second auxiliary request.

After due consideration of the appellant's arguments the Chairman announced the decision.

VII. Independent claim 1 of the main request reads as follows:

"1. A method to standardize data properties in a process control environment (100) including a module (128) having at least one function block (136) that define functions performed by a field device (134) to implement a process control routine, wherein the at least one function block (136) cause the field device (134) to acquire measurement values associated with data properties, the method comprising the steps of:

saving the acquired measurement values in the data historian (118) associated with the process control environment;

invoking a history client (120), wherein the history client configured to

associate the at least one function block with one or more keys; and associate at least one data property of interest with the one or more keys; and

obtain measurement values that are associated with the at least one data property of interest;

associate the obtained measurement values with the one of [sic] more keys; and

store the measurement values associated with the one or more keys in a local history database (122) associated with the process control environment (100) without interrupting the saving of the data property in the data historian (118)."

VIII. Independent claim 1 of the first auxiliary request reads as follows :

"1. A system to standardize data properties in a process control environment comprising:

a field device (134);

a function block to be executed on the field device (134), wherein the function block defines one or more data properties relating to sensors of which the function block is aware; and wherein the function block, when executed on the field device acquire measurement values associated with the one or more data properties;

a controller (130) associated with a process control system (124) to execute the function block;

a data historian (118) for saving data properties obtained by the field device;

characterized by

a history client (120) configured with the association of the function block with one or more keys and further with the specifying of data properties of interest that are to be obtained from the execution of the associated function block;

wherein the history client is further configured to, when the function block is executed, obtain measurement values relating to the data properties of interest, associate the obtained measurement values with the one or more keys associated with the function block, and saving the obtained measurement values together with the associated one or more keys in a local history database (122)."

IX. Independent claim 1 of the second auxiliary request essentially adds to the end of claim 1 of the first auxiliary request:

"the system further comprising a history standardizer (130) to receive an instance of the data property of interest and store the instance in a global history database (112);

wherein the history client is further configured to transmit key configuration fields (212) relating to the one or more keys to the history standardizer (110); and

wherein a second history client corresponding to a second process control plant may query the history standardizer (110) for a list including the key configuration fields when the second history client is invoked in the second process control plant.

X. The appellant's arguments can be summarized as follows:

The novel and inventive concept of the invention was a "history client". This unit, without interrupting the saving of data properties in a "data historian" of a process control environment, was configured to allow the association of function blocks with one or more keys. This in turn allowed data properties of interest to be specified, for which measurement values were obtained when the function block was executed.

This allowed both the automatic association of keys with the measurement values by applying the keys associated with the function block being executed and the filtering of measurement values.

The benefit was a storage of measurement data in a form which expedited the search and study of data properties in a process control system. It overcame the drawback of the typical "data historian" which provided only a simple logging of measurement data.

Reasons for the Decision

1. Background

1.1 The invention concerns the standardisation of data properties in a process control environment. Process control systems typically include one or more centralized process controllers, coupled to one or more field devices and at least one host or operator workstation. The field devices perform functions within the process for a product, including the measuring of process parameters. The process controller uses inter alia these process measurements to implement a control routine for the field device(s) to control the operation of the process.

1.2 The system keeps records of settings and measurements in a "historical database", recorded by a "data historian", to allow a system engineer or analyst to investigate if something went wrong, for example. It also allows a comparison to be made between different runs for a particular product. An analyst who wants to compare a production run in plant A with a production run in plant B has to find the corresponding stored measurement data. However, the corresponding and comparable measurement data is stored with different names and is therefore difficult to find.

1.3 The solution of the invention is to store measurement data with user-defined keys. The analyst then just has to look for the keys that go with a specific product and will find the sets of measurement data and can make the comparison.

2. Main request - Article 56 EPC

2.1 In the Board's view, there is a degree of confusion regarding many of the terms used to define the invention in the claims. Therefore, the Board sets out how it interprets these features in light of the description.

2.2 Claim 1 defines the step of associating at least one function block [of a module] with one or more keys and to associate at least one data property of interest with one or more keys.

A function block is interpreted to be the lowest component in a process control system, it defines a function to be performed by the field devices or controllers to implement a process control step, see paragraph [0030]. The invention employs this feature according to its general meaning in process control, see paragraph [0002]. According to the appellant, it is a software step in a process control routine.

The association of a function block with one or more keys is done manually by the system engineer or analyst, see paragraphs [0036] to [0038] and Figure 2A, where keys "Petroleum", "K1" and/or "PK1" are assigned to the function block "Prime Vessel". Having assigned a function block with one or more keys, the data properties "belonging" to this function block, such as temperatures TC1 to TC3 in Figure 2B, are indirectly also associated with the same one or more keys.

2.3 Claim 1 defines the step of obtaining measurement values that are associated with the at least one data property of interest, and to associate the obtained measurement values with the one or more keys.

This feature is interpreted in that the data properties of interest are those which were set to "ACTIVE" by the analyst, see Figure 2B, item 250. In consequence, measurement data is obtained for these data properties of interest and recorded together with the one or more assigned keys, see paragraph [0037].

2.4 Claim 1 also defines the step of storing the measurement values associated with the one or more keys in a local history database without interrupting the saving of the data property in the data historian.

This feature is interpreted in light of paragraphs [0019], [0025], [0036] and [0037], in that a separate unit, claimed as a "history client", possibly produced by a different company, is added to the process control environment in addition to the "data historian", which usually exists in process control environments for the logging of measurement values, see paragraphs [0019] and [0020]. The operation of this "history client" does not affect the operation of the historian in the saving of measurement data. However, the claim says nothing more than that both units operate independently and do not affect each other.

2.5 As the Board understands the description, prior art process control involved the storage of "detailed batch logs", which an operator might want to compare, see paragraph [0005]. Such comparisons were difficult, due to a lack of uniform naming conventions.

2.6 D1 discloses an exemplary process control environment which supports a plurality of field devices. D1 also discloses "function blocks", see page 20, section "iii. Function Blocks", which are the primary means of defining monitoring and control. This corresponds to the feature "function block" of the present invention.

2.7 The invention stores the same data in the same way and in the same place as in the prior art; this is performed by a "data historian". But, additionally, the invention provides a history client which has the function of associating function blocks with one or more keys and, as a consequence, also data properties of interest of this function block and the measurement data obtained for them. The history client obtains measurement values for the data properties of interest and stores these values associated with the one or more keys in a local history database.

2.8 The association of a key with properties of interest is per se a cognitive exercise undertaken by the user. A user faced with the problem that it is difficult to find data sets and compare them, because one set might use one name for a property, while another set might use a different name for the same property, would perform this cognitive activity. This concept cannot therefore contribute to inventive step.

2.9 Thus the objective technical problem is how to label groups of measurement data that are of interest so that they can be easily accessed and analysed.

2.10 Firstly, every table in a relational database must have keys that identify the table's rows. The properties stored in the columns of the table are, therefore, associated with keys, and it is not clear that the invention means anything else by "key". Thus in the Board's view the invention amounts to no more than what is inevitable when the database of prior art "detailed batch logs" is implemented as a relational database.

2.11 Secondly, the concept of labelling process control data, which is physical data, is known from D1 which discloses, page 27, fifth and sixth paragraphs, that objects which make up a function block application are referred to by keys. The Board understands this disclosure as a labelling of function blocks with keys, as it is claimed.

2.12 Therefore, the Board concludes that the concept of labelling groups of data of interest with "keys" in order to easily retrieve it is known from the prior art.

2.13 The provision of a separate unit which implements a labelling of data properties of interest and which stores obtained measurements together with keys is obvious for the person skilled in the art. It is an obvious design choice to either implement these functions on a separate device or to modify the data historian of D1. The easier way is to provide an additional unit.

2.14 The Board therefore concludes that the subject-matter of claim 1 of the main request does not involve an inventive step (Article 56 EPC) over D1 in combination with common general knowledge.

3. Auxiliary request 1 - Article 56 EPC

3.1 Claim 1 of auxiliary request 1 defines a system to standardise data properties in a process control environment. Claim 1 defines features corresponding to those of the method of claim 1 of the main request. The appellant confirmed this view and explained that the intention was to introduce a system claim to make the subject-matter claimed clearly technical.

3.2 Due to the fact that claim 1 of the auxiliary request does in substance not define additional features compared to claim 1 of the main request, the same reasoning applies as for the main request.

3.3 Accordingly, claim 1 of the first auxiliary request does not involve an inventive step (Article 56 EPC).

4. Auxiliary request 2 - Article 56 EPC

4.1 Claim 1 of auxiliary request 2 adds three features relating to a "history standardizer".

4.2 The term history standardizer is used without definition and does not provide functions other than the storing of data and the querying of it.

The first feature provides a global location for the saving of data properties of interest, e.g. measurement data, of a first plant, see paragraph [0053], whereas the other two features provide an exchange of key configurations, which the Board interprets as key profiles, based on paragraph [0038] and paragraphs [0062] to [0063], between the users at different plants. Such a key profile defines a naming convention of keys together with data properties of interest.

4.3 The technical effect of these three features is to speed up setting up the configuration of process control in a second plant, based on data obtained in a first plant. The appellant emphasized that this assures standardisation across the overall system which allows a comparison of measurement data from a first plant with data from a second plant. A user in a second plant can lookup what a user in a first plant has configured and what measurements were obtained.

4.4 The objective technical problem is how to efficiently set up process control in a second plant and how to facilitate the comparison of measurement data of the two plants. Standardisation, in that the same nomenclature is used, see paragraph [0064], does not achieve a technical effect.

4.5 The Board judges that faced with this problem, a person skilled in the art of data processing and process control would consider it self-evident to provide any necessary data from an existing plant to a plant that is to be set up. It would be a matter of routine design to do this by making an existing database globally available or by adding a globally acting unit to the process control environment.

4.6 Accordingly, claim 1 of the second auxiliary request does not involve an inventive step (Article 56 EPC).

Order

For these reasons it is decided that:

The appeal is dismissed.