T 1866/15 (Multiple execution environments/ORACLE) 28-06-2021

Reasons for the Decision

1. Summary of the invention

1.1 The application relates to an object-oriented software platform (e.g. for Java; see original description, [33]) for a computer of any type (e.g. desktop, laptop, PDA; [107]) providing (at least) two execution environments (see figure 2: "alpha environment 7" and "beta environment 5"). One class-loader (8) is associated with the alpha environment, and two class-loaders (18 and 20) with the beta environment (figure 2: 8, 18, 20; [54] and [51]). A class-loader dynamically loads classes into the Java Virtual Machine (JVM) during the runtime of an application ([38]).

1.2 The alpha environment is defined as having more capabilities than the beta environment ([24], third sentence). Capabilities in the meaning of the invention are resources available in the environment, such as libraries, interfaces, methods, classes, files or network connections ([25]). These resources may relate, for example, to the capability of floating point arithmetic ([93]).

1.3 A program called "alpha software application 16" in the claims (and "alpha environment application" or "alpha application" in the description and the figures; see for example [54]; figures 2 and 9: 908-910) is run in the alpha environment without that environment having any knowledge of the beta environment ([54], third sentence).

1.4 Another program called "beta software application 14" in the claims (and "beta environment application 14" in the description and the figures; e.g. [52] and figure 2 and 9: 904-906; the board hereinafter refers to it as "beta application") is run in the beta environment.

1.5 If the beta application requests capabilities which exist only in the alpha environment, but not in the beta environment, two situations may occur ([52] and [58]).

1.6 If the requested capability is, for example, an additional member in a class which exists in both environments, then the access to the additional member in the alpha environment is rejected by the first beta class-loader 18 ([52], first, fourth and fifth sentences).

1.7 But if the requested capability is, for example, a class (i.e. a class which exists only in the alpha environment, but not in the beta environment), then the request of the beta application is dispatched to the second beta class-loader 20 ([55], second and third sentences), which transfers it to the alpha environment to enable the beta application to indirectly access this specific alpha-only capability ([53]; [58]).

2. Inventiveness of claim 1 of the main request

2.1 The board agrees with the appellant that D1 is not an appropriate starting point for assessing inventive step, since it does not relate to virtual machines with class-loaders (such as the Java Virtual machine), but uses virtual machines of a completely different kind (namely those virtualising DOS operating systems on the virtual 8086 mode of the 80386 processor running OS/2, see page 6, first paragraph and page 6, figure 2, or -albeit with different capabilities - page 10, section 1.2.4, first two paragraphs).

2.2 The board will use D2 as a starting point instead. D2 discloses two Java Virtual machine execution environments with different capabilities, namely CDC ("Connected Device Configuration"; page 5, line 17 to page 8; corresponding to the alpha environment) and MIDP in combination with CLDC ("Mobile Information Device Profile" and "Connected Limited Device Configuration"; page 11, line 1, i.e. below table 1.4, to page 12; page 4, lines 26-28; this MIDP/CLDC combination corresponding to the beta environment).

2.3 CDC and MIDP/CLDC are given in the application as examples of the alpha and beta environments, respectively (see [30]-[31] and figures 3 and 10, with the corresponding description in [59] and [99]-[105]).

2.4 As to the expression "denying direct access", the board is of the opinion that it is an immediate consequence of the two environments being "isolated from" each other that there is no direct access between them. As there is no direct access from one isolated environment to the other, no dedicated means is required to "deny" direct access. Therefore, the board considers this feature to be implied by the feature that two environments are installed on the same computer and isolated from each other.

2.5 The invention thus differs from D2 essentially in that both environments are installed together on the same computer without any interaction.

2.6 However, the board considers it obvious to a skilled programmer to install these two environments on the same computer if he or she sees a need for executing alpha and beta applications on the same computer. Such isolated side-by-side installation of two environments on the same computer does not achieve any technical effect other than that alpha and beta applications can be run on the same computer. The desire to do so (i.e. to execute both types of applications on the same computer) was not technically justified at the oral proceedings.

2.7 The appellant argued that D2 explicitly taught away from installing the two environments on the same computer in stating (D2, page 9, lines 21-22):

"The CLDC is different from, yet also a subset of the CDC. The two configurations are independent of each other, however, so they should not be used together to define a platform."

2.8 However, this passage merely states that they "should" not be used together to define a platform, but not that it is impossible or prohibited to do so. It also does not explain why exactly the two environments "should" not be used together. In the board's view, the mere fact that the passage mentions the idea of using them together to define a platform (even if it advises against it) discloses that it is indeed possible.

2.9 Also, the fact that the beta environment contains a second class-loader (20) cannot contribute to an inventive step, since it is not used in the rest of the claimed subject-matter.

2.10 Therefore, the board agrees with the examining division that the subject-matter of claim 1 of the current main request (i.e. the then auxiliary request) is not inventive within the meaning of Article 56 EPC 1973.

3. Admittance of auxiliary request 1 under Rule 137(5) and (3) EPC

3.1 The examining division decided not to admit the main request under Rule 137(3) EPC because it did not meet the requirements of Rule 137(5) EPC (first sentence).

3.2 The board considers that Rule 137(5) EPC, first sen­tence, constitutes a substantive requirement on amended claims, and endorses the findings of T 2431/19 on this point. If an amendment does not comply with Rule 137(5) EPC, it is not allowable on that ground alone and the examining division no longer has discretion whether or not to admit it under Rule 137(3) EPC.

3.3 For this reason alone, the decision not to admit under Rule 137(3) EPC is incorrect and the auxiliary request is to be taken into account in accordance with Article 12(4) RPBA 2007.

