T 1225/16 (Resource management/ZHIGU) of 6.6.2018

Summary of Facts and Submissions

I. The appeal is against the decision of the examining division, dispatched with reasons dated 7 December 2015 to refuse European patent application No. 01 923 030.9 for lack of inventive step over the document

D3: US 5 640 569 A.

II. Notice of appeal was filed on 15 February 2016, the appeal fee being paid on the same day. A statement of grounds of appeal was received on 18 April 2016. The appellant requested that the decision under appeal be set aside and a patent be granted on the basis of the main request or the auxiliary request on file.

III. In an annex to a summons to oral proceedings, the board informed the appellant of its preliminary opinion that the claimed invention indeed lacked inventive step over D3.

IV. In response to the summons, by letter dated 4 May 2018, the appellant filed amended claims according to auxiliary requests 1 and 2.

V. During the oral proceedings, which took place on 6 June 2018, and after the board's indication that it would admit the new auxiliary requests, the appellant withdrew the main request and requested the grant of a patent on the basis of the claims of auxiliary requests 1 and 2 as filed on 4 May 2018.

VI. Claim 1 of auxiliary request 1 reads as follows:

"A computing system (20) implementing a resource management architecture including multiple consumers (32) at a user level and including at a kernel level multiple resource providers (104) and a resource manager (102), the consumers being applications, wherein:

said resource manager (102) exposes an application programming interface, API, including API calls in kernel mode;

said multiple consumers being adapted to use said API calls in kernel mode to create an activity (122) at said resource manager and to build one or more resource configurations (124), each resource configuration describing a set of resources required to perform the activity;

said multiple resource providers (104) are associated with said resources adapted to be utilized by said multiple consumers (32), wherein each of said resources is a finite quantity of a computing component in the computer system; and

said resource manager (102) is further adapted to arbitrate access to the resources provided by the resource providers by using one of a plurality of resource configurations that are specified for an activity (122) created by one of said customers."

Claim 1 of auxiliary request 2 differs from claim 1 of auxiliary request 1 in that at the end of the third paragraph the following text has been inserted:

"... wherein each resource configuration comprises one or more resource descriptors (126) each representing an instance of a resource required by said one consumer, wherein each resource descriptor comprises an identity field (128) to hold an identity of a specific resource provider that owns the required resource, an amount field (130) to hold the quantity of resource needed for that configuration, and an attribute field (132) to list one or more resource attributes; ..."

VII. At the end of the oral proceedings, the chairman announced the decision of the board.

Reasons for the Decision

The invention

1. The application generally relates to resource management in a distributed system in which multiple consumers compete for various resources such as, for instance, CPU time, USB bandwidth, virtual memory and audio volume (see page 8, penultimate paragraph, and page 15, lines 6-8; all references being to the description as originally filed).

1.1 Since resources are usually limited, it may not be possible to grant all resource requests simultaneously. Requests may be in conflict with each other (see, e.g., page 1, last paragraph, to page 2, paragraph 2). The invention proposes a resource management architecture with a conflict resolution mechanism.

1.2 The scenario considered in the application is depicted in figure 2 (see also page 3, paragraph 2, and page 14, last paragraph et seq.). Typical resource consumers (see figure 2, no. 32 and 35) are user-level computer applications, but kernel-level resource consumers are also possible (see page 15, lines 3-5; page 17, paragraph 3; and page 44, last paragraph et seq.). Resources are accessed via "resource providers" (see figure 2, no. 104) such as associated drivers (see page 15, lines 8-15), which typically run on kernel level, even though user-level resource providers are also mentioned (page 15, lines 14-15). To arbitrate resource access, a kernel-level resource manager is provided (see figure 2, no. 102, and page 16, paragraph 3, to page 17, paragraph 1).

1.3 A consumer intent on carrying out a certain task will use an application programming interface (API) provided by the resource manager to request access to one or more alternative sets of resources required for that purpose. Each such set of resources is stored in a data structure called a "configuration", and all of them are bundled in a con­tainer data structure called an "activity" (see page 3, para­graphs 4 and 5; page 17, paragraph 5, to page 18, paragraph 2; figure 2, no. 122 and 124; and figure 4, nos. 400 and 402). The data structures may specify which configurations are preferred and which are provided as "fallback" options (see e.g. page 35, paragraph 2).

The prior art

2. D3 discloses a system in which scarce computing resources, such as network bandwidth (also referred to as "goods"), are regulated by a pricing mechanism (see column 1, lines 32-55, and column 2, line 58, to column 3, line 2). A resource manager (called an "agoric arbiter", i.e. utilizing market mechanisms; see figures 2 and 3, no. 110, and column 4, lines 5-7) receives, from each of several requesters (see figure 1), a bid "slate" comprising several bids (see figure 5, no. 162, and column 5, lines 18-42), each of which lists a number of requested resources and a price the requester is willing to pay for them (see column 4, lines 51-67, and figure 3, nos. 132, 134, 140 and 142). The resource manager arbitrates (see figure 3, no. 126) between the bids and the available resources and produces a "winning bid combination", comprising at most one bid per bid slate, the combi­na­tion having the highest total bid price (see abstract, figure 3, nos. 144, 146, and 148, and figure 6; column 2, lines 64-66).

