T 1663/21 15-10-2024

Reasons for the Decision

1. The claimed invention

1.1 In an industrial automation environment, several industrial machines and devices are installed which have normally a certain "lifecycle". For example, a certain model may be discontinued and replaced by another, newer model. Another model may become obsolete and not be supported by the manufacturer any more. As the application describes, a lifecycle of such machines may have distinct phases, such as "active", "active mature", "discontinued" or "end of life". For the operator/owner of the machines and devices it is important to have an overview at which lifecycle phase each machine and device is, in order to be able to schedule a replacement or to get a supply of spare parts, e.g. for a discontinued model (see e.g. paragraph [0003] of the published application).

1.2 The claimed method scans the machines and devices in the specific automation environment (a network) and obtains information such as product name, serial number or version number for each machine/device ("configuration data"; see e.g. paragraph [0035]). These data are then transferred to a "product compatibility and download center" where, on the basis of the configuration data, the corresponding "lifecycle management data" are retrieved and displayed to a user.

A machine's "lifecycle management data" include information about the specific phase in the lifecycle the machine is currently in (e.g. "discontinued") and possibly the identity of a suggested replacement machine (see e.g. paragraph [0013]).

2. Main request - inventive step

2.1 It is uncontested that document D1 represents a suitable starting point for the skilled person.

D1 describes a diagnostic module for a distributed industrial network. In an industrial network architecture, a diagnostic agent module collects diagnostic information from the industrial machines of the network (see D1, Figure 1 and paragraphs [0009] to [0011], and [0016]).

The diagnostic agent scans (polls) the industrial machines of the network and collects their respective diagnostic information (e.g. error messages and other feedback). The scanning is carried out on the basis of a predetermined configuration, such as a preconfigured list of devices attached to the network. Alternatively, the scanning protocol is provided by the industrial protocol used (paragraph [0031]).

The collected information is stored in a data repository (260) (see Figure 2) and can be accessed by the user via a diagnostic information management station (140) (see Figures 1 and 3; paragraphs [0033] to [0038]).

2.2 A first point of discussion relates to whether the claimed method provides any technical effect.

2.2.1 The appellant referred to decision T 528/07 of the Boards of Appeal and argued that providing indications about the condition (state) of a machine was a technical feature. The lifecycle management data provided by the claimed method informed the user about the state of the machines/devices and prompted them to take action, if necessary (e.g. to replace an obsolete model). The lifecycle management data were thus to be considered as technical data. Moreover, prompted by the displayed lifecycle data, the user was able to e.g. replace an obsolete machine/device in time, ensuring thus the continuous operation of the industrial installation. Therefore, the claimed method produced the technical effect of ensuring the operation of the industrial installation.

2.2.2 The board notes at first that in decision T 528/07 the deciding board, after a brief review of the case law, came to the conclusion that visual indications concerning internal technical conditions of a system (e.g. error messages) were to be considered technical. In case the visual indications related to non-technical conditions of the system they rather related to presentations of information and were not technical (see point 3 and sub-points of the Reasons).

In the present case, the configuration data obtained from the machines/devices relate rather to commercial information (product name, serial number, etc.) than to any operational parameters or diagnostic information, i.e. information related to the operation of the machines. Similarly, the lifecycle management data, such as the information that a certain machine model has been discontinued or information about a possible replacement model, are also of a commercial/administrative nature. Such data do not relate to internal technical conditions of the machine, since they do not convey any information about the operation of the machine or any malfunctions that may have occurred.

The information about whether a certain model has been discontinued, made obsolete or continues to be supported (i.e. remains "active") is not related to any technical state of the machine but rather to a commercial decision by the corresponding manufacturer.

The board, hence, does not agree with the appellant that the lifecycle management data are to be considered technical data. Their cognitive content relates only to information of a commercial nature.

2.2.3 In addition, the claimed method merely displays the obtained lifecycle management data to the user, who is free to take action or simply ignore them. The appellant's argument that the user is prompted by the displayed data to e.g. replace an obsolete machine, ensuring thus the continuous operation of the industrial installation cannot be seen as a technical effect of the claimed method.

Firstly, at the moment the lifecycle management data are displayed to the user, there is no malfunction of any machine in the industrial installation. Even if there were a malfunction in any of the machines, the lifecycle management data do not convey any related information. Secondly, replacing a machine in order to avoid a possible malfunction cannot be considered as a technical solution to any technical problem related to a malfunction of the machine. In the board's view, this is rather an administrative decision avoiding the technical problem rather than solving it.

