T 1853/08 (Configuring client computers/RED HAT) of 9.11.2012

Summary of Facts and Submissions

I. The appeal is against the decision of the examining division, with written reasons dated 6 May 2008, to refuse the European patent application no. 05255532.3 for violation of Article 123 (2) EPC and for lack of an inventive step, Article 56 EPC 1973, over either of the documents

D1: US 6 151 674 A1 and

D6: Sun Microsystems, "Solaris 9 4/04 Installation Guide", pp. 1-20, 35-39, 109-162, 191-242, April 2004.

II. An appeal against this decision was filed on 27 June 2008 and the appeal fee was paid on the same day. A statement setting out the grounds of appeal was filed on 16 September 2008 along with four sets of claims according to the main and 1st to 3rd auxiliary requests.

III. With summons to oral proceedings the board informed the appellant of its preliminary opinion according to which the independent claims of all requests lacked clarity, Article 84 EPC 1973, and an inventive step over D1, Article 56 EPC 1973.

IV. In response to the summons, with letter dated 5 Septem ber 2012, the appellant filed new claims according to a fourth auxiliary request which were amen ded over those of the main request so as to overcome the board's cla ri ty objections. Except for one (the transfer as "read-only to the clients" objected against in the summons, points 7 to 7.2), the clarity objections themselves were not challenged by the appellant (cf. p. 1, 5th par. - p. 2, 2nd par.). The appellant further argued that "the claims" were "novel and inventive over all of the cited prior art" by virtue of features shared, accor ding to the appellant's interpretation, by all inde pendent claims of all requests (cf. p. 2, 2nd par. ff; and esp. p. 3, last par.). No arguments were provided with reference to the features distinguishing the claims of 1st-3rd auxiliary requests from those of the main request.

V. The appellant requests that the decision under appeal be set aside and that a patent be granted based on claims 1-20 according to the main or 4th auxiliary request or claims 1-12 according to the 1st-3rd auxilia ry requests, apparently in combination with the following applica tion docu ments:

Description, pages

1, 2, 4-6, 8, 10-19 as originally filed

3, 7, 9 received on 22 February 2007

Drawings, sheets

1-7 as originally filed.

VI. Claim 1 of the main request reads as follows

"A server computer (303) in a computer system, cha rac terised by:

one master operating system (OS) for each different operating system, said master comprising a reference set of computer program files and at least one configuration file to operate a client computer, transferable to a plurality of client computers, where the master operating system is read-only at the client computers thereby simplifying maintenance of both the plurality of client computers and the master operating system;

a version managing program maintaining said master operating system; and

a server program configured to transfer said master operating system as read-only files to at least one of the plurality of client computers."

Claim 1 of the 4th auxiliary request reads as follows

"A server computer (303) in a computer system, cha rac terised by:

one master operating system (OS) for each different operating system, each of said master operating systems comprising a reference set of computer program files and at least one configuration file to operate a client computer, transferable to a plurality of client computers;

a version managing program maintaining each of said master operating systems; and

a server program configured to transfer one of said master operating systems as read-only files to at least one of the plurality of client computers."

Claim 15 of the main and 4th auxiliary requests specify a "computer assisted method" or, respectively, a "computer-assisted method for operating a server computer" in terms corresponding to the respective claim 1.

Claim 1 according to the 1st auxiliary request reads as follows:

"A computer system, comprising:

a server computer (303); and

a plurality of client computers (305,307);

characterised in that:

the server computer (303) comprises one master operating system (OS) for each different operating system, said master comprising a reference set of computer program files and at least one configuration file to operate a client computer, transferable to a plurality of client computers, where the master operating system is read-only at the client computers thereby simplifying maintenance of both the plurality of client computers and the master operating system;

a version managing program maintaining said master operating system; and

a server program configured to transfer said master operating system as read-only files to at least one of the plurality of client computers;

wherein each client computer (305,307) is configured to operate using a designated one of the at least one master OS (403) as read-only files, wherein each client computer (305,307) comprises a memory including two logical partitions, a first partition including the designated one of the at least one master OS (403) and a second partition for storing a new version of the master OS, wherein the client computers (305,307) are configured to receive a new version of the master OS in the second partition from the server (303) and, when the new version of the master OS is completely cached, the client computers (305,307) are instructed by the server (303) to use the new version."

