T 1623/10 (Software installation/MICROSOFT) 22-04-2015

Reasons for the Decision

1. The admissibility of the appeal

In view of the facts set out at points I to III above, the appeal fulfills the admissibility criteria under the EPC and is consequently admissible.

2. The context of the invention

2.1 The application relates to installing an operating system on the storage media of a target computer, such as that shown in figure 5 which comprises a hard disk drive (154) and magnetic (156) and optical (160) drives for removeable media. The application acknowledges that it is known in the prior art to install operating systems by discovering information about the target hardware, copying and decompressing source files, installing the resulting files and then configuring the installed files based on user input; see page 1, lines 11 to 20.

2.2 In order to reduce the installation time and possible user installation errors of this known approach, the application uses an image-based installation approach in which a hardware-independent run-time image is transferred, together with an executable install routine, from a source medium via a transfer medium to the media of the target computer, for instance its hard disk. By a "run-time image", the application means a ready-to-run operating system requiring little additional setup or installation.

2.3 The target computer is then rebooted into the applied run-time image (see page 7, lines 23 to 24), and the target computer runs the executable install routine to carry out a list of integration tasks to integrate the run-time image with the target computer. As examples of integration tasks, the application discloses hardware detection, making system settings, such as registry keys, installing device drivers, registering software, security identifier determination and encryption and pre-installing application programs; see page 4, lines 19 to 20, and page 7, lines 21 to 25.

2.4 The capabilities of different motherboards require support from different hardware abstraction layers (HALs) provided by the operating system. The operating system run-time image includes multiple HALs, enabling it to work with different motherboards with different power management needs and numbers of processors, the integration tasks also including configuring the HAL and (as set out in claim 1 according to the auxiliary request) identifying any mass storage device controllers on the target computer; see page 8, lines 8 to 14.

2.5 Claim 1 according to the auxiliary request also sets out the integration task of updating one or more system settings for the target computer with security identification data to identify the target computer. As an example of this, the description mentions "... generating machine-specific settings based on the security information of the target computer (e.g., encrypting keys) ..."; see page 5, line 30, to page 6, line 1. According to page 5, lines 23 to 25, "... data that is machine specific (e.g. registry key KeyFoo = machine_specific_security_ID+"applicationname") is recreated after the imaging process." According to page 11, lines 19 to 21, and figure 4, one or more keys are encrypted with the security identification data obtained via the determining data field (86) contained in the integration task list of the executable install routine. The board understands this example to mean that one installation task is to encrypt a registry key on the hard disk of the target computer using data stored in the task list of the executable install routine so that the target computer can be identified by means of the encrypted key.

3. Clarity, Article 84 EPC 1973

The amended claims are sufficiently clear for the purposes of assessing inventive step, Article 56 EPC 1973.

4. Document D1

4.1 D1 is regarded as the closest prior art in the reasons for the decision. The appellant has disputed this (see below).

4.2 D1 relates to a "custom-programmed" (abstract, line 2) CD ROM containing a software image supplied with a built-to-order computer which can be used to restore only that particular computer to its original, "factory new" state; see abstract, last five lines. The software image on the CD ROM is specifically configured ("built-to-order"; column 2, line 48) for that computer; see column 1, line 60, to column 2, line 13. The CD ROM is accompanied by a bootable flexible diskette containing a CD restoration program that controls the process of restoring the software image from the CD ROM to the computer; see column 3, lines 43 to 46. The computer system, diskette and CD ROM contain security keys so that the diskette and CD ROM must be used in combination to load the software image onto the particular computer; see column 6, lines 34 to 44.

4.3 The CD ROM is created by a CD ROM burner using a software image created by a mass storage controller from software in mass storage taking into account the hardware and software configuration of the computer; see figure 1, column 5, lines 40 to 48. According to column 6, lines 20 to 23, "The software image 102 formed on the custom-programmed CD ROM 106 precisely matches the configuration of the computer hardware to the detailed level of each device, bus, BIOS, device driver, and operating system".

4.4 The restoration method assumes that the computer system hardware is as originally ordered; see column 7, lines 54 to 56. To initiate restoration, the user inserts the diskette and CD ROM into the computer and reboots from the diskette; see column 3, lines 51 to 55. The CD restoration program checks to see if the service tag of the computer hardware matches the tag ID of the CD ROM; see figure 2, step 220 "Check ID tags", column 8, lines 26 to 32, and column 9, lines 1 to 6. The restoration program formats the computer hard drive to clear any information on it and downloads the software image from the CD ROM to the hard drive; see column 9, lines 18 to 22. The correctness of the download process is then verified. After the restoration program has terminated, the CD ROM and diskette are removed from the computer and the computer is rebooted, thus leaving the computer system restored to its "factory new" state; see column 9, lines 29 to 38.

