T 1542/06 ("Main request - novelty (no)""Auxiliary request - … of 18.12.2008

Summary of Facts and Submissions

I. This appeal is against the decision of the examining division refusing European patent application No. 02018087.3, with publication number EP-A-1284446, on the ground that the subject-matter of claim 1 of both a main and an auxiliary request did not meet the requirement of novelty having regard to the disclosure of the following document:

D1: Himstedt et al: "OPC - künftig Standard für Visualisierungs- und Feldbussysteme", ETZ vol. 118, no. 13/14, 1 July 1997, pages 6-8.

II. In the notice of appeal, the appellant requested that the decision be set aside and a patent granted. Together with a statement of grounds, the appellant filed sets of claims of new main and auxiliary requests.

The appellant conditionally requested oral proceedings.

III. In a communication accompanying a summons to oral proceedings, the board gave a preliminary opinion that, inter alia, the independent claims of the main request did not meet the requirement of novelty with respect to the following document referred to in the European search report:

D4: EP-A-0825506

D4 was not mentioned during substantive examination and was cited by the board by virtue of its power under Article 114(1) EPC.

The board further expressed its preliminary opinion that the independent claims of the auxiliary request did not fulfil the requirements of either Articles 84 or 123(2) EPC.

IV. No written reply was received to the board's communication.

V. Oral proceedings were held on 18 December 2008.

The appellant requested that the decision under appeal be set aside and a patent granted on the basis of either claims 1-27 (main request) or claims 1-26 (auxiliary request) filed during the oral proceedings.

After deliberation, the board's decision was announced at the end of the oral proceedings.

VI. Claim 1 of the appellant's main request reads as follows:

"A system (10, 50) for interacting with an industrial controller (18, 74, 96), the system comprising:

an automation interface component (14, 54, 94) adapted to communicate with at least one industrial controller (18, 74, 96), and

a computer process interface library (56) integrated into the automation interface component (14, 54, 94) and adapted to expose the automation interface component (14, 54, 94) to a client application process (16, 58, 84),

wherein the computer process interface library (56) comprises object-oriented programming based objects and classes,

characterized in that

said computer process interface library (56) is adapted such that the client application process (16, 58, 84) locally effectuates on the at least one industrial controller (18, 74, 96) at least one or more of creating, programming, editing, monitoring or maintaining one or more control programs associated with the at least one industrial controller

(18, 74, 96)."

VII. Claim 1 of the appellant's auxiliary request adds to claim 1 of the main request the feature that:

"the automation interface component (14, 54, 94) comprises functionality for inserting a rung (38) into a ladder logic instruction program, downloading the ladder logic instruction program to the industrial controller (18, 74, 96) and executing the program programmatically".

Reasons for the Decision

1. Introduction of new prior art by the board (Article 114(1) EPC)

1.1 The board has relied in this decision on document D4, which as noted above in the Summary of Facts and Submissions, section III, was referred to in the European search report, but cited for the first time in these appeal proceedings.

1.2 In accordance with Article 114(1) EPC, in proceedings before it, the European Patent Office shall examine the facts of its own motion; it shall not be restricted in this examination to the facts, evidence and arguments provided by the parties and the relief sought (reference is made to decision G 10/93 of the Enlarged Board of Appeal, OJ EPO 1995, 172). In the present case the board, making use of its power under Article 114(1), included D4 into the proceedings, considering it to be more relevant than D1 relied on by the examining division.

2. Claim 1 (main request) - novelty

2.1 The present application concerns a system for interacting with industrial controllers by means of a client application. The client application is able to communicate with one or more industrial controllers via an automation interface. The automation interface uses object-oriented programming techniques to enable the client application to carry out programming operations on the industrial controllers.

2.2 In the board's view, the system as claimed in claim 1 of the main request is fully disclosed by document D4.

2.3 In this respect, D4 discloses a system for "remote" process control using a client-server arrangement, although it is clear from the description that the client may either be sited "locally" in the enterprise of the user and connected to the server via an intranet or LAN, or may be connected remotely via the internet (cf. col. 4, lines 16-29).

The client-server system of D4 is adapted to monitor and control process control apparatus, eg control/sensing devices 19a-19e such as valves and thermostats. These are controlled by respective control stations 23a-23e. The control stations 23a-23e include objects which control and reflect the status of the respective attached process control apparatus using object-oriented programming. In the board's view, the controller stations 23a-23e, which comprise inter alia process objects (cf. col. 6, lines 17-18), are "industrial controllers" within the meaning of the present application.

2.4 Using the language of claim 1, D4 discloses a system for interacting with an industrial controller, the system comprising (cf. Fig. 1):

- an automation interface component ("server digital data processor" 16, including "information server" 20, "command processor front end" 25a, "interface" 25b and "object manager" 25c, together with the distributed parts of the object manager located at the control stations 23a-23e) adapted to communicate with at least one industrial controller ("control stations 23a-23e");

- a computer process interface library ("object manager 25c") integrated into the automation interface component (col. 5, lines 53-56: "Each object manager maintains the data structures -- to wit, objects -- that control and reflect the status of its associated process control apparatus") and adapted to expose the automation interface component to a client application process (cf. col. 4, line 55 - col. 5, line 6: "The information server 20 establishes communications with the client digital data processors 12, 14 and, particularly, their respective information clients in the conventional manner known in the art. Once communications are established, the information server transfers to the information client an applet that executes within the virtual machine environment and that monitors and/or controls the process control apparatus via communications with a command processor in the server digital data processor 16");

- the computer process interface library comprising object-oriented programming based objects and classes (cf. col. 6, lines 8-10: "Using the object manager 25c (via front end 25a), applets 26, 28 may create, read, write, and destroy instances of objects, which are subtyped into four categories ...." - the board considers that categories of objects are the same as classes); and

said computer process interface library being adapted such that the client application process locally effectuates on the at least one industrial controller at least one or more of creating, programming, editing monitoring or maintaining one or more control programs associated with the at least one industrial controller.

In this respect, referring again to D4, col. 6, lines 8-10, the tasks carried out by the applets (which reside on the client computer, cf. Fig. 1) of creating, reading, writing and destroying objects are examples of "creating" and "programming" the objects. Since, as noted above, the objects control and reflect the status of their associated process control apparatus (col. 5, lines 54-56), it follows that control programs associated with the industrial controllers can be programmed by the client. Finally the client processor may be sited locally and communicate with the controllers via an intranet or local area network (cf. col. 4, lines 16-29), and hence the client process is adapted to effectuate creating and programming of the control stations "locally".

2.5 Hence the board concludes that D4 discloses all the features of claim 1; the subject-matter of claim 1 of the main request is therefore not new (Articles 52(1) and 54 EPC).

2.6 The appellant argued at the oral proceedings mainly that the subject-matter of claim 1 was new because the objects described in D4 did not represent a control program of an industrial controller but merely status values of the process control apparatus.

However, the board does not agree. Apart from the clear indication mentioned above that the objects control as well as reflect the status of their associated control apparatus, the routine for obtaining status values described in D4, column 9, lines 32-34 is also a control program associated with an industrial controller within the meaning of the present application. This view is corroborated by the description of the present application (cf. col. 1, lines 11-17), in which it is stated in the section outlining the background of the invention that "Industrial controllers are special purpose computers used for controlling factory automation devices. Under the direction of a stored program, a processor of the industrial controller examines a series of inputs reflecting the status of a controlled process or device and changes outputs affecting control of the controlled process or device". Hence examining a series of inputs, which is what is being performed in the aforementioned section of D4, is to be understood as part of the stored program of the controller.

2.7 The appellant also argued at the oral proceedings that D4 did not disclose programming of the industrial controllers "locally". Although the board considers that this term in the context of claim 1 could be construed in different ways, the description in fact makes clear that the term "locally" relates here to the location of the client processor in relation to the industrial controller (cf. col. 2, lines 44-47: "The automation interface provides for programming, editing, monitoring and maintenance of industrial controllers programmatically from a local or remote location"; col. 6, lines 43-46: "if the automation interface 14 includes compiled COM libraries, the client application can access the automation interface through a local procedure call (LPC) or a remote procedure call (RPC)"). "Locally" in this sense is fully disclosed in D4, which, as stated above, suggests both remote access via the internet or local access via an intranet or LAN.

2.8 In the statement of grounds the appellant submitted arguments in respect of D1. The board has considered whether these arguments could be applied to D4.

The appellant argued as follows:

"D1 discloses a system wherein several clients communicate with an OPC server to obtain field data from industrial controllers. The clients communicate client data to the OPC server, which converts the client data into a format comprehensible by the industrial controllers, such as ladder logic. The clients are thus limited to gaining access to the functionality of the OPC server, which then in turn communicates with the industrial controllers. Therefore, a client does not gain access to the functionality of the industrial controllers".

2.9 Applying this argument by analogy to D4, the board does not find it convincing. In D4, by communicating with the server digital data processor 16, the client is able to communicate with the controlled devices to control the devices. The board therefore considers that the client does gain access to the functionality of the industrial controllers. Moreover, this appears to be no different to the approach taken in the present application; the "automation interface" is configured as a server which translates requests from the client into control messages for the industrial controller (cf. paragraph 0026).

2.10 The appellant further argued in the statement of grounds that according to the invention the programs of the industrial controllers can be edited directly without the intermediary of an OPC server acting as a protocol conversion node.

However, the board considers that this feature is not included in claim 1. In any case, in the system described in the pending application, access to the industrial controllers is also via the intermediary of a server (the automation interface), whereby communication from the client to the automation interface in general uses a different network protocol to that between automation interface and controller (cf. col. 8, lines 8-15). The board is therefore not convinced by this argument either.

2.11 In view of the above, the board concludes that the appellant's main request is not allowable.

3. Claim 1 (auxiliary request) - inventive step

3.1 Claim 1 of the auxiliary request differs from claim 1 of the main request in that the automation interface component further comprises functionality for inserting a rung into a ladder logic instruction program, downloading the ladder logic instruction program to the industrial controller and executing the program programmatically.

3.2 In respect of the first part of this feature, the appellant has acknowledged that it was commonplace in the art at the priority date of the application for industrial controllers to be provided with a ladder logic instruction program. The board also notes that the description of the present application in column 1, lines 41-42 states that a conventional language for programming the stored program is relay ladder logic.

3.3 Therefore in the board's view the person skilled in the art, starting out from D4 and making use of common general knowledge, would find it obvious to provide the industrial controllers with a ladder logic instruction program. This point does not seem to be disputed by the appellant.

3.4 Nevertheless, the appellant argued in the oral proceedings that it would not be obvious, using the system of D4, to modify the rungs of such a program, since the object-oriented programming system of D4 merely enabled status values to be read but did not enable program instructions of the industrial controller to be changed.

3.5 The board however judges that such a step is obvious. As has already been argued, D4 explicitly provides for objects to be created for controlling the controlled process as well as objects for monitoring the status of the process. Hence program instructions can be created or changed. Moreover, the object-oriented based system of D4 is a highly flexible system which has no inherent technical limitation to simply reading out status values or performing simple control tasks. Consequently, the board regards it as obvious that the skilled person would seek to exploit the full potential of the system of D4 by providing functionality for creating and modifying more complex control programs than those explicitly disclosed in D4, such as those requiring ladder logic programming, which as observed above, is a standard method of programming used in the field of industrial controllers. The board regards it as self-evident that this includes the inserting of rungs into such programs.

3.6 Claim 1 of the auxiliary request further requires that the ladder logic instruction program be downloaded to the industrial controller from the automation interface and executed "programmatically".

In this respect, the board observes that in D4 the automation interface component is distributed between the central server 16 and the control stations 23a-23e. The control stations not only perform the function of the industrial controller of the present application, but also comprise the distributed part of the automation interface which stores the objects which control the process control apparatus. It is therefore not necessary to "download" the program objects from the automation interface to the industrial controller, insofar as "download" might imply a physical separation of these components. However, the fact that the D4 system distributes part of the object manager functionality among the control stations rather than carrying out this functionality entirely in the central server 16 is in the board's view a matter of routine design choice which does not contribute to inventive step; the appellant has also not argued otherwise.

With regard to the executing of the program "programmatically", the board regards it as self-evident that a new or modified program should be executed. That this should be done "programmatically" is inherent in the nature of a program.

3.7 In view of the above, the board concludes that the subject-matter of claim 1 according to the auxiliary request does not involve an inventive step having regard to the disclosure of D4 and common general knowledge (Articles 52(1) and 56 EPC).

In consequence, the appellant's auxiliary request is not allowable either.

ORDER

For these reasons it is decided that:

The appeal is dismissed.