T 0584/14 (Isolator instances/RED BEND SOFTWARE) 14-10-2020
Téléchargement et informations complémentaires:
SYSTEM FOR ENABLING MULTIPLE EXECUTION ENVIRONMENTS TO SHARE A DEVICE
Summary of Facts and Submissions
I. The appeal is directed against the decision of the examining division, dated 4 October 2013, to refuse application No. 07857090 for added subject-matter (Article 123(2) EPC) of the then main request and auxiliary requests 1-4, and for lack of inventive step of auxiliary request 5 over the following document:
D1|A. Radonic, F. Meyer: "Xen 3", October 2006, Franzis-Verlag, XP002477592, ISBN: 3-7723-7899-4. |
As "further remarks", objections concerning lack of inventive step were raised against the main request and auxiliary requests 1-4.
II. A notice of appeal was received on 16 December 2013. The appeal fee was paid on the same day. A statement of grounds of appeal was received on 14 February 2014. Claim sets according to a main and five auxiliary requests were filed.
III. In a communication dated 17 February 2020, the board raised objections of added subject-matter and lack of inventive step.
IV. In a letter dated 27 April 2020, the appellant submitted arguments and filed new auxiliary requests 1-3. The newly filed claims of auxiliary requests 1-3 are not materially different from those filed with the grounds of appeal.
V. In the summons to oral proceedings, the board addressed the appellant's arguments and gave further reasons why the claims still lacked an inventive step.
VI. In response to the summons, the appellant did not file any arguments or amendments but, in a letter dated 11 September 2020, notified the board that it would not be represented at the oral proceedings.
VII. Subsequently, oral proceedings were cancelled.
VIII. The appellant requests that the decision be set aside and that a patent be granted on the basis of the claims according to:
- the main request, filed with the grounds of appeal;
- auxiliary requests 1-3, filed with letter of 27 April 2020;
- auxiliary request 4, filed with the grounds of appeal;
- auxiliary request 5 (subject of the appealed decision), filed with telefax of 19 August 2013 and re-filed with the grounds of appeal.
IX. Claim 1 of the main request reads as follows:
"1. A data processing system comprising:
a shared physical device for shared access by multiple clients;
a primary partition associated with the shared physical device, the primary partition comprising a device driver for accessing the shared physical device, and a back end driver for accessing the device driver;
multiple secondary partitions each comprising a respective one of said multiple clients and a front end driver for accessing the shared physical device via the primary partition;
wherein each secondary partition comprises a virtual device representing an image of the physical device intended for access by a respective one of said multiple clients; and
wherein secondary partitions that do not run trusted software comprise instances of an isolator for preventing communications between the secondary partitions and the primary partition except through said virtual devices."
X. Claim 1 of auxiliary request 1 differs from that of the main request in that the last paragraph reads (additions are underlined):
"wherein secondary partitions that do not run trusted software comprise instances of an isolator for preventing communications between the secondary partitions and the primary partition except through said virtual devices, wherein each isolator instance is to protect hardware resources not owned by a domain associated with the corresponding secondary partition from being accessed by software running within that secondary partition."
XI. Claim 1 of auxiliary request 2 differs from that of the main request in that the last paragraph reads:
"wherein secondary partitions that do not run trusted software comprise instances of an isolator for preventing communications between the secondary partitions and the primary partition except through said virtual devices, wherein each isolator instance is arranged to operate at privileged CPU level in ring 0 and to run a guest operating system at non-privileged CPU level in ring 1."
XII. Claim 1 of auxiliary request 3 differs from that of auxiliary request 2 in that the last paragraph reads:
"wherein secondary partitions that do not run trusted software comprise instances of an isolator for preventing communications between the secondary partitions and the primary partition except through said virtual devices, wherein each isolator instance is arranged to operate at privileged CPU level in ring 0 and to run a guest operating system at non-privileged CPU level in ring 1 wherein each isolator instance is arranged to replace privileged CPU instructions unavailable at non-privileged CPU-level with equivalent services, and wherein the kernel of each guest operating system is arranged to invoke said services in order to perform privileged CPU instructions."
XIII. Claim 1 of auxiliary request 4 differs from that of the main request in that the last paragraph reads:
"wherein secondary partitions that do not run trusted software comprise instances of an isolator for preventing communications between the secondary partitions and the primary partition except through said virtual devices, wherein said instances of an isolator are different from one another and arranged to run concurrently."
XIV. Claim 1 of auxiliary request 5 differs from that of the main request in that the paragraphs after the paragraph starting with "multiple secondary partitions" read (additions are underlined; deletions are [deleted: struck through]):
"a virtualizer for dispatching hardware resources of the data processing system across the primary and secondary partitions, thereby to provide independent execution environments in the primary and secondary partitions, respectively;
wherein each secondary partition comprises a virtual device representing an image of the physical device intended for access by a respective one of said multiple clients; and
[deleted: wherein secondary partitions that do not run trusted software comprise instances of an isolator for preventing communications between the secondary partitions and the primary partition except through said virtual devices]
wherein each secondary partition comprises an isolator for preventing communications between the secondary partitions and the primary partition except through said virtual devices."
Reasons for the Decision
1. Summary of the invention
The claimed invention mainly relates to virtual machine monitor software (also called a "hypervisor" or "virtualizer" in the application) which is said to be designed according to the needs of embedded and real-time systems (original description page 13, last paragraph). During its run-time, the virtualizer generates several virtual machines ("partitions" in the application) which share a device (e.g. a network or a hard disk, see figures 13 and 14). This "shared physical device" is accessed through a chain of device drivers (see figures 2 and 14): the virtual machine (called "secondary partition" in the current claims, "type 3 partition" in figure 2, "partition of the third type" in original claim 1 and "Linux Kernel" in figure 14) that wants to access the device has a "front-end driver" that connects through the virtualizer to a "back-end driver" in the "primary partition" (see current claims; "type 2" in figure 2; "second type" in the original claims; "Trusted Executive" in figure 14), which itself connects to the "device driver" ("native device driver" in figure 2; "second device driver" in original claim 1), located in the same primary partition as the back-end driver. The front-end driver is said to "expose" an "image of a virtual device representing an image of the actual device" (page 10, lines 19-20) or to "comprise a virtual device representing an image of the physical device" (original claim 5 and current claims), which means nothing more than that the front-end driver is the virtualised driver-counterpart in a secondary partition for accessing the real device through the "virtual device" (i.e. through the back-end and native drivers).
2. Inventiveness
2.1 Main request and auxiliary requests 4 and 5
2.1.1 It is stated in the grounds of appeal (page 5, last paragraph) that claim 1 of auxiliary request 5 is distinguished from the prior art for essentially the same reasons as claim 1 of the main request. The board agrees and therefore treats the two requests together (for claim 1 of auxiliary request 4, see section 2.1.12).
2.1.2 The board furthermore agrees with the decision (section 5.4 in combination with 5.1) that D1 is a suitable starting point for the problem solution approach.
2.1.3 D1 discloses front-end, back-end and native device drivers (page 92, Abb. 4.6: "Frontend Driver Block Devices", "Backend Driver Block Devices", "Treiber") and virtual devices (page 89, Abb. 4.3: "Virtuelle Block-Geräte"). D1 also discloses a primary partition and multiple secondary partitions (see Abb. 4.6: "Domain 0" corresponding to the primary partition and "domU 1" to "domU 3" corresponding to the secondary partitions).
2.1.4 D1 further discloses the functionality of an "isolator" as defined in claim 1 of the requests, i.e. preventing communications between the secondary partitions and the primary partition except through the virtual devices. See D1, page 89, second paragraph:
"Die Domain 0 ist als privilegierte Domain im Besitz der physischen oder 'orginalen' Geräte-Treiber. ... Die domU-Kernel sind so modifiziert, dass sie über die virtuellen Treiber mit den physischen Treibern der Domain 0 kommunizieren ..."
In D1 and the invention, modified operating system kernels are used (this is the usual way of implementing so-called "paravirtualisation"). See description page 24, lines 1-5:
"Each partition is dedicated to run an Execution Environment managing resources assigned to the partition. Note that existing operating systems need to be ported on virtualizer to run within a partition as a guest OS. In other words, sources of an existing operating system kernel have to be modified in order to run within a partition created by the virtualizer." (emphasis added)
2.1.5 Claim 1 differs at most from D1 in that the isolator (functionality) is comprised in the secondary partition.
2.1.6 "At most" because it is not certain if the claimed system and that of D1 really differ, since if there is program code supporting the isolating functionality, which for some (e.g. programming) reasons must be located in the secondary partitions, then it can be assumed that also in D1 this code is located in the "domU"s. There can only be a difference between the claim and D1 if there is other code supporting the isolating functionality, which can either be located in the primary partition, or in the virtualizer (hypervisor), and if this code belongs to the claimed isolator.
2.1.7 In the following, we assume that this difference exists.
2.1.8 However, in general, the organisational structure of a program (e.g. its distribution/partitioning into pieces of software) cannot contribute to an inventive step because its effects will normally be limited to matters of programming which, per se, is considered not to be a technical activity (see T 1541/16, 2.8, and T 1539/09, headnote).
2.1.9 In this case, the board cannot recognise a technical effect going beyond the effects of programming, nor did the appellant indicate any in the grounds of appeal or its submission of 27 April 2020.
2.1.10 As to the feature of having multiple isolator instances (i.e. one per partition) to allow heterogeneous partitions (see also the grounds of appeal, page 2, paragraph 3-4), the board finds that it is obvious for a skilled person to either integrate code for heterogeneous partitions in the virtualizer, or to put it in specific pieces/instances of software coupled to concerned partitions. The skilled person would choose one of the two alternatives without exercising inventive activity according to desired effects and potential side conditions.
2.1.11 Thus, the board finds it obvious to the skilled person to put program code common to all partitions into the virtualiser and partition-specific program code in the concerned partition to fulfil the desired requirements for isolation. Moreover, the board points out that the partitions of D1 (called "Domains") are also heterogeneous, see figure 4.3 on page 89 with three different operating systems (Linux, NetBSD, FreeBSD).
2.1.12 It further follows from the preceding that it would be obvious to provide different isolators for different partitions, which would then have to run concurrently, as in claim 1 of auxiliary request 4.
2.1.13 Therefore, the subject-matter of claim 1 according to the main request and auxiliary requests 4 and 5 is considered not to be inventive.
2.2 Auxiliary requests 1-3
2.2.1 The additions in claim 1 of auxiliary request 1 merely explicitly formulate the aim of isolator instances. This aim (i.e. to protect hardware resources) is already implicitly present in the main request and therefore cannot establish an inventive step.
2.2.2 As to auxiliary request 2, the board agrees with the decision (page 18, first paragraph) that it is a matter of common knowledge that lower layers of system software run in a privileged CPU mode, while higher layers run in non-privileged mode. Thus, it would be obvious to make the (lower-layer) isolator code run in a privileged CPU level and its guest OS in a non-privileged CPU level.
2.2.3 As to the appellant's allegation on page 3, section 3 of the reply dated 27 April 2020 that it was not common knowledge to run isolating code in ring 0 and guest operating systems in ring 1, the board refers to D1 (page 90, Abb. 4.4) where the virtualiser (called "XEN Hypervisor"; including the common isolating code) runs in ring 0, and the guest operating systems (called "domU Kernelspace") run in ring 1. Thus, irrespective of whether this feature was common general knowledge or not, it is anyway disclosed in D1.
2.2.4 As to auxiliary request 3, a direct consequence of running the guest OS in non-privileged mode and the isolator in privileged mode consists in that privileged CPU instructions are no longer available for the guest OS but for the isolator below it. Thus, knowing that the guest OS needs the functionality of these privileged CPU instructions, the programmer would have to use common programming skills to provide their functionality in the non-privileged mode, e.g. by "emulating" the instructions. Putting this emulating code into the isolator would be an obvious choice, since the guest OS runs on top of the isolator and the privileged mode of the isolator allows doing so.
2.3 Therefore, the claimed subject-matter of all requests is not inventive within the meaning of Article 56 EPC.
Order
For these reasons it is decided that:
The appeal is dismissed.