2.2.4 The board's conclusion is therefore that displaying the lifecycle management data to the user does not produce any technical effect.

2.3 The appellant argued also that the technical effect of the claimed method lied in the manner ("how") the lifecycle management data for the industrial machines and devices within the industrial automation environment were obtained (see also statement of the grounds of appeal, page 3, second paragraph).

2.3.1 The appellant pointed out that the configuration data of the industrial machines and devices were not provided by the user to the product compatibility and download center but they were provided automatically by the claimed method. Errors in the submitted configuration data were thus avoided.

2.3.2 Moreover, the configuration data of the industrial machines and devices were obtained by the claimed method on the basis of a predetermined scanning configuration, following a corresponding scanning protocol. As the application also described, there were several known industrial network protocols (see e.g. paragraph [0051] of the published application). The scanning configuration provided to the method was thus based on one of those known protocols (although no details were included in the claim wording). The user thus did not need to know the configuration data, the identity or the topology of the machines and devices in the industrial environment; they only needed to select a scanning protocol for the method to retrieve those data automatically (see also page 4 of the statement of the grounds of appeal).

According to the appellant, these constituted technical features which distinguished claim 1 of the main request from D1 and they should not have been considered administrative features. In the absence of any relevant disclosure or suggestion in D1, these features were also inventive.

2.3.3 The board does not find these arguments persuasive.

2.3.4 Regarding the scanning configuration, the board notes that in D1 the industrial machines are polled (scanned) on the basis of a user pre-configured list (see e.g. D1, paragraph [0034]). This is taken to correspond to the scanning configuration of claim 1 of the main request. Moreover, D1 mentions the use of the known industrial network protocols in the industrial network, like CIP and SNMP (see e.g. paragraphs [0019] and [0030]).

D1 thus discloses that the machines are scanned on the basis of a scanning configuration selected by the user, just like in the claimed method.

2.3.5 According to D1, once the diagnostic information is collected from the industrial machines, it is stored in a data repository (see e.g. Figure 3, "330", and paragraph [0038]) and then displayed to the user via a diagnostic information management station (see Figure 3, "340", and paragraph [0038]).

In the claimed method, the collected configuration data are transmitted to the product compatibility and download center, the lifecycle management data are received from the center in response and displayed to the user.

The difference between the claimed method and D1 lies thus in that in the claimed method the configuration data collected from the machines/devices are not the data which are displayed to the user, but they are used to obtain the lifecycle management data from an external product compatibility and download center. In D1 it is the diagnostic information (data) collected from the machines that is displayed to the user.

2.3.6 Although transmitting and receiving data are incontestably technical steps, the board takes the view that these steps are dictated by the nature of the processed information (i.e. the cognitive content of the information). In the board's opinion, the cognitive content of the collected information, i.e. what information will be collected from the industrial machines and displayed to the user, is a design decision, unrelated to any technical problem. The designer of the system (business person) decides which information is to be collected and displayed to the user and this decision is given to the skilled person for implementation. Hence, the type of information to be handled by the method would be given to the skilled person as a non-technical requirement for implementation and technical problems that may arise would relate to that implementation.

2.3.7 The lifecycle management data do not represent information related to the specific industrial automation environment but to information related to models of the machines and devices which are present in this environment. Such information is provided normally by the corresponding manufacturers of the machines and devices. It is thus to be expected that such information would not be available within the specific industrial automation environment and would need to be obtained from external sources, e.g. the manufacturers.

In D1 the diagnostic information relates to the specific industrial machines in the specific industrial network and their operation. It is thus to be expected that no external information needs to be obtained in order to provide the user with the relevant diagnostic information.

2.3.8 In the board's opinion, the skilled person wishing to use the technical infrastructure of D1 to obtain lifecycle management data instead of diagnostic information for the industrial machines and devices in the industrial environment, would modify the method of Figure 3 (of D1) in order to include steps related to obtaining such information from an external source, if necessary. The board considers such a modification to be within the skilled person's common general knowledge and practice as it only involves transmitting and receiving data over a network. It would thus be obvious for the skilled person to implement the claimed method using the technical means known from D1.

2.3.9 The board thus agrees with the examining division that the subject-matter of claim 1 of the main request does not involve an inventive step in the sense of Articles 52(1) and 56 EPC.

3. Auxiliary requests

3.1 Compared to claim 1 of the main request, claim 1 of auxiliary request 1 specifies that:

- the scanning protocol is one of CIP, SNMP and WMI; and

- the configuration data include a product name, a firmware version number and a serial number.

