T 1051/15 (Software upgrade/ABB) 17-06-2021
Téléchargement et informations complémentaires:
A low or medium voltage electric power distribution network
Summary of Facts and Submissions
I. The appeal is directed against the decision of the examining division, dated 22 December 2014, to refuse application No. 10176966.9 for lack of clarity, and for lack of inventive step over document
D1 US 2004/092255 A1.
II. A notice of appeal was received on 16 February 2015. The appeal fee was paid the same day. With a statement of grounds of appeal received on 21 April 2015, the appellant filed claims 1-3 according to an auxiliary request. It requested that the decision under appeal be set aside and that a patent be granted on the basis of
- claims 1-7 according to the main request underlying the decision under appeal, filed with a letter of 4 November 2014, or
- claims 1-3 according to the auxiliary request, filed with the statement of grounds of appeal.
The other application documents are the same as indicated in the appealed decision.
III. In its summons to oral proceedings, the board gave reasons for its preliminary opinion that the independent method claims of both requests lacked an inventive step over common general knowledge.
IV. Oral proceedings were held on 17 June 2021 in the form of a videoconference. At the end, the chairman announced the board's decision.
V. Claim 1 of the auxiliary request reads as follows (amendments to independent method claim 7 of the main request being underlined or [deleted: struck through]):
"1. A method for performing a software upgrade in at least a P&C device of a low or medium voltage distribution network, said at least a P&C device communicating with a computer station (11) through a communication network (12),
characterised in that said computer station executes, according to a batch processing mode, downloading sessions of software packages (Fi, FN) to said P&C devices in order to upgrade the software of said at least a P&C device;
wherein said computer station executes a plurality of processing threads during a downloading/uploading session of said software packages, each of said processing threads being executed for performing the task of downloading one software package to said at least a P&C device in parallel and independent manner with respect to other P&C devices;
said method comprising the following steps:
- selecting a software package to be downloaded from said computer station to said at least a P&C device;
- performing compatibility checks on the software package to be downloaded;
- opening a downloading session from said computer station to said at least a P&C device;
- closing said downloading session;
- receiving a software package downloaded by said computer station (11);
- storing the software package downloaded by said computer station (11);
- saving a back-up copy of the old software that is already resident in said at least a P&C device;
- checking whether the software package downloaded from said computer station (11) have been correctly stored [deleted: a consistency check between a configuration tool of the computer station and said at least a P&C device being performed to validate the upgraded software];
- waiting for a message confirming that the software packages downloaded by said computer station (11) have been stored correctly;
- if said message is not received in a predefined period of time, sending instructions to recover said back-up copy of the old software, said old software being used to continue the normal operations of said at least a P&C device."
Reasons for the Decision
1. Summary of the invention
1.1 The application relates to upgrading software of client computers in an electric power distribution network. Each client computer is part of a "P&C device" (= protection and control device) or "IED" (= Intelligent Electronic Device, see A2 publication, paragraph [2], first sentence and figure 1).
1.2 First, a (human) operator selects the software to be downloaded at a server computer 11 (called "computer station" or "computerized station"; ([36]-[37]; [45]).
1.3 Then, the operator starts the sending session ([45]) at the server which downloads in "batch processing mode" in a "parallel and independent manner" ([46]; original claims 1 and 4; claim 2 of the main request; claim 1 of the auxiliary request) software packages F1 to FN over a communication network 12 (e.g. an Ethernet LAN, [30]) to clients IED1 to IEDN ([31]; figure 1).
1.4 After the operator has selected the software and before the download starts, the server performs "some compatibility checks" on the software ([37]; original claim 6; see also claim 4 of the main request and claim 1 of the auxiliary request). There are no details about these compatibility checks in the application (in particular nothing about a reaction to a negative check result).
1.5 For security reasons (e.g. in case of a "sudden power-fail" while storing or in case the new software is not working), the client stores a back-up copy of the old software ([32], second sentence; [39], second and third sentences; original claim 2).
1.6 After the download, the server (configuration tool, [36]) and each IED client cooperatively check the consistency of the installed software package to "validate it" and to restore (recover) the previous software if the check fails ([20]). This is also called "checking whether the software packages downloaded by said computer station (11) have been correctly stored" ([34] or claim 1 of the auxiliary request). According to the board, this might be intended to detect transmission errors. It is done by sending two messages back and forth. Firstly, the server waits for a message from the client after the latter has stored and "checked" the software ([34]; original claim 3). It would seem to the board that the message might contain a checksum of the stored software. If the server does not receive this message after a predefined period of time, it sends a message to the client to recover the back-up of the old software (loc. cit.).
1.7 In the auxiliary request, it is additionally specified that the downloading is performed in one session per client, the session being closed afterwards ([37]). Furthermore, one thread per client download is created ([44]).
2. Inventiveness
2.1 In the following, the board will only consider method claim 1 of the auxiliary request, since it is more specific than corresponding independent method claim 7 of the main request. It should be noted that the consistency check of the main request, which is not included in the auxiliary request, does not go beyond the other checks in the auxiliary request, as the check whether the downloaded software package was saved correctly can be subsumed under the consistency check. Therefore, a finding of lack of inventive step in relation to the auxiliary request would also apply to the main request.
2.2 The board is of the opinion that the invention mainly results in an obvious combination of well-known options commonly used for software updating over a network. According to the board, at the filing date, the skilled person knew the following options for software updating:
- having a human operator select the software to be downloaded either at the download server or at another (remote) server;
- downloading over a network (wired or wireless) the software from a server to a client, the initiative to start the download lying either with the server (i.e. with its operator) or the client;
- downloading to one client or to multiple clients (serially or in parallel);
- checking the compatibility of the software with the client hardware and/or (other) software residing on the client, before or after the download (i.e. at the server or at the client);
- saving at the client or at the server a back-up copy of the (old) software to be replaced, in order to recover it after failure;
- checking for transmission errors either at the server or at the client (e.g. by building checksums of the software at both the server and the client, and by sending one checksum either to the server or to the client in order to compare them there, i.e. either at the server or at the client);
- if necessary, recovering the old software (e.g. after a transmission error message, or in case of no message: after a timeout).
2.3 The appellant did not question in respect of any of these assumptions whether they belonged to the common general knowledge of the person skilled in the art.
2.4 In the board's judgement, the skilled person would have chosen from these options at will, depending on the context in which the software update was to take place.
2.5 A particular combination of the above options would involve an inventive step only if it produced a technical effect going beyond the effects for which these individual options are intended and commonly used.
2.6 That is not the case here.
2.7 As to the argument in the grounds of appeal (middle of page 5) that the invention was particularly suitable for electric power distribution networks, since it reduced their downtime, the board is not convinced. It can be reasonably assumed that a client computer in many fields should only be out of service as briefly as possible during a software update. This is not specific to an electric power distribution network.
2.8 The appellant further stated (during oral proceedings) that all steps as claimed, taken in combination, are particularly useful for P&C client networks.
2.9 The board recognises that every single step (e.g. compatibility check, "correctly stored" check; back-up copy; recover after timeout) is useful for updating the client computers of a P&C network. However it does not see that any of them has a particular advantage for P&C networks, or is particularly adapted to them.
2.10 Furthermore, the board notes that the execution of these steps in combination does not produce a synergistic effect that goes beyond the sum of the effects of the individual steps. Each step addresses a separate problem that is addressed separately.
2.11 Therefore, the board agrees with the decision (3.) that the invention does not have any particular relationship with electric power distribution networks, but instead constitutes a general software update method. Furthermore, the board finds that the claimed invention does not guarantee a shorter downtime than that which could be expected from any other updating method with the same security checks.
2.12 As to the argument in the grounds of appeal (end of page 5) that the invention used a particular communication model with interchanged functions of client and server, the board cannot see that this is the case. The board is of the opinion that the initiative to start a download does not imply which computer is the server and which one the client. It is clear that "computer station 11" functions here as a server for the service of providing the software file to the "P&C device", which is consequently to be seen as a client for this service.
2.13 The argument that a wireless transmission required a different communication model is not convincing either (middle of page 6). The wireless transmission is merely a different lower-level transmission technique which is completely transparent at the file transfer level used for the updating. Thus, a change in the transmission technique does not affect the updating method.
2.14 The use of one thread per client (page 10, sentence 10) is also considered to constitute a merely routine implementation decision, with its known advantages and disadvantages, to realise "parallel" downloads to multiple clients. The same holds for one "session" per client.
2.15 The fact that such a method is used in the field of P&C networks (which may not have had such upgrade methods before) does not make the method inventive, already because no specific adaptation of the method to this field is claimed. As an aside, the board notes that any such adaptation would, of course, still have to be assessed in itself for obviousness.
2.16 Therefore, the subject-matter of the independent method claims of both requests is not inventive within the meaning of Article 56 EPC.
Order
For these reasons it is decided that:
The appeal is dismissed.