T 2097/11 (Application server/HEWLETT PACKARD) of 2.5.2017

Summary of Facts and Submissions

I. The appeal lies against the decision of the examining division, with reasons dispatched on 10 May 2011, to refuse European patent applica­tion No. 06 801 158.4 for lack of compliance with Articles 123(2) and 84 EPC. The decision also mentioned inter alia document

D1: US 2005/081097 A1,

but did not rely upon it in its reasons. However, with its summons to oral proceedings, dated 26 October 2010, the examining division had argued why it considered then claim 1 to lack inventive step over D1.

II. Notice of appeal was filed and the appeal fee was paid on 27 June 2011. A statement of grounds of appeal was received on 8 September 2011. The board understands the appellant's requests to be that the decision under appeal be set aside and that a patent be granted on the basis of claims according to a main or one of two auxiliary requests (claims 1-21, 1-18 and 1-21, respectively) as filed with the grounds of appeal.

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

"An application server system (10), comprising:

one or more clients (40) operable to execute one or more applications, each client executing one or more virtual client environments (50); and

a main server (20) operable to control the one or more clients (40) and to manage the distribution of virtual client environments over various client computers (40); and

each virtual client environment comprising:

one or more application objects (56), each application object associated with an application being executed at the client and operable to store operating information related to the associated application, each application has one or more associated processes (58; 60; 62), each process having an associated process companion (64; 66; 68); and

a lightweight server (54) operable to:

instantiate the application objects (56) in response to receiving configuration information from the main server (20);

receive operating information from the application objects (56) relating to the operation of the associated applications and communicate the received information to the main server (20); and

control the applications based on at least one of: (i) the configuration information received from the main server and (ii) further instructions received from the main server (20) after instantiation of an application object (56) to control each process (58; 60; 62) by actions applied to the associated process companion (64; 66; 68)."

Claim 1 of the first auxiliary request differs from claim 1 of the main request by adding that the virtual client environment further comprises

"... the applications, process companion and jobs may contain and handle meta-information, the meta-information comprising information about the applications, processes and groups of applications running together as jobs,; [sic] ..."

and by claiming a "virtual client environment server (54)" instead of a "lightweight server (54)".

Claim 1 of the second auxiliary request reads as follows:

"An application server system (10), comprising:

a main server (20); and

one or more clients (40) controlled by the main server and operable to execute one or more applications, each client executing one or more virtual client environments (50), each virtual client environment comprising:

one or more application objects (56), each application object associated with an application being executed at the client and operable to store operating information related to the associated application; and

a lightweight server (54) operable to:

instantiate the application objects (56) in response to receiving configuration information from the main server (20);

receive operating information from the application objects (56) relating to the way the associated application object is to be deployed via invocation of a define application macro and its corresponding passed arguments in the application code and communicate the received information to the main server (20); and

control the applications based on at least one of: (i) the configuration information received from the main server and (ii) further instructions received from the main server (20) after instantiation of an application object (56)."

All three requests also comprise a corresponding independent method claim 11 or 12.

IV. In an annex to a summons to oral proceedings, the board informed the appellant of its preliminary opinion that claim 1 of all three requests lacked inventive step over D1. Objections under Articles 84 EPC 1973 and 123(2) EPC were also raised.

V. In response to the summons, the appellant did not file any amendments or arguments. Instead, with letter of 27 April 2017, the appellant informed the board that neither the applicant nor its representative would be attending the scheduled hearing.

VI. The oral proceedings took place as scheduled and, as announced, in the appellant's absence. At the end of the oral proceedings, the chairman announced the board's decision.

Reasons for the Decision

Decision in the appellant's absence

1. According to Article 15(3) RPBA the board is not obliged to delay any step in the proceedings, including its decision, by reason only of the absence at the oral proceedings of any party duly summoned. Therefore, and also in accordance with Article 15(3) RPBA, the board is treating the appellant as relying only on its written case. The following reasons correspond substantially to those given in the board's preliminary opinion and to which the appellant had chosen not to respond.

The invention

2. The invention relates to an "enterprise application server" (EAS) "and method" (see page 1, lines 4-5; all references being to the application as originally filed). The EAS is composed of several computers, specifically a "main server" and a number of client computers to which the main server delegates its tasks (see figure 1).