4.5 In the light of the above analysis, the board disagrees, particularly in view of column 6, lines 20 to 23, with the finding in the appealed decision that the run-time image known from D1 includes multiple hardware abstraction layers, the reasons for the decision not citing any part of D1 which discloses this feature. However the board agrees with the finding in the appealed decision (see point 2.11, page 5, last three lines) that the skilled person reading D1 would understand that the software image transferred to the hard drive would contain a hardware abstraction layer for that particular computer and that said hardware abstraction layer would need to be configured.

4.6 Hence, in terms of claim 1 of the main request, D1 discloses: a method of transferring a run-time image (figure 1; 102) from a source computer-readable medium (mass storage 122) to one or more target computer-readable media (hard drive 112) of a target computer (computer 104) via one or more transfer computer-readable media (CD ROM 106), said method comprising: copying the run-time image onto the transfer media (see CD ROM burner 118); and copying an executable install routine onto the transfer media (CD restoration program on floppy 108), wherein said executable install routine, when executed by the target computer, applies the run-time image to the target media and performs integration of the applied run-time image with the target computer including configuring a hardware abstraction layer.

5. Inventive step, Article 56 EPC 1973, the main request

5.1 According to the reasons for the appealed decision, the subject-matter of claim 1 of the then main request differed from the disclosure of D1 in that:

1. the run-time image is operable with different hardware configurations of target computers,

2. the executable install routine copies its functionality to the target media and

3. the run-time image is integrated with the target computer after a re-boot into the applied run-time image.

5.2 These differences were held to be an aggregation of unrelated features. Difference 1 reduced the deployment and maintenance effort of a run-time system image in a heterogeneous system. It was known in the field of software engineering that the adaption of software to multiple different environments required that all specific aspects of the target environment be included. Differences 2 and 3 were both obvious design choices for the person skilled in the art of software installation.

5.3 Claim 1 of the main request has since been amended by adding features relating to a list of integration tasks (referred to as feature "d" below), these features having been previously discussed in the context of the former auxiliary request.

5.4 In the oral proceedings the appellant argued that the skilled person starting from D1 would have addressed the problem of increasing the efficiency of software installation. The board takes the view that this problem cannot be regarded as the objective technical problem because the claimed solution does not increase the efficiency. It merely defers computational efforts by anticipating the preparation of images for several hardware variants. The skilled person would be aware that such a "one size fits all" software solution would not be more efficient than a "made to measure" tailored image for a specific hardware configuration.

5.5 The appellant also initially disputed whether D1 disclosed the configuration of a hardware abstraction layer, since D1 did not mention any integration tasks once the system image had been copied to the hard disk, but later agreed with the board that, although not explicitly mentioned in D1, such configuration steps were implicit in the method known from D1.

5.6 Thus it is common ground between the board and the appellant that the subject-matter of claim 1 differs from the disclosure of D1 in the following features:

a. the run-time image includes multiple hardware abstraction layers so that it is operable with different hardware configurations of target computers,

b. the executable install routine copies its functionality to the target media,

c. the run-time image is integrated with the target computer after a reboot into the applied run-time image and

d. said executable install routine comprising a list of integration tasks which are performed to carry out said integration.

5.7 Difference feature "a"

5.7.1 It is common ground between the board and the appellant that difference feature "a" addresses a different problem to difference features "b", "c" and "d".

5.7.2 The appellant has argued that the invention addresses the problem of making the installation process faster and less error prone by separating installation tasks that are machine specific from those which are common to different platforms. The board does not accept that the application discloses such a separation, since both the run-time image and the subsequent "integration" phase may relate to both generic and machine-specific aspects. For instance, while much of the run-time image relates to parts of the operating system common to all computers, the multiple hardware abstraction layers relate to machine-specific aspects such as the motherboard; see page 8, lines 8 to 14. Similarly the "integration" tasks mentioned in the description relating to software registration, pre-installing application programs and updating one or more system settings with security identification data to identify the target computer are common to all computers, while hardware-specific tasks such as configuring the HAL and identifying any mass storage device controllers on the target computer are machine-specific tasks.