Claim 1 according to the 2nd auxiliary request is identical to claim 1 of the 1st auxiliary request up to the "version managing program" and then reads as follows:

"... a server program configured to write the master OS (403) on to a removable storage medium, for transfer to at least one of the plurality of client computers (305,307) as read-only files;

wherein each client computer (305,307) is configured to operate using a designated one of the at least one master OS (403) stored in a memory as read-only files, wherein each client computer (305,307) is configured to receive the removable storage medium from the server computer (309) and to send a message to the server (309) requesting a response as to which one of the stored master OS and the master OS stored on the removable storage medium should be used."

Claim 1 according to the 3rd auxiliary request is identical to claim 1 of the 1st auxiliary request up to the "server program" and continues to read as follows:

"... wherein each client computer (305,307) is configured to operate using a designated one of the at least one master OS (403) stored as read-only files, and each client computer (305,307) is configured to send a message to the server (309) when connected back to a network (301) after a disconnection; and

the server is arranged to determine whether the client computer (305,307) contains the correct version of the master operating system and, if the client computer (305,307) has an older version of the operating system, to use a master operating system stored on the server computer (309) over the network (301) whilst also transferring the master operating system from the server (309) to the client computer (305,307)."

Each of 1st-3rd auxiliary requests also contain an inde pendent method claim 7 which corresponds closely in wor ding to the respective independent claim 1.

VII. With letter dated 2 October 2012, the appellant indicated that it would not be attending the oral procee dings which the board consequently decided to cancel (see below point 1 of the reasons).

Reasons for the Decision

1. By indicating its intention not to attend oral pro cee dings, three days before the scheduled date, the appellant expressed, in the board's judgement, its wish to rely only on its written submissions and not to use the opportunity to make further oral comments. Following established jurisprudence of the Boards of Appeal (see the book on Case Law of the Boards of Appeal of the EPO, 6th ed., 2010, Chapter VI.C.2.2), the board thus takes the appellant's in di ca tion of its intention not to attend the oral procee dings as a withdrawal of its request for oral procee dings.

1.1 In the annex to the summons the board had argued that the main request lacked clarity for several reasons. Except for one of them, the "read-only at the client" feature, these clarity objections were not challenged in the appellant's response of 5 September 2012 (see p. 1, pen ult. par. - p. 2, 2nd par.).

1.2 Notwith standing the cla ri ty objection and based on its understanding of the intended inter pre ta tion of the claims, the board had given a preliminary nega tive opinion on inventive step and, in particular, ar gued that the "read-only" feature would not establish an inventive step (see summons, point 15 ff.). It was pre dictable for the appellant that this argument would apply to the newly filed 4th auxiliary request, too, which was filed only in order to overcome the clarity objections (appellant's response, p. 1, 3rd-4th pars.).

1.3 The appellant in response disputed the board's analysis as to inventive step by arguing that the terms "master OS" and "transferable to a plurality of client compu ters" had to be interpreted in a particular way (see response, p. 2, 5th par.) and would, thus interpreted, establish a difference over D1 (see also point 9.1 here inbelow). The board had already expressed its pre liminary opinion that the claim wording did not estab lish such a diffe rence (see summons, point 14.2) and the appellant's ar guments do not change this (see point 9.2 hereinbelow).

1.4 The appellant's arguments in its response as to inven tive step apply to all independent claims and all re quests alike. The appellant did not comment on the board's preliminary opinion as to the inventive merit of the additional features in the independent claims of the 1st-3rd auxiliary requests.

1.5 Consequently, the board is in a position to decide on the substance of the matter based on its preliminary opinion and the appellant's written case without vio la ting the appellant's right to be heard, Article 113 (1) EPC 1973.

1.6 The reasons of this decision are based, to a large part literally so, on the board's preliminary opinion as expressed in the summons.

The Invention

2. The application relates to a client-server network with so-called "thick clients" which can operate inde pen dent ly of the network (description, p. 1, lines 5-21, and p. 4, lines 2-5). The invention is con cerned with the maintenance of a thick client network in which the clients may use different operating systems or ope ra ting system in different versions or configu ra tions (p. 2, lines 2-8 and 15-16). The claimed invention re quires in particular that a server computer stores a "mas ter ope ra ting system (OS)" for each of se ve ral "diffe rent ope rating systems", a "ver sion mana ging pro gram" to main tain them, and a program which would trans fer a mas ter OS "as read-only" to the client computers.

Article 123 (2) EPC

3. The decision under appeal (points 15.1-15.3) found that three features of the claimed invention were not dis closed in the application as originally filed, namely

i) the reference to "operating system types",

