T 1446/06 (Distributed program execution/CITRIX SYSTEMS) of 6.5.2010

Summary of Facts and Submissions

I. This appeal is against the decision of the examining division to refuse the European patent application No. 02768936.3 on the grounds that the method for enabling distributed program execution of claim 1 of the main and first and second auxiliary requests did not involve an inventive step (Article 56 EPC 1973) over US-A-5 838 906 (D1) and the skilled person's common general knowledge. The additional feature of receiving a rule to determine where to execute the program in claim 1 of the third auxiliary request was found to be obvious from the load balancing aspect of the Tarantella system disclosed in D2 (ANONYMOUS: "Tarantella Web-enabling Software, One World, One Network, One Answer, An SCO Technical White Paper", Santa Cruz Operation, Inc., December 1999, pages 1-25, retrieved from Internet: http://web.archive.org/web/19990915181007/www.tarantella.sco.com/ info/wps/wp1.pdf).

II. In the statement setting out the grounds of appeal, the appellant requested that the decision under appeal be set aside and that a patent be granted on the basis of the refused main, or first to third auxiliary requests. The appellant also requested the refund of the appeal fee and made an auxiliary request for oral proceedings. In particular, the appellant argued that D1 did not disclose the claimed mapping specifying an association between data file type and executable application program and filed a witness statement by a person skilled in the art of computer networks to support this.

III. In the communication accompanying the summons to oral proceedings, the Board summarised the issues to be discussed and tended to agree with the examining division that the subject-matter of claim 1 of all requests lacked an inventive step. In particular, the Board tended to consider that document D2 was a better starting point for inventive step. With respect to the refund of the appeal fee, the Board could not acknowledge a procedural violation.

IV. At the end of the oral proceedings, the Chairman announced the decision.

V. Claim 1 of the main request reads as follows:

"In a network including a client system (10, 20) and a plurality of server systems (30, 32, 34, 36), a method for enabling distributed program execution, the method comprising the steps of:

(a) receiving at a client system (10, 20), from one of a plurality of server systems (30, 32, 34, 36), a mapping specifying an association between each of a plurality of types of data file and a corresponding one of a plurality of executable application programs, whereby each type of data file is associated with an executable application program that accepts that type of data file for processing;