5.7.3 In its preliminary opinion in the summons for oral proceedings, the board stated that difference feature "a", which was also present in the previous version of the claims, addressed the problem of allowing the run-time image to be used with a greater variety of hardware. The skilled person starting from D1 and, in view of column 2, lines 29 to 33, seeking to allow system restoration even if the user has installed hardware not supplied by the factory (contrary to the assumption in column 7, lines 54 to 56) would have incorporated more hardware abstraction layers to allow the run-time image to be adapted to a greater variety of hardware as a matter of usual design. In the oral proceedings the appellant challenged this problem, arguing that it contained a pointer to the solution by mentioning changing the computer hardware. According to the appellant, it was not reasonable to formulate a problem in contradiction to the clear statements in D1 that it was assumed that the computer hardware was unchangeable (see column 7, lines 54 to 56) and that the restored software image was "built to order" to correspond to that hardware configuration; see column 2, lines 47 to 49. The board does not accept this argument because the skilled person would understand that D1 implies the configuration of a hardware abstraction layer, implying that the software, in particular the device drivers, can deal with some variations in the hardware, be it only updated versions of the same hardware components. Moreover the skilled person would be aware that the computer identity is established using the service tag number of the computer (see figure 2; step 224), rather than by checking the identities of the individual hardware components comprising the computer. Hence a hardware change not affecting the service tag number would not prevent the restoration process from being carried out. Consequently the board takes the view that the skilled person would recognise that D1 does not teach that no changes in hardware configuration are possible. It would thus be reasonable for the skilled person to consider hardware modifications.

5.7.4 The board concludes that the objective technical problem starting from D1 can be formulated as allowing the run-time image to be used with a greater variety of hardware, this problem not containing an unallowable pointer to the solution. The skilled person solving this problem would have incorporated more hardware abstraction layers in the run-time image to make the run-time image operable with different hardware configurations of target computers, as set out in feature "a", and thus produced a more generic restoration CD ROM as a matter of usual design.

5.7.5 Hence difference feature "a" does not involve an inventive step.

5.8 Difference feature "b"

5.8.1 In the oral proceedings the appellant argued that difference features "b", "c" and "d" acted together to solve a second problem, namely that of integration. While, generally speaking, difference features "b", "c" and "d" do indeed relate to different aspects of integration, there is no synergistic effect, each difference feature having the effects that it would have, taken alone. Hence the contributions of each feature to inventive step must be considered separately.

5.8.2 Difference feature "b", the executable install routine copying its functionality to the target media, addresses the problem of speeding up execution of the install routine. The skilled person would have been aware as a matter of common general knowledge that, as conceded by the appellant in the oral proceedings, the target computer can access its own media, for instance hard disk 112 (see figure 1), more quickly than it can access transferable media, for instance the flexible diskette ("floppy") 108 (see figure 1). Hence the skilled person would, as a matter of usual design, have added feature "b" to allow the install routine to be executed more quickly.

5.8.3 Hence difference feature "b" does not involve an inventive step.

5.9 Difference feature "c"

5.9.1 Although D1 does not explicitly disclose any integration processes once the software image has been transferred to the hard disk of the computer, the skilled person would have been aware, as a matter of common technical knowledge, that integration processes of some sort would typically follow the removal of the bootable flexible disk and the rebooting operation disclosed in D1; see column 9, lines 29 to 33. In the absence of the bootable flexible diskette, the reboot would inevitably occur into the applied run-time image. Hence difference feature "c", the run-time image being integrated with the target computer after a reboot into the applied run-time image, relates to a matter of usual design. This has not been disputed by the appellant.

5.9.2 Hence difference feature "c" does not involve an inventive step.

5.10 Difference feature "d"

5.10.1 This difference feature, said executable install routine comprising a list of integration tasks which are performed to carry out said integration, is a clarified version of a feature commented on by the board in its summons, albeit in the context of the previous version of the auxiliary request. The board took the view that the organisation of integration tasks as a list seemed to be a matter of routine for the skilled person. The appellant has not challenged this view.

5.10.2 Hence difference feature "d" does not involve an inventive step.

5.11 Conclusion on the main request

Since none of the difference features between the subject-matter of claim 1 and the disclosure of D1 involves an inventive step in view of D1, the board finds that the subject-matter of claim 1 according to the main request does not involve an inventive step, Article 56 EPC 1973.

6. Inventive step, Article 56 EPC 1973, the auxiliary request