ii) the requirement that the master OS be "read-only at the client computers", and

iii) the requirement that the claimed invention "[simp li fy] maintenance of both the plurality of client com puters and the master operating system".

3.1 The objection regarding feature i) has become moot due to the amend ments filed with the grounds of appeal.

3.2 The board agrees with the appellant that the "read-only" feature ii) is supported by the application as ori ginally filed, based on page 4, lines 9-11, and original page 7, lines 11-14) and that feature iii) is ori gi nally supported based on page 4, lines 2-3, and original page 7, lines 12-14.

3.3 The board is thus satisfied that the pending claims conform with Article 123 (2) EPC.

Clarity, Article 84 EPC 1973

Main and 4th auxiliary request

4. The independent claims of the main and 1st-3rd au xil i ary requests state that the master OS at the server is "read-only at the client com puters", and those of all re quests state that it is "transfer[red] ... as read-only" to the client computers".

4.1 In the board's view, as expressed in the annex to the summons, it is entirely under the control of the client computer whether the master OS, once transferred, will be read-only at the client com pu ter. Therefore, it is not a property of the mas ter OS stored at the server or of the transfer of the master OS to the client that the master OS is read-only at the client.

4.2 The appellant contradicts this opinion in its reply to the summons by arguing (cf. par. bridging pages 1 and 2) that

a) "modern operating systems provide ways of labelling files to indicate allowable operations", that

b) "[s]uch labels can be maintained through the trans fer from the server to the client system, thereby allowing the files to be transferred as 'read-only' by ensuring that read permissions are enabled while write and execute permissions are not set", and that

c) "[s]etting such permission values prior to transfer is clearly related to the operation of the server / server program during transfer of the master OS files, and not to the client device receiving the transferred files".

4.3 The board does not question the existence of file permissions per se as argued under a).

4.4 The board also does not doubt in principle that, as argued under b), file per missions can be maintained through the transfer but maintains the position that it depends inter alia on the ope ra ting system at the cli ent computer whether file per missions transferred along with a file are en forced or not and, hence, whether they actually are main tained through the transfer.

4.5 The board therefore disagrees with the argument under c) and considers that the "read-only" feature is, ulti mate ly, a feature of the client computer receiving the file so that, claim 1 of the main request lacks clarity, Article 84 EPC 1973, due to the fact that it is directed to a server computer only.

4.6 Since claim 1 of the 4th auxiliary request is, in this respect, identical to claim 1 of the main request, this finding obviously applies to the former as well.

4.7 In contrast, 1st-3rd auxiliary requests are clear in this respect because their respective claim 1 is direc ted to a system comprising a server computer and a plu ra lity of client computers.

4.8 Notwithstanding the lack of clarity of the main and the 4th auxiliary requests, in the following the board will give its reasoning on inventive step for all requests.

The Prior Art

5. D1 deals with so-called "network computers" (NC; see fig. 1, nos. 12A, 12B, 12C) which, in contrast to perso nal computers, download all ne cessa ry data and programs, including their operating system and suitable start parameters, from a server via the net work (col. 1, lines 13-24, and col. 4, lines 12-19). The appellant did not dispute that the network com puters accor ding to D1 constitute client computers as claimed. D1 dis closes that the server may store for each NC a diffe rent ver sion and type of operating system designa ted by the ser ver administrator (col. 2, lines 31-33, and col. 7, lines 17-26) and mentions that the OS may be upgraded at the server to a different version or type (see e.g. col. 7, lines 21-23, 30-35). When an NC is started for the first time, an ope ra ting system will be downloaded from the server (col. 6, lines 55-63). Thereafter, when ever the NC is started and if it is connected to the ser ver, it will check whether the lo cal ly stored opera ting system matches the OS de sig nated by the ser ver and, if not, will obtain the desig nated OS from the ser ver (cf. col. 2, lines 15-28, and col. 7, lines 2-6).

Inventive Step, Article 56 EPC 1973

Main Request

6. There is agreement between the decision under appeal, the appellant and the board that D1 is a suitable star ting point for the assessment of inventive step of the present invention.