3.4 On the substantive requirement, and in contrast to the decision (sections 4-6), the board is of the opinion that claim 1 of current auxiliary request 1 (i.e. the then main request) does comply with Rule 137(5) EPC.

3.5 The examining division (middle of page 8) referred to the Guidelines H-II, 6.2 which state, in pertinent part, that "an objection under Rule 137(5), first sentence, would [...] arise if a technical feature taken from the description which has an effect unrelated to the effect(s) of the features of the originally claimed invention(s) were added to a claim".

3.6 The board does not agree with the finding in the decision (see section 5.2 a.) that original claim 9 implies that access is denied altogether. However, even if that were to be the case, and if, therefore, the effect of "allowing access" were to be "unrelated to" the effects of "denying direct access", the board does not agree with the decision as regards Rule 137(5) EPC.

3.7 The board agrees with the general statement (see also Guidelines H-II, 6.2) that, in order to assess whether or not amended claims fulfil the requirements of Rule 137(5) EPC, first sentence, it needs to be established whether or not an objection of lack of unity would have been raised if the amended claims had been present in the set of claims on file at the time of the search.

3.8 The board takes the view that there cannot be a lack of unity between two claims where one strictly limits the subject-matter of the other. Accordingly, original claim 1 cannot lack unity with present claim 1, which is a strict limitation of original claim 1.

3.9 The board agrees with the quoted passage of the Guidelines (section 3.5 above) insofar as that the effect of an originally claimed invention could be that of a feature of a dependent claim. If, for example, claim 1 lacked novelty a posteriori and a "special technical feature" of the original set of claims was contained in claim 2, then the amendment of claim 1 by incorporation of another "special technical feature" with an unrelated effect could lead to the situation that amended claim 1 and original claim 2 lacked unity and that, accordingly, the amendment could not be allowed under Rule 137(5) EPC. If, however, the original "special technical feature" was contained in original claim 1, then the addition of another, even unrelated, "special technical feature", could not introduce a lack of unity between original and amended claim 1. Accordingly, such an amendment cannot be objected to under Rule 137(5) EPC.

3.10 However, if an amendment introduces a feature with an effect entirely unrelated to the effects of the original claims, this might well be a sound basis for the examining division to deny its consent under Rule 137(3) EPC.

3.11 Returning now to amended claim 1, the applicant (see decision, 5.1, points 2-3 and grounds of appeal, points 5.3-5.5) argued in support of unity that current claim 1 contained more features than original claim 9 (namely "allowing indirect access") and therefore was unitary with it.

3.12 The board prefers to compare current claim 1 with original claim 1 instead of original claim 9 (as in the decision), since current claim 1 does not contain the feature of a "plurality of beta environments" of original claim 9 (see decision, 5.2 b.) but notes that the examining division came to its conclusion even under the assumption that claim 1 was a limitation of original claim 9 (again, see the decision, 5.2 b.).

3.13 Hence, since amended claim 1 is a strict limitation of original claim 1, there cannot be a lack of unity and thus there is no violation of Rule 137(5) EPC.

4. Inventiveness of claim 1 of auxiliary request 1

4.1 Claim 1 of auxiliary request 1 differs from claim 1 of the main request in that (indirect) access from the beta environment to the alpha environment may be provided via a specific class-loader (20).

4.2 According to the appellant, this makes it possible to test a beta application which has been enriched with calls to alpha capabilities that are not present in the beta environment. Developers can carry out testing of enriched beta applications (and of their alpha capabilities) in the existing beta environment without changing it, before deciding whether to implement them in an enriched beta environment.

4.3 Although this scenario is not mentioned in the description, the board finds it plausible and cannot deny the advantages of the claimed invention in such a scenario. In the board's view, this also explains why one would not simply run the enriched beta applications in the alpha environment (notwithstanding various possible compatibility issues between the two environments), namely because the goal is to eventually enrich the beta environment.

4.4 The problem to be solved by the present invention may therefore be regarded as how to integrate alpha capabilities in the beta environment.

4.5 Starting from D2, the straightforward way to solve this problem would be to program the desired alpha capabilities directly into the beta environment.

4.6 However, the invention saves the work of reprogramming the alpha capabilities in the beta environment (at least for testing) and instead teaches installing both environments, running the beta application in the (yet) unchanged beta environment and forwarding calls to alpha capabilities to the alpha environment via a special additional class-loader (20).

4.7 Although additional user-defined class-loaders are known for accessing user-defined and remote sources/locations (as shown, for example, in description paragraphs [38] and [40]-[41]), they are only used according to these passages for loading external classes into the same environment. Here, however, the alpha capability is loaded into the alpha environment, not into the beta environment (see the last paragraph of the claim: "a request ... may access the alpha environment (7) via the beta ... class-loader (20)"). This allows the alpha code to be executed in the alpha environment, thereby avoiding the compatibility problems between the two environments that might arise when loading the alpha code into the beta environment. This methodology clearly goes beyond the normal utilisation of user-defined class-loaders to provide access to user-defined sources/locations (as argued in the summons, section 6.8).

4.8 Therefore, the board considers the subject-matter of claim 1 of auxiliary request 1 to involve an inventive step over D2.

4.9 However, in its decision (4 a., last sentence) the examining division "considers" that the additional feature of current auxiliary request 1 (i.e. the then main request), namely accessing the alpha environment (7) via an additional beta class-loader (20), was not searched. Since the search examiner was not part of the examining division, they could not be sure what was searched, and what was not.

4.10 Since the board considers it probable that the search for present claim 1 did not cover the additional feature taken from the description ([58]), it is not in a position to order the grant of a patent. Exercising its discretion under Article 111(1) EPC, it remits the case to the department of first instance for further prosecution. This will make it possible for the examining division to carry out any necessary additional search for claim 1 of auxiliary request 1 and to assess inventive step on this basis.