T 1065/14 (Engineering tool/SIEMENS) 23-11-2016
Download and more information:
METHOD FOR PROVIDING ENGINEERING TOOL SERVICES
I. The appeal lies against the decision of the examining division, with reasons dated 2 December 2013, to refuse European patent application No. 02 768 521.3 for lack of inventive step over
D1: WO 01/69335.
In a section entitled "Further remarks", the examining division also argued that the claimed invention lacked inventive step over the prior art acknowledged in the application itself.
II. Notice of appeal was filed on 28 January 2014, the appeal fee being paid on the same day. A statement of grounds of appeal was filed on 14 April 2014. The appellant requested that the decision be set aside and that a patent be granted on the basis of amended claims filed with the grounds of appeal, the other pending application documents being as follows:
description pages
2-4, 6-26 as published,
1, 1a, 5 as filed with letter of 12 September 2008,
and drawings, sheets
1/27-27/27 as originally filed.
III. In the annex to a summons to oral proceedings, the board informed the appellant of its preliminary opinion that the claimed invention lacked inventive step over D1 or, alternatively, over the prior art acknowledged in the application itself, Article 56 EPC 1973. A clarity objection, Article 84 EPC 1973, and a terminological issue were also raised.
IV. In response to the summons, with letter dated 4 October 2016, the appellant filed amended claims 1-6 according to a main and an auxiliary request.
Claim 1 of the main request reads as follows:
"A method for providing a customer (55), having a client device (30), with use of an engineering tool for programming a programmable logic controller (40), the method comprising the steps of:
providing the client device (30) of the customer (55) with access to a server (50) residing on a network (35), the server (50) not comprised by the programmable logic controller (40);
maintaining on the server a web-enabled engineering tool capable of being accessed by a browser application running on the client device (30);
providing the customer with use of the web-enabled engineering tool the web-enabled engineering tool adapted to receive, from the customer (55), programming code;
compiling the programming code on the server (50), the compiled programming code adapted for use by the programmable logic controller (40);
testing the compiled programming code by running simulation software on the server or running the programming code on a test programmable logic controller interfaced with the server;
downloading the compiled code to the programmable logic controller (40); and
receiving value from the customer (55) in exchange for use of the engineering tool."
Claim 1 of the auxiliary request is identical to claim 1 of the main request, except that the three occurrences of "programmable logic controller (40)" have been replaced with "target programmable logic controller (40)".
V. The oral proceedings took place as scheduled on 23 November 2016. At their end, the chairman announced the board's decision.
The invention
1. The application relates to the programming of a programmable logic controller PLC (see the application as originally filed, page 1, paragraph 2). Typical PLC programming languages are listed, including ladder logic ("LAD") and other IEC 1131 languages (page 2, lines 1-4, and page 10, last paragraph).
1.1 In the prior art it was common to develop PLC programs on the user's personal computer (PC) which would run suitable "engineering" software such as "Siemens STEP 7" (see page 3, paragraphs 3 and 4; figure 1).
1.2 This is said to be disadvantageous because it requires software vendors to support many operating systems (page 4, paragraph 1), because it has high maintenance costs (page 4, paragraph 2), and because it complicates licensing (page 3, last paragraph, and page 4, paragraph 3; page 23, paragraph 3, to page 24, paragraph 1).
1.3 To overcome these deficiencies, the invention proposes that the engineering tool execute at a server and be accessible from a client device through a web interface (see e.g. page 12, paragraph 2; page 13, last paragraph; figure 3). In particular it is proposed that editing, debugging, compiling and testing take place at the server (page 13, last paragraph, to page 14, paragraph 1; page 24, last paragraph, to page 25, paragraph 1). Rather than by simulation at the server, testing may also be at a "test" or "testing PLC" under server control (loc. cit.). The compiled code may be downloaded to the (target) PLC via the client computer or directly (page 14, paragraph 2, to page 15, paragraph 1).
1.4 In addition to avoiding the mentioned shortcomings of the prior art, the invention is said to simplify not only collaborative software development and version management, but also billing (page 17, last paragraph to page 18, paragraph 1; page 20, last paragraph to page 21, paragraph 1; page 21, paragraph 3; page 23, paragraph 3).
Clarity, Article 84 EPC 1973, and a terminological issue
2. The board's clarity objection concerned the previously claimed feature that the engineering tool was provided with "programming code adapted to be compiled on the server" and the question whether the programming code was limited by having to be "adapted to be compiled by the server". This feature has been deleted in the present requests, so the objection has become moot.
3. Claim 1 of both requests refers to a "test" PLC "interfaced with the server" on which the compiled programming code might be run before being downloaded to the target PLC. In claim 1 of the auxiliary request, the latter is expressly referred to as the "target" PLC.
3.1 The appellant argued that it was clear from the wording of the claims that the test PLC and the target PLC were different from each other, inter alia because otherwise no downloading to the target PLC would be necessary after (successful) testing (see letter of 4 October 2016, sentence bridging pages 1 and 2).
3.2 The board considers that the claimed target PLC must also be "interfaced" with the server so that compiled code can be downloaded to it. In this regard, the test and target PLCs cannot be distinguished. Furthermore, in the board's view, the claim language does not exclude the reading that test and target PLCs may be the same devices and that the testing is carried out directly on the target PLC. As will be seen below, however, the board's inventive step assessment does not depend on this reading.
The prior art
4. D1 relates to remote monitoring and control of programmable logic controllers (PLCs) in industrial processes (see page 1, lines 19-20, page 2, lines 26-27, page 3, lines 12-15, page 6, lines 26-27, and page 7, lines 14-17). More specifically, a system is proposed with which users can, via the Internet and a commercial web browser, access information and data contained in a PLC and reprogram it (see page 3, lines 21-29; figure 1). The web server provided to that end can be coupled to a PLC (see page 6, lines 17-23, and figure 2). Access to the PLC is supported by means of a "program package" which resides and runs on the PLC and which provides inter alia a program editor (see page 7, lines 4-13, and figure 2). It is mentioned that PLC application programs may be stored as ladder logic or as an IEC 1131 language program.
Inventive step
5. The only difference between claim 1 of the main request and that of the auxiliary request is that the PLC (40) is marked as the "target" PLC to distinguish it from the "test" PLC. In the following, claim 1 of the auxiliary request will therefore be considered first.
6. The board agrees with the decision that D1 is a suitable starting point for the assessment of inventive step.
7. It is common ground between the board and the appellant (see grounds of appeal, page 2, paragraphs 1 and 4) that the subject-matter of claim 1 is distinguished from the system of D1 by the following features:
A) The engineering tool is run on the server (rather than on the target PLC) from which the program is eventually downloaded to the target PLC,
B) the customer provides payment ("value") per use of the engineering tool, and
C) the engineering tool offers compilation at the server and testing of the compiled code with simulation software at the server or by running the compiled code at a test PLC under the server's control.
7.1 Features A) and B) correspond substantially to the differences acknowledged by the examining division to exist between D1 and then claim 1. At the time, the appellant's argument that compilation at the server constituted a further difference was not accepted by the examining division, because compilation at the server was not implied by the claim language (see the minutes of oral proceedings before the examining division, page 1, paragraph 5; see also point 2 above). However, present claim 1 (both requests) as amended recites feature C) explicitly.
7.2 The board agrees with the examining division (see the decision, reasons 16.3) that billing the customer per use (feature B)) is a business choice which does not, by itself or in the context of the claimed invention, make any technical contribution to the art. The appellant did not challenge the decision under appeal in this regard.
7.3 With regard to features A) and C), the appellant stated the following:
(a) The fact that the programming package resided on the PLC (see esp. page 7, paragraph 2) was a fundamental feature of the disclosure of D1. Therefore, it would not have been a realistic option for the skilled person to give up this feature and any argument to this effect would be based on hindsight reasoning. This followed from decision T 2201/10 (headnote 1).
(b) The skilled person to be considered when assessing inventive step of the present invention was a computer scientist or electrical engineer engaged with the programming of programmable logic controllers, who would mainly deal with the correct implementation of controller functions in the engineering tool used for programming rather than with the computer environment in which the engineering tool is executed (see letter of 4 October 2016, page 2, paragraph 8).
(c) Before the invention was made, computer scientists had never questioned the use of engineering tools locally on a PC or directly on a PLC. Therefore, the claimed invention represented "a completely new paradigm for providing an engineering tool for programming a PLC to customers" (see the letter of 4 October 2016, page 2, paragraph 9). In this situation it required an inventive step for the skilled person to even realise that a paradigm change was advantageous. It was an indicator of inventive step that the old paradigm had not been questioned for so long. In situations like the present one, where the invention was based on the idea of changing the long-established practice in a given field, the problem-solution-approach tended to produce unfair results based on hindsight reasoning.
7.4 The board disagrees.
(a) It is acknowledged that the programming package in D1 resides on the PLC rather than on the server. Inter alia due to this difference, the subject-matter of claim 1 is new over D1. The main thrust of D1 is to provide a system allowing the "use [of] general, commercial networks such as the Internet in place of specialized industrial networks to remotely monitor and program automation control devices such as PLCs". In the board's judgement, the residence of the programming package on the PLC is not of fundamental importance to achieve this purpose and, hence, its modification would not change the essence of the system of D1.
(b) The board considers that the person skilled in programming PLCs, whether a computer scientist or electrical engineer by training, must have at least a working knowledge of client/server architectures and programming environments. Having said that, the board agrees that the distribution of tasks between PLC, client and server computers may not be an issue the PLC programmer should normally be concerned with. This however implies that the skilled person concerned with task distribution is not the PLC programmer but rather the developer of PLC programming environments and architectures, who certainly has the relevant expertise. The fact that the application relates to the field of industry automation does not affect this conclusion (see the grounds of appeal, page 2, paragraph 3).
(c) The board has no reason to doubt the appellant's assertion that practitioners in the field have never questioned the residence of the engineering tool on the PLC or a local PC. There is however no indication that this was due to the skilled person's lack of technical imagination. Practitioners may accept an existing and practicable solution even though they can imagine alternatives, and such alternatives may be straightforward for the skilled person to realise provided that a manufacturer is willing to invest in their development and customers are prepared to pay for them. The fact that a "paradigm" persisted for a period of time therefore does not suffice to establish that any change to it would be non-obvious.
The board also notes that the application itself talks about a "new paradigm in the engineering tool marketplace" (page 5, paragraph 3, first sentence), a "new business paradigm for selling engineering tool services" (page 8, lines 19-22) and a "new paradigm in the engineering tool industry" and how they were "manufactured and sold" (page 17, last paragraph). The paradigm shift thus seems to be of little concern to the persons of technical skill in the art. Whether an invention, however, represents a new marketing or business paradigm is immaterial for the assessment of inventive step within the meaning of Article 56 EPC 1973.
Finally, the board rejects the assertion that the use of the problem-solution-approach in the present case was based on hindsight reasoning, noting only that for the reasons set out below the skilled person is required to have nothing but basic knowledge and competences to arrive at the invention.
7.5 Returning now to feature A), the board takes the view that moving the "program package" of D1 from the PLC to the server has the effect, amongst others, of reducing the load on and the complexity of the PLC. The board considers that the person skilled in the art - namely, as just explained, the developer of PLC programming environments and architectures - would naturally be concerned with problems of this type. Moreover, the board considers that it is an obvious solution to these problems to move the "program package" of D1 to the server and only download the finished program code to the PLC. This is feature A).
7.6 As regards feature C), it is first noted that the provision of a compiler is a matter of necessity depending on the programming language in question. Incorporating this compiler into the programming package is an obvious choice so that, if the programming package was moved to the server for the above reasons, the compiler would be moved along with it and run on the server. Furthermore, the board considers it to be common practice to test a developed program by "simulation" or on the intended hardware. To provide simulation software as part of the programming package is, in the board's view, an obvious option, too. And if a modified program was successfully tested on a "test" device it would be an obvious option to "download" it to a further, "target" device.
7.7 In summary, the board concludes that claim 1 of the auxiliary request lacks inventive step over D1, Article 56 EPC 1973. A fortiori, this conclusion applies to claim 1 of the main request as well.
For these reasons it is decided that:
The appeal is dismissed.