2.1 The "main server" transmits "virtual client environments" (VCEs), preferably Lisp "worlds", to the client computers (see page 4, lines 11-12 and 27-29; page 6, lines 7-16; page 10, lines 17-18), and then starts, monitors and controls applications on the VCEs (see page 7, lines 12-18). There may be more than one VCE per client, several applications per VCE and several processes per application (see figures 3 and 4; page 4, lines 29-31; page 5, lines 1-14).

2.2 Each VCE provides a component referred to as a "lightweight server" which acts as an interface between the main server and the applications within the VCE (page 5, lines 4-7; page 10, line 33, to page 12, line 8; page 12, lines 18-20; figure 3, no. 54). In other words, the lightweight server (effectively on behalf of the main server) deploys and controls the applications (via associated application objects) and returns runtime information about user, applications and processes to the main server.

2.3 Each process has an associated "process companion" (see figure 4 and page 13, paragraph 2). The description states that process companions are "data elements" (page 5, lines 9-11) but does not define them any further, except to say that the "activity [of each process] may be controlled and monitored by actions applied to the process companion" (loc. cit.).

2.4 The application states that the EAS architecture uses "a level of abstraction (meta-information)" to separate an application's business functionality and its deployment. This "meta-information" is said to be about the applications, processes and jobs, and to be handled by "application objects, process companions and jobs". "These objects" are also said to be controlled by the EAS system and to respond to this control "in a specific way" (see page 3, line 29, to page 4, line 5).

The prior art

3. D1 discloses a distributed computing architecture with a "distributed (computing) management server" and several worker clients (see e.g. figures 1 and 2A). The server sends the applications and job parameters to the clients and receives "job results" from them (see paragraph 40). The software structure of a worker client is depicted in figure 3B. Each client provides an "environment" (see esp. the grid infrastructure (33), the worker client infrastructure (35) and the runtime environment (32) possibly comprising a Java virtual machine; see paragraphs 75-78). Moreover, each client comprises a "work unit transfer component" (40) for receiving applications and job parameters and for sending results (see paragraph 87), and a "work engine task processing component" for accepting and executing jobs (paragraph 88).

Article 123(2) EPC

4. The contested decision found a lack of compliance with Article 123(2) EPC because the application (esp. on pages 3 and 4) did not disclose "meta-information objects", which the examining division interpreted as objects containing only such meta-information (see the decision, reasons 1.1.2, F3b). The term deleted or replaced in the claims on file, this objection has become moot. The further objection under Article 123(2) EPC which the board raised of its own volition in the summons to oral proceedings is a minor one and will therefore not be considered in this decision.

Claim construction

5. The claims contain several terms which must be construed broadly. For the purposes of this decision, the board leaves open whether they are clear.

5.1 Claims 1 and 11 of the main request mention a "lightweight server". The board agrees with the decision (see reasons 3.1) that the limitations implied by referring to a server as "lightweight" are undefined. However, the board accepts the appellant's position that the term "lightweight" is merely used to assist the reader and that the relevant features of the main server and the lightweight server are those defined in the remainder of the claim (see the grounds of appeal, point 7.3).

5.2 The term "process companion" is mentioned in claims 1 and 11 of the main and the first auxiliary request but not defined. The main request merely specifies that each process is controlled "by actions applied to the associated process companion". In the board's view, this makes the claimed process companion indistinguishable from a process identifier which is referred to whenever an operation is to be performed on a particular process. The first auxiliary request further states that the process companion may "contain and handle meta-information". This suggests that the process companion is an "object" which contains information other than the process identifier. The role of that information is, however, undefined.

5.3 In fact, claims 1 and 11 of the first auxiliary request state merely that the "meta-information" is "about the applications, processes and groups of applications", but fail to define the role of this meta-information in the context of the claimed system and method.

5.4 The term "configuration information" is used but not specifically defined in the claims. This information is stated to be "received from the main server" and used at the client side for the instantiation of application objects and to "control the applications" (see e.g. claim 1 of the main request, first and third paragraphs defining the lightweight server). In the board's view, however, the claimed use of the "configuration information" does not imply more than that the server instructs the clients which application objects to create (i.e. "instantiate").

5.5 Also the broad term "operating information" subsumes virtually any kind of information relating to the application objects being executed. For instance, it can refer to the computation results or to data needed for performance monitoring (see also page 7, lines 15-16). The claims do not specify what the main server uses the operating information for, or how.

6. In view of the foregoing, the board considers that the claimed subject-matter comes down to a system (and related method) comprising

- a main server,

- several clients,

- each client running one or more virtual client environments (VCEs) each being distributed from (i.e. on "instruction" by) the main server,

- each VCE running several applications and associated processes, each created on "instruction" by the main server and controlled ultimately by the main server, and each returning "operating information" to the main server, and

- each VCE having a (component called a) "lightweight server" or "virtual client environment server" which acts as an interface between the server and the applications, objects and processes.

Inventive step

7. The board is of the opinion that D1 is a suitable starting point for the assessment of inventive step.

8. The board agrees with the following central assumptions of the examining division, namely that

- D1 discloses that each client comprises a "client environment" (see the components of the archi­tecture depicted in figure 3B and, in particular, the runtime environment) which can be identified with the claimed "vir­tual client environment" (see D1, para­graphs 75-78, and the summons of 26 October 2010, page 5, feature F2), except that D1 does not disclose that their "distribution" is managed by the server; and also that

- the "work unit transfer component" 40 and the "work engine task processing component" 41 of D1 correspond, in combination, to the lightweight server in that the former component receives instructions from the main server and returns information to it and the latter component executes the jobs (see D1, paragraphs 40, 87 and 88, and the summons of 26 October 2010, page 6, feature F3b).

Main request

9. Accordingly, the board considers that claim 1 of the main request differs from the subject-matter of D1 in that

(a) the main server manages the distribution of the client environments (VCEs) to the clients,

(b) more than one client environment (VCE) is available on each client, and

(c) an application has several processes and each has a process companion enabling control of the process.

9.1 The board takes the view that these differences solve different, essentially unrelated problems. Feature (a) may be seen as making sure that the client environments are up-to-date. Feature (b) may be advantageous for security reasons because it helps keep applications separate from each other, but it may also simply reflect the fact that different applications might require different environments. Feature (c) serves to structure an application, for instance in view of parallelisation.

9.2 As regards feature (a), the board takes the view that it would be obvious to provide some sort of automated service for "distributing" updates of the client environments, and that locating this service at the claimed main server is one obvious choice.

9.3 As regards feature (b), the board takes the view that the skilled person is well aware of the potential advantages of having several separate environments on one physical client device, including the two mentioned, and would therefore resort to this measure without the need to exercise inventive skill if circumstances so required.

9.4 And as regards feature (c), the board takes the view that the use of processes, process control and process identifiers is well-known in the art of programming.

9.5 In summary, the board concludes that features (a)-(c) do not establish that the subject-matter of claim 1 involves an inventive step over D1, Article 56 EPC 1973.

10. Under these circumstances the question can be left open whether any of the above differences solves a technical problem at all. The board would merely note that in the annex to its summons it expressed doubts about that and also as to whether the claimed invention achieved the effects alleged by the appellant, namely "increased flexibility whilst maintaining reliability of a software operational environment" (grounds of appeal, point 7.5.4.1) because "applications" could be "more easily deployed" in the claimed architecture, as well as "hardware independence" and "scalability" (point 7.5.4.2). In not responding to the board's preliminary opinion, the appellant did nothing to dispel these doubts.

First auxiliary request

As mentioned above, claim 1 does not define the role played by the added meta-information in the context of the claimed server system. Therefore, the additional feature is insufficient to overcome the inventive-step objection presented above, so that also claim 1 of the first auxiliary request lacks inventive step over D1, Article 56 EPC 1973.

Second auxiliary request

12. The features added to claim 1 of the second auxiliary request specify that the lightweight server "receive[s] operating information from the application objects [...] relating to the way the associated application object is to be deployed" and that a "define application macro" is invoked for this purpose.

12.1 D1 discloses that the work unit transfer component "provides the mechanism to receive the application itself, job parameter and input files" (paragraph 87). In general terms, this implies - or at least suggests - the provision of "operating information" relating to the deployment of the application to the worker client. Using a "define application macro" for this purpose appears to be a straightforward option for the person skilled in the art of programming.

12.2 Claim 1 of the second auxiliary request thus likewise lacks inventive step over D1, Article 56 EPC 1973.

Order

For these reasons it is decided that:

The appeal is dismissed.