(b) presenting, by the client system (10, 20), a graphical depiction (57, 57') of a data file stored on a client system (10, 20);

(c) receiving, by the client system (10, 20), a selection of the graphical depiction (57, 57') of the data file;

(d) identifying by the client system (10, 20), (i) a program for establishing a connection with a server system and (ii) one of the plurality of executable application programs associated with the type of file identified by the selected graphical depiction (57, 57') using the received mapping; and

(e) sending, by the program for establishing a connection with a server system, to one of the plurality server systems (30, 32, 34, 36) a request to execute the identified one of the plurality of executable application program [sic]."

Claim 1 of the first auxiliary request specifies in feature (a) that the application programs are "residing on the server systems" and at the end of the feature "storing the received mapping in a data structure on the client system so as to update a previously existing mapping in the data structure".

Claim 1 of the second auxiliary request specifies that the data structure added in the first auxiliary request is "a registry file of an operating system".

Claim 1 of the third auxiliary request adds to the end of claim 1 of the first auxiliary request the step of "receiving a rule determining whether an identified executable application program is to be executed on the client system or one of the plurality of server systems".

VI. The appellant argued essentially as follows:

Networks with fat clients running applications and file type association (FTA) were common general knowledge. Also thin clients where keystrokes were sent to the applications on the server were known. In the latter, the server may be running FTA. The invention was to have FTA on the client, but capable of identifying applications running on the server. It would not have been obvious to want applications running on both the client and the server. Even if this were to have been considered, it would not have been an obvious extrapolation to extend the FTA on the client to run applications on the server; the skilled person would have provided two separate FTA systems. It would have been more difficult to extend the FTA than to have provided separate FTA systems and that would have steered the skilled person away from doing it.

The Tarantella system of D2 was a server based system with central control by the server. The FTA would have been on the server because the server needed to know everything about the system. Tarantella simply displayed on the client the files available on the server.

The system of D1 received web pages containing an "EMBED" tag that identified the address (URL) of an object and either an application to be used to handle the object, or the type of data of the object. There were thus two types of mapping; a fixed mapping between a data file and an application, in which case there was no need to do more, or a mapping between a data file and its type, but not to an application.

Claim 1 of the first auxiliary request was also distinguished from Dl by the additional feature of "storing the received mapping in a data structure on the client system so as to update a previously existing mapping in the data structure". Dl did not disclose storing any mapping. In particular, there was no reason to store any mapping on the client system disclosed in Dl because the HTML tag specified what application to launch.

Claim 1 of the second auxiliary request was also distinguished from Dl by the feature of updating the registry file. There was no disclosure or suggestion in Dl of updating a registry file.

Claim 1 of the third auxiliary request was also distinguished by the feature of "receiving a rule determining whether an identified executable program is to be executed or the client system or one of the plurality of server systems".

In the Tarantella system of D2, it was not the client system that made the decision which servers to use, it was the host server. This could clearly be seen from the disclosure in 5.1 which stated that Tarantella resided on a host on the network. Therefore, it was not present on the client system. Accordingly, a man skilled in the art reading Tarantella may have modified the apparatus of Dl to provide a black box on one of the hosts that carried out load balancing routines, however there was no disclosure that would lead one skilled in the art to modify the apparatus of Dl so that the client system received a rule determining whether an identified executable application program was to be executed on the client system or one of the plurality of server systems.

The examining division's procedure with regard to this case constituted a substantial procedural violation under Rule 67 EPC 1973. Under Article 96(2) and Rule 51(3) EPC 1973, any communication notifying the applicant that the application did not meet the requirements for grant of a patent should contain a reasoned statement covering all the grounds against the grant of a patent. The "grounds" were the essential reasoning, both legally and factually, which led to refusal of the application. If the applicant was not given enough time to provide a reply to such grounds then there was a substantial procedure violation of Article 113(1) EPC.

During examination of this application, the applicant was informed in communications issued under Article 96(2) EPC 1973 that the invention defined in the claims lacked novelty and/or an inventive step over Dl. In these communications, the examiner pointed to columns 9, lines 24 to 26 and column 12, line 54 to column 13, line 31 explaining that this disclosure anticipated the feature of receiving the mapping as defined in claim 1.

Initially, the applicant responded in writing pointing out to the examiner that these sections of Dl did not disclose the feature of receiving such a mapping. On being summoned to oral proceedings, the representative telephoned the examiner, as neither the representative nor the applicant understood how the examiner could maintain his objection when, clearly, there was no explicit disclosure of this feature in Dl. During the telephone call, the examiner simply reiterated the reasoning given in the written communications and at no point embellished or provided further reasoning for his objections. It was only on attending oral proceedings that the applicant was told that the examining division believed the feature of the mapping to be implicitly taught in Dl based on column 15, line 9-48. This reasoning was completely different to that given in the written communications and in the telephone conversation. Clearly, the examining division had plenty of opportunity to present these arguments to the applicant before the oral proceedings and was even prompted to do so by the applicant, but failed to take these opportunities. The applicant therefore felt "ambushed" by the examining division, not having had sufficient time to consider these arguments and formulate a considered and substantive response.

Providing the grounds for refusal of the application for the first time during oral proceedings constituted a substantial procedural violation under Article 113(1) EPC that warranted a refund of the appeal fee.

Reasons for the Decision

1. The appeal complies with the requirements referred to in Rule 65(1) EPC 1973 and is therefore admissible.

The application

2. The application concerns the problem of automatically starting an appropriate program on a server computer by selecting an icon representing a data file on a client computer.

3. In a conventional Windows environment, a data file can be worked on either by clicking on the icon of the application program to be used (e.g. Microsoft Word) and then opening the required data file, or by directly clicking on the data file. In the latter case, Windows matches the type of the data file with the associated program (e.g. a ".doc" file with Microsoft Word - see published application, page 33, Table 3) and starts the program (paragraph 42). This is the so-called file type association (FTA).

4. The idea of the invention (see Figure 1 and paragraph 7) is essentially to extend this function to launch application programs located on a server computer 38 over a network 40. This is achieved by sending a "mapping" between the types of data file and their associated programs from the server to the client (claim 1, feature (a)), so that the client knows which program to launch when the file icon is clicked on (features (b) to (e)).

5. The application was refused because of lack of inventive step starting from D1. The examining division considered that D1 disclosed features (b) to (e) as well as the mapping of feature (a), but not that the mapping was received at the client. The problem was seen as how to remotely update the configuration of a computer, the claimed solution being found obvious. The appellant does not consider that D1 discloses the mapping between types of data file and application programs.

6. The Board has difficulties in seeing how the overall functionality provided by D1, namely the ability to locate, retrieve and interact with programs on servers (see D1, paragraph bridging columns 6 and 7 and column 12, line 50 ff.) depending e.g. on the "data format" of an object received at a client (column 13, lines 23 to 25), can be achieved without some sort of "mapping" falling under the definition given in claim 1. However, the context of D1 is somewhat different in that the programs are launched via links in a hypermedia document sent by the server and displayed on the client.

7. The Board considers that D2 is a better starting point for the discussion of inventive step. D2 was an "X" document for claim 1 in the ISR, and the examining division used it in the decision, albeit in connection with the third auxiliary request to show that "load balancing" was known.

8. In the background (Section 3), D2 sets out the problems with conventional networks, namely that the clients were becoming too bloated with software ("fat" clients), resulting in the need to manage applications centrally on a server and making them accessible over the network (via "thin", or at least "thinner" clients). The Tarantella system is said to enable users to manage "fat" clients without starting from scratch. This is achieved by moving all states associated with users and applications to a central server (page 8, top). The user has a "webtop" (section 5.1.9, first paragraph), which is a web page that shows all his objects, including applications and documents, as icons. The user can "invoke applications and view documents" by clicking on these icons.

9. D2 does not discuss what happens to the client's data files when Tarantella is added to an existing system, but in the Board's view it does not exclude the possibility that they remain on the client. The appellant appears also to accept this possibility by suggesting that any FTA on the server would run side by side with conventional FTA on the client. The invention thus differs by allowing icons representing documents on the client to be clicked on to launch applications on the server as well by the associated mapping received from the server.

10. In the Board's view, considering the above-mentioned objects of Tarantella, namely the desire to integrate with "fat" clients without starting from scratch, showing all the user's applications and documents as icons and viewing documents by clicking on them, it would be an obvious wish to be able to launch programs by clicking on document icons without regard to whether they are on the server or the client. It would thus be obvious to pose the problem of launching the centralised application programs via an extended form of the existing FTA. Thus the situation is not as simple as choosing either "fat" or "thin" or separate client/server arrangements as suggested by the appellant; the skilled person would appreciate that there is a continuum of solutions, in particular when integrating new systems with existing ones as in D2. The only remaining question is whether the claimed solution to this problem is obvious.

11. Looking for a solution to this problem, it would be self-evident that a "mapping" is required as claimed in feature (a). This is also how the conventional FTA works. The mapping must include all programs that the user might need to launch. Furthermore, in the Board's view, receiving such a mapping from the server is an obvious possibility especially since only the server side would be aware when relevant applications have been installed.

12. Accordingly claim 1 of the main request does not involve an inventive step (Article 56 EPC 1973).

13. In the Board's view, storing the received mapping in a data structure, according to claim 1 of the first auxiliary request, is a self-evident requirement and a matter of normal design procedure. Using the registry for this, according to the second auxiliary request, would be an obvious possibility. Moreover, this is also precisely how the conventional FTA is implemented.

14. Claim 1 of the third auxiliary request specifies that the client determines where a program is to be executed dependent on a "rule". If the client and server both had the same application program, which is not excluded in D2 and is a situation likely to arise in normal use, some decision would have to be made about which version to run. A "rule" would thus be required. In the Board's view, specifying that the client determines where a program is to be executed, would be an obvious choice (from two possibilities) depending on the circumstances, such as where the information required to make the choice is available.

15. Accordingly, the subject-matter of claim 1 of all requests does not involve an inventive step (Article 56 EPC 1973), so that it follows that the appeal must be dismissed.

16. Since the appellant's appeal is not allowable, the request for reimbursement of the appeal fee must also be rejected (Rule 67 EPC 1973) and the issue of the alleged procedural violation need not be considered. Nevertheless, the Board cannot see how providing new arguments at the oral proceedings, even if they differ from ones previously used, could be seen as a procedural violation. The applicant had the chance to discuss fully these arguments at the oral proceedings and could have asked for more time to study any parts of D1 not previously referred to. Thus the decision is not based on any grounds or evidence on which the parties concerned did not have had an opportunity to present their comments that would have been contrary to Article 113(1) EPC. Moreover, if no new arguments are to be given at the oral proceedings, the Board wonders what the purpose of oral proceedings is.

ORDER

For these reasons it is decided that:

The appeal is dismissed.