7. In the decision under appeal (point 18.1), it was argued that D1 would disclose a ver sion management system by way of re ference to the old and new version avai lable for se lection by the admini s tra tor (cf. D1, col. 7, lines 17-26). In the summons to oral procee dings the board noted that this had apparently been conceded by the appellant, and furthermore expressed the opinion that D1 in the cited section at least suggested that the two version of an OS should be pre sent on the ser ver at the same time and that, hence, some form of ver sion management was imme di ately obvious. The appellant in its submission of 5 September 2012 did not challenge the board on this point.

8. According to the appellant (cf. grounds of appeal, p. 4, pars. 4, 5 and 7), claim 1 of the main request differs from D1 in particular in that D1 does not disclose

(1) any "mas ter operating system" which would be transferred to a client computer and that

(2) the operating system is stored at the client as read-only.

9. To establish (1), the appellant argues that according to conventional understanding a "master operating sys tem" would be one "from which copies are made" (grounds of appeal, p. 4, par. 4). D1 discloses that the clients down load an operating system from the server (loc. cit.). To the board this clearly implies that a - i.e. at least one - copy of the OS at the server is made and trans ferred to the client.

9.1 In the response dated 5 September 2012 (see p. 2, 5th par.) the appellant fur ther points out that all inde pen dent claims require the master OS to be "trans fe rable to a plurality of client computers" and submits that the "use of the term master implies a one to many rela tion ship between the one mas ter copy, and the many client computers to which it can be transferred". In contrast, so the argument, D1 would not disclose this concept of a master OS.

9.2 The board notes that term "transferable to a plu ra lity of client computers" only requires that the mas ter OS is suitable for being so transferred, not that it is actu ally transferred to several client computers. An opera ting system which is, according to D1, trans ferred from the server to one client computer is ob vi ously also "trans ferable" to several client com pu ters. Likewise, the board disagrees that the term "master" implies a strict one to many relationship with the client com pu ters but considers that it expresses primarily a hier archical relationship which can be satisfied by indi vi du al clients, too: In other words, while a master OS could - and may even be intended to - be copied to se veral client computers, the skilled person would use the term "master OS" also for the copy of an operating sys tem which the server maintains for just a single cli ent. The board therefore disagrees that the claimed features "transferable" and "master OS" estab li sh a diffe rence between claim 1 and D1.

9.3 The board concedes that D1 does not literally disclose that the same OS is transferred to several NCs. That said, however, the board considers that it is an obvious choice to use, by default and for simplicity, the same operating sys tem for several NCs in a network. Therefore even the appellant's interpretation of the terms "transferable" and "master OS" as implying a "one to many relationship would be obvious for the skilled person in view of D1.

10. Regarding (2) the board explained above (point 4 ff.) that claims 1 and 15 of the main request are not limi ted by the fact that the OS is stored read-only at the client, insofar as they relate only to the server com pu ter. The board thus considers that (2) does not con stitute a difference between D1 and claims 1 and 15.

10.1 Even if it did, however, it would not establish an inventive step over D1. Storing the master OS as "read-only" in the client eli mi nates the risk that the master OS is mo dified at the client and thus strengthens the control of the server over the client.

10.2 The mechanism according to D1 enables clients to run without connection to the network and the ser ver (see e.g. col. 1, lines 35-38) but maintains the primacy of the server in that the OS is maintained and designated at and downloaded from the server.

10.3 Thus the skilled person would understand from D1 that it is neither ne ce ssary nor normally intended that the files constitu ting the local OS copy are modified at the client.

10.4 Hence, in order to increase the control of the server over the client it would be obvious for the skilled person to disable changes to the OS files by storing them as read-only at the clients.

11. The appellant argues (see response of 5 September 2012, p. 2, last par.) that "it is only by combining the fea tu res of using a single master copy of each different OS to be transferred to a plurality of client com pu ters and transferring that copy to the OS files as read-only that allows the claimed invention to solve the problem of simplify[ing] maintenance of networked computers." The board disagrees and maintains that both features are also individually obvious over D1 (see esp. points 9.3 and 10.4 above) so that any interaction be tween both features is irre levant for the assessment of inventive step.

12. Finally, the board considers D1 not to disclose that

(3) the server stores a master OS "for each diffe rent operating system".