3.1.1 Regarding the former added feature, the board notes that all those protocols are known industrial protocols as also the application mentions (see paragraph [0051]). CIP and SNMP are also mentioned in D1, as stated above.

As to the latter feature, the board takes the view that the cognitive content of the collected and transmitted data does not affect the technical operation of the system underlying the claimed method in any way.

3.1.2 The board's conclusion is therefore that neither of these features can support the presence of an inventive step and, hence, the subject-matter of claim 1 of auxiliary request 1 is not inventive for the same reasons as the main request.

3.2 Compared to claim 1 of auxiliary request 1, claim 1 of auxiliary request 2 specifies that the user interface is part of a "customer environment".

3.2.1 The board cannot see any additional limitation of the claimed subject-matter by this feature. In the board's understanding, the industrial automation environment of claim 1 of the main request (and auxiliary request 1) is separate from the product compatibility and download center. So, it can be understood that the industrial automation environment, including the user interface, corresponds to a customer (environment) requesting lifecycle management data from the product compatibility and download center.

3.2.2 Therefore, this additional feature cannot be seen as a basis for the presence of an inventive step and the subject-matter of claim 1 of auxiliary request 2 does is not inventive for the same reasons as auxiliary request 1.

3.3 With respect to claim 1 of the main request, claim 1 of auxiliary request 3 specifies additionally that the lifecycle management data include replacement data for one or more industrial device found to be "discontinued" or at the "end of life".

3.3.1 The appellant argued that the provided information about the replacement of one or more industrial devices prompted the user directly to take action and replace the concerned machine. This was a technical effect because it contributed to ensuring the continuous operation of the industrial installation.

3.3.2 As stated with regard to the main request (see points 2.2.2 to 2.2.4 above) the board's view is that the lifecycle management data cannot be regarded as technical data and that replacing a machine in order to avoid a possible malfunction cannot be seen as a technical solution to any technical problem. The board remains thus of the opinion that, as with the configuration data in auxiliary request 1, the cognitive content of the lifecycle management data cannot contribute to an inventive step in the sense of Article 56. Therefore, the subject-matter of claim 1 of auxiliary request 3 does not involve an inventive step, either.

3.4 Compared to claim 1 auxiliary request 1, claim 1 of auxiliary request 4 defines additionally the following steps the user has to take in order to configure the scan according to the selected protocol:

" ... wherein, upon selecting one of the protocols, a user is prompted to configure the scan with the user interface, wherein

when the selected protocol is CIP, the user is prompted to select a device as a starting point and to set a maximum scanning depth,

when the selected protocol is SNMP or WMI, the user is prompted to enter an Internet Protocol, IP, address range and a maximum number of hops.".

3.4.1 The appellant argued that, by setting the maximum scanning depth or the maximum number of hops, the user could limit the scanning only to a part of the machines/devices in the industrial environment. There were thus savings in the use of the used resources in comparison with scanning all of the machines of the automation environment.

Although the protocols were known, the fact that the claimed method prompted the user to add a maximum scanning depth and a maximum number of hops, encouraged the user to set limitations, which resulted in less computational load and less data being transferred within the industrial automation environment and in particular to the product compatibility and download center.

3.4.2 The board does not follow this argument of the appellant. The claimed protocols are known and setting the necessary parameters for them to be used is considered part of the skilled person's common general knowledge. Moreover, there is nothing in the claim that would prompt the user to limit the scanning only to some of the machines, as the user is always free to set the maximum scanning depth and the maximum number of hops so that the scanning would cover the whole network (environment). The fact that the user has the mere choice to enter a more limited scanning depth or number of hops cannot be considered as a technical effect, since in the end it all depends on the user's individual decision.

In any case, as mentioned earlier, these protocols are also mentioned in D1 and the same considerations regarding the setting of the parameters are also valid for the method of D1, i.e. they are considered to be implicitly disclosed in the prior art.

3.4.3 The board's conclusion is therefore that claim 1 of auxiliary request 4 does not involve an inventive step for the same reasons as auxiliary request 1.

3.5 Claim 1 of auxiliary request 5 combines all the features of respective claim 1 of the main request and auxiliary requests 1 to 4.

As presented above, the board's opinion is that none of these features can support the presence of an inventive step. The same is valid for their combination, as they represent a combination of commonly known and essentially non-technical features.

The subject-matter of claim 1 of auxiliary request 5 does therefore not involve an inventive step, either.

4. Since none of the requests on file is found to be allowable, the appeal must fail (Articles 97(2) and 111(1) EPC).