6.1 According to the reasons for the appealed decision, the subject-matter of claim 1 according to the then auxiliary request had been restricted with respect to that of the main request by adding the following feature: the integration tasks comprise updating one or more system settings for the target computer with the security identification data. It was known to the skilled person, in an installation process, to configure a system by updating system settings referring to security data.

6.2 The appellant has argued that the difference features are more than an aggregation of unrelated features and that they further separate machine-specific from common tasks. Contrary to the method of D1, the claimed method, before applying the image, determined parameters of the target computer (see figure 2, step 52 and page 5 of the description) and, after having applied the image, updated the system settings with said parameters. The service tag known from D1 was only used to determine whether the image should be installed on the computer and did not play a part in the subsequent installation steps. Hence the service tag could not be considered as the claimed security identification data. Moreover the method of D1 sought to restore the computer to its original factory new state in spite of any data on the target computer. In contrast, according to the invention, the data structures from the applied image are merged into the computer's existing data structure; see page 5, lines 18 to 19. Parameters comprising security identification data, determined from the target computer, were integrated with the applied run-time image after a reboot into the image. It was not obvious to update system settings for the target computer with the security identification data.

6.3 Claim 1 of the auxiliary request has been restricted with respect to claim 1 of the main request by adding two features relating to the executable install routine, namely that it:

e. determines one or more parameters specific to the target computer comprising security identification data, the integration tasks comprising integrating the determined parameters and the applied run-time image with the target computer and updating one or more system settings for the target computer with the security identification data to identify the target computer, and

f. identifies any mass storage device controllers on the target computer.

6.4 Difference features "e" and "f" lack any synergistic effect in combination with differences "a" to "d", discussed above, and between themselves so that their contributions to inventive step must be considered separately.

6.5 Difference feature "e"

6.5.1 This feature is a clarified form of that commented on by the board in its summons, albeit in the context of the previous auxiliary request. The board stated that it accepted the appellant's argument that the service tag of the computer in D1 (as opposed to the tag ID of the CD ROM) (see column 9, lines 50 to 52) could not be considered as the claimed security identification data, since the service tag was not used to update one or more system settings, as set out in the claims, but rather to decide whether or not to initiate the restoration process. Hence the board took the view that feature "e" was a further difference feature over D1. The board however doubted whether feature "e" necessarily solved a technical problem and thus could contribute to inventive step, since it seemed to merely set out the reading of parameters and the updating of settings, the claims not being limited to the use of the data for security purposes.

6.5.2 Although feature "e" now sets out the the security identification data being used to identify the target computer, which covers the use of the service tag to identify the computer known from D1, the board is satisfied that feature "e", as a whole, is not known from D1, since D1 does not disclose the updating of one or more system settings for the target computer with said determined parameters, including the security identification data to identify the target computer.

6.5.3 In the oral proceedings the appellant did not expand its arguments as to the inventive step of this feature.

6.5.4 The board finds that, although feature "e" mentions "updating one or more system settings for the target computer with the security identification data to identify the target computer", the application does not disclose the target computer being identified using the updated settings based on the security identification data. The board understands the expression in feature "e" "to identify the target computer" as setting out the potential in the target computer to be recognised, rather than requiring that recognition of the target computer actually occur. The board concludes that feature "e" sets out the reading of parameters and the updating of settings but does not solve a technical problem and thus cannot contribute to inventive step; see T 0154/04 ("Estimating sales activity/DUNS LICENSING ASSOCIATES", OJ EPO 2008, 046, reasons 5(F)).

6.6 Difference feature "f"

6.6.1 As the appellant explained in the oral proceedings, feature "f", identifying any mass storage device controllers on the target computer, is based on page 8, lines 12 to 14, of the description. The appellant also argued that while it was known for operating systems to identify mass storage controllers, it was not obvious for an executable install routine to do so.

6.6.2 Since, as the appellant conceded in the oral proceedings, the application does not disclose what is done with the information if any mass storage device controllers on the target computer are identified by the executable install routine, the board finds that feature "f" does not solve a technical problem and thus cannot contribute to inventive step; again, see T 0154/04 (cited above).

6.7 Conclusion on the auxiliary request

Since none of the difference features between the subject-matter of claim 1 and the disclosure of D1 involves an inventive step in view of D1, the board finds that the subject-matter of claim 1 according to the auxiliary request does not involve an inventive step, Article 56 EPC 1973.