12.1 D1 discloses that the server stores an OS "for the network computer" (e.g. col. 7, lines 5-6) and de sig nates "a specific type and version of OS to be used in the net work computer" (col. 7, lines 19-21).

12.2 The board considers that different "types of OS" as used in D1 reads on the "different operating systems" as claimed. In the summons to oral proceedings (see point 16.1) this interpretation was put to the appellant who left it unchallenged.

12.3 In the board's view, D1 does not disclose in unambiguous terms that the server would store more than one type of OS at the same time. D1 also focuses on the protocol between the server and a single NC.

12.4 However if, as obviously intended in D1, the server is connected to several NCs, the notion of storing an OS "for" each of these NCs at least suggests that this may mean different "types" of OS for different NCs. As a consequence, the server would have to store "a master OS for each different operating system".

13. In summary, the board concludes that claims 1 and 15 of the main request, even if interpreted as suggested by the appellant, lack the required inventive step over D1, Articles 56 EPC 1973. Since claims 1 and 15 of the 4th auxiliary request are only clarified over these claims of the main request and since the inventive step assess ment of the latter was based on their intended meaning as, by way of clarification, made explicit in the former, the inven tive step assessment of the main request carries over the 4th auxiliary request. Claims 1 and 15 of the 4th auxiliary request thus also lack an inventive step over D1.

1st Auxiliary Request

14. The independent claims of the 1st auxiliary request spe cify in addition to those of the main request that a new version is downloaded to the client into a "partition" of the client's memory separate from that in which the current version is stored, and that only once the new version is completely cached the client is in structed by the server to use the new version.

14.1 It is known from D1 that, once in a while, the client's OS may have to be upgraded (loc. cit., see point 5 above) so that a new version of the OS may to be down loaded to the client.

14.2 In the board's view it is commonly known that downloads may be delayed or may fail, for instance due to net work problems. If this were to happen, a client down loa ding the new OS into the memory partition storing the current OS might be left in an inconsistent state and become inoperable. For the skilled person it would be an obvious coun ter measure against this happening to download the new OS into a separate memory partition and to switch to the new OS only after a successful download. The board further considers that anything indicating the success ful end of transmission of the new OS reads on the claimed instruction by the server that the client use the new OS version.

14.3 The board therefore concludes that the independent claims of the 1st auxiliary request also lack an in ven tive step over D1 in view of common knowledge, Article 56 EPC 1973.

2nd Auxiliary Request

15. The independent claims of the 2nd auxiliary request spe cify in addition to the main request that a new master OS is loaded from a "removable storage medium" and that the server is requested by the client to indicate whe ther to use the newly loaded or the previously sto red mas ter OS.

15.1 The board deems it to be a commonly known fact that the download of large files - such as operating systems - may take longer than desirable, in particular on a slow network. To address this problem the board consi ders it to be ob vi ous to load the master OS from a removable storage me dium such as a DVD.

15.2 It is known from D1 that the NC checks whether the local OS matches the OS stored at the server and, if it does not, the local OS is replaced by the OS from the server (col. 7, lines 11-15).

15.3 The board considers that the skilled person introducing the option into D1 to load an operating system from a removable storage medium would maintain this check to maintain consistency in the network.

15.4 As a consequence, the board concludes the in de pendent claims of the 2nd auxiliary request, too, to lack an inven tive step over D1, Article 56 EPC 1973.

3rd Auxiliary Request

16. The independent claims of the third auxiliary request spe cify in addition to those of the main request that each client computer, when "connected back to a network" sends a message to the server, checks whether it runs the most recent version of the master OS, and if not ini ti ates the transfer of the new master OS.

16.1 According to D1, the check whether the client runs the latest OS (see point 20.3 above) is per formed in parti cular whenever the NC is activated (col. 7, lines 2-6). In the board's view, it is ob vious to perform the same check whenever the NC is "connected back" so that cli ents may upgrade to the latest OS as soon as possible.

16.2 The board deems it to be implicit that the check involves a message sent from the client to the server, as re quired by the claims. Moreover, the board deems it to be ge nerally obvious that a client indi cates its reconnection to a network.

16.3 As a consequence, the board concludes the in de pendent claims of the 3rd auxiliary request to lack an in ven tive step over D1, Article 56 EPC 1973.

Summary

17. There not being an allowable request, the appeal has to be dismissed.

ORDER

For these reasons it is decided that:

The appeal is dismissed.