3. During the oral proceedings, the appellant stated that it was known in the prior art that operating systems would provide a kernel-level resource manager to arbitrate between conflicting user-level requests for resources, including kernel resources "owned" by suitable drivers. More specifically, it was known that user-level applications intent on carrying out a certain "activity", would request one set of required kernel-level resources (i.e. a single resource configuration) from a resource manager which would decide, in view of other resource requests, whether it could be served or not. It is common ground between the board and the appellant that this assumption requires no further proof.

Inventive step, Article 56 EPC 1973

"Auxiliary request 1"

4. During examination, in the decision under appeal, and in the board's preliminary opinion, the inventive step assessment was carried out starting from D3.

4.1 With the submission dated 4 May 2018, the independent claims were amended to make clear that the resource consumers were user-level applications whereas the "resource providers" and the "resource manager" operated "in kernel mode". These amendments were meant to set the claimed invention apart from D3 by stressing that the invention related to an operating-system service on a single computer system rather than to a user-level service in a distributed system as disclosed in D3 (see column 5, lines 1-14, and figure 4).

4.2 In view of these amendments, the appellant argued that it was more appropriate to assess inventive step starting from the known resource management in a conventional computer system such as that sketched above (point 3). The board agrees.

4.3 The board also accepts the appellant's point that the claimed invention according to "auxiliary request 1" differs from this known computer system essentially in that the user-level applications can, via a suitable interface, specify not only a single "resource configuration" but "one or more resource configurations [...] required to perform [an] activity".

4.4 In the known computer system, a user-level application whose request could not be served would either receive a suitable error message or have to wait. Often this would be noticeable to the user, for instance if a high-resolution news video could not be delivered due to a lack of communication bandwidth. The board regards it as obvious that users would then consider alternative ways of completing their "activity". For instance, they might consider requesting, via the appropriate user-level application, a lower bandwidth video stream or merely the audio stream (see, in this regard, also D3, column 4, lines 62-65).

4.5 In similar scenarios, the distinguishing feature relieves the users from the inconvenience - in terms of time delay and effort - of having to request the potential alternatives one after the other.

4.6 D3 discloses a solution to this type of problem. Users may, in a single request ("bid slate"), specify their alternatives ("bid"), and the "agoric" arbiter selects a combination of bids determining which resources are to be allocated to each requester (see column 4, lines 8-14).

4.7 Incorporating this solution into the known computer system requires modifications to the resource manager and its interface, as both must be able to handle "one or more resource configurations" per request, but is otherwise independent of which type of resources is requested.

4.8 The board thus concludes that the skilled person, setting out to simplify the user interaction with the known computer system in the situations mentioned above, would consider and find a suitable solution in D3. Adapting this solution to the kernel-level resource manager and resource providers would, in the board's judgment, not involve any difficulty for the skilled person.

5. The appellant has argued that the skilled person would not apply the user-level solution of D3 to improve kernel-level resource management in an operating system because operating systems were generally complex, closed and proprietary.

5.1 The board disagrees that this is necessarily the case. For example, the early Unix-type operating system Minix released in 1987 was open, free and comparatively simple.

5.2 Moreover, ope­ra­ting systems are constantly being developed further, even if they are complex, closed and proprietary. These properties would, therefore, not discourage the skilled person from incorporating a known user-level solution into an operating system to improve a kernel-level service.

6. In summary, the board concludes that claim 1 of "auxiliary request 1" lacks inventive step over the known computer system in view of D3, Article 56 EPC 1973.

"Auxiliary request 2"

7. Claim 1 of auxiliary request 2 differs from that of auxiliary request 1 in specifying that the requested resources are described in terms of the identity of the corresponding resource provider, the requested resource quantity and one or more resource "attributes" (such as, for instance, a desired tuner frequency; see the sentence bridging pages 18 and 19 of the description).

7.1 The board considers that these are minor implementation details which the skilled person would employ without exercising an inventive step.

7.2 In its submission of 4 May 2018, the appellant characterised the additional features as "further clarif[ying] the technical meaning of the resource configurations" but did not, beyond that, provide any reasons as to why they established an inventive step. Also during the oral proceedings, the appellant did not argue that the additional features of claim 1 of auxiliary request 2 could change the board's assessment.

7.3 The board therefore concludes that also the subject matter of claim 1 of auxiliary request 2 lacks inventive step, Article 56 EPC 1973.

Order

For these reasons it is decided that:

The appeal is dismissed.