T 2042/13 (Managing power in a computer system/LG) of 4.12.2018

Summary of Facts and Submissions

I. This is an appeal against the decision, dispatched with reasons on 29 April 2013, to refuse European patent application No. 03 018 715.7 on the basis that the subject-matter of the independent claims did not involve an inventive step, Article 56 EPC, in view of the following document:

D1: Yung-Hsiang Lu, Giovanni De Micheli, "Comparing System-Level Power Management Policies", IEEE Design & Test of Computers, IEEE Service Center, New York, NY, US, vol. 18, no. 2, 1 March 2001, pages 10 to 19, XP001058644, ISSN: 0740-7475.

In a section entitled "Further Remarks, not forming part of the Grounds" the examining division cited inter alia the following document as evidence for its assertion in the decision that the use of the status of a queue to determine whether a device was idle or not would have been common general knowledge for the skilled person:

D3: US 5 461 266 A.

II. A notice of appeal and the appeal fee were received on 5 July 2013, the appellant requesting that the decision be set aside and that a patent be granted. The appellant also made an auxiliary request for oral proceedings.

III. With a statement of grounds of appeal, received on 9 September 2013, the appellant submitted amended claims according to a new main request, its sole request. The appellant reiterated the requests that the decision be set aside and a patent granted and the auxiliary request for oral proceedings.

IV. In an annex to a summons to oral proceedings the board expressed doubts whether the subject-matter of inter alia claim 1 involved an inventive step, Article 56 EPC 1973, in view of D1 and the common general knowledge of the skilled person, as exemplified by D3.

V. With a response received on 2 November 2018 the appellant filed amended claims according to an auxiliary request and an amended page of the description.

VI. At the oral proceedings on 4 December 2018 the appellant requested that the decision under appeal be set aside and that a patent be granted on the basis of the main request, filed with the grounds of appeal dated 9 September 2013, or on the basis of the auxiliary request, filed with the letter dated 2 November 2018.

VII. The application is being considered in the following form:

Description:

pages 1 to 2 and 4 to 17, as originally filed,

pages 3 and 3a, received on 12 July 2010, and

page 18, received on 2 November 2018.

Claims:

Main request: 1 to 11, received with the grounds of appeal on 9 September 2013.

Auxiliary request: 1 to 11, received on 2 November 2018.

Drawings:

Pages 1/9 to 9/9, as originally filed.

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

"An apparatus for managing power in a computer system, the apparatus comprising: an operation system (10) configured to set up a power mode of the computer system, wherein the power mode includes at least one of an operating mode and a power down mode; at least one device (40) configured to perform specific functions and operations; at least one device driver (20) configured to control operations of the device, wherein the device driver (20) is configured to change a power mode of the device among the at least one of the operating mode and the power down mode; and a filter driver (100) coupled to the operation system (10), wherein the filter driver (100) is configured to generate a signal to cause the device driver (20) to individually change the power mode of the device to operate in the power down mode when the computer system is in the operating mode, characterized by a queue for storing IRP - input or output request packets - generated by one or more control circuits, wherein the filter driver (100) is configured: if the device is in the power down mode when a packet enters into the queue, to transfer a power control message to the device driver (20) to change the power mode of the device to the operating mode before the first packet requested to be transferred by the operating [sic] system (10) is transferred to the device driver (20); to transfer the requested packet to the device after the power mode of the device is changed to the operation mode; and to set the power mode of the device to the power down mode after the device completes handling the packet when the queue is empty."

IX. Claim 1 according to the auxiliary request differs from that of the main request in the addition at the end of the following expression to the definition of the filter driver: "without using a timer".

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 requirements under the EPC and is consequently admissible.

2. A summary of the invention

2.1 The invention concerns managing power in a computer system having a normal "power on" mode (also known as the "operating" mode) and a "power down" mode having a reduced power consumption. As illustrated in figure 2, the computer system comprises an "operation" system (10) (presumably an operating system), a filter driver (100), a device driver (20), a bus driver (30) and bus-connected hardware devices (40), such as a network adapter, display adapter, disk drive or sound card (see page 1, paragraph [2]). The operation system sends IRPs (Input or output Request Packets, also termed "IO request packets") via the filter driver to the device driver, which then sends Device Power Mode Packets (DPMPs) to each hardware device via the bus driver; see paragraph [4].

2.2 The filter driver provides control of device power states, based on a packet monitoring function which detects that devices are idle. If so, the power mode of that device is set to "power down" mode irrespective of the system power mode set by the operation system, thus reducing system power consumption; see paragraph [15]. Figure 4 illustrates the case of a sound application program (#1-3) running in user mode sending sound data to an IO manager (50) running in kernel mode which then sends IRPs via a filter driver (100) to the sound device driver (45) of a sound card; see page 9, lines 5 to 8, and figure 10.

2.3 A timer can be used to delay the entry of an idle device into the "power down" state. The application discloses embodiments using a timer (see figure 8 and paragraphs [49-51]) as well as one embodiment without a timer (see paragraphs [59-60]). The flow chart of figure 8 illustrates the control of the power mode of a sound card using a timer. When an IRP is received from an application, it is entered (pushed) into a queue (S81), the first IRP causing the device to enter "power up" mode (step S82). As long as IRPs remain in the queue, a timeout timer is reset (step S85), and the device remains in the "power up" mode. Once the last IRP has been popped (removed) from the queue and the timer has timed out, the device is set to the "power down" mode; see paragraphs [50-51].

2.4 Paragraphs [59-60] disclose an embodiment in which no timer is used, which the board understands to mean that, as soon as the last IRP has been popped (removed) from the queue, the device is put into the "power down" mode.

3. The prior art on file

3.1 Document D1

3.1.1 D1 reviews system-level power management policies for extending the operating time of portable battery-powered computers. The review is concerned with "dynamic" measures, meaning those which modify runtime behaviour to save power when the computational load on systems is less. One dynamic measure is to shut down unused (idle) devices such as network interface cards and hard disk drives; see page 10, right column, "Power management". For simplicity, D1 addresses only one device receiving one stream of requests, see figure 1 and page 11, left column, lines 3 to 5. When the device has no requests, meaning that it is "idle", it is put into a low-power state, the transition having a duration of Tsd (the shutdown time). When new requests arrive, the device is woken up, the transition having a duration of Twu (the wake-up time); see page 2, right column, line 12, to page 11, left column, line 1.

3.1.2 As D1 puts it, "power management degrades performance", since a "sleeping" device cannot immediately respond to requests and must first be "woken up"; see page 11, left column, lines 10 to 19. Moreover overall power consumption may not even be reduced by briefly putting a device into "power down" mode, since waking up a "sleeping" device may take extra energy (see figures 6a and 6c), termed an "overhead", and thus use more energy than has been saved. Hence "a device should sleep only if the saved energy justifies the overhead" (see sentence bridging pages 10 and 11), meaning that the idle time should be longer than the "break-even time" Tbe; see box on page 12.

3.1.3 D1 describes the "Advanced Configuration and Power Interface" (ACPI) for controlling the power states of hardware devices, supported by Microsoft Windows and Linux; see page 14, right column, "Implementing policies in Microsoft Windows". The system power states in ACPI consist of a "working state" and three, lower power-consumption, sleeping states; see page 15, right column, lines 3 to 5. In Windows 2000 ACPI commands are issued by creating I/O request packets (IRPs), and a filter driver is inserted between the Windows kernel and a device driver, the filter driver passing, adding, deleting or changing messages between the device driver and the Windows kernel; see page 15, left column, lines 2 to 9. The filter driver can create a new IRP, termed a "power IRP", to change the power state of a device; see page 15, "Change Power States".

3.1.4 D1 classifies power management policies into three groups: "Time-out", "Predictive" and "Stochastic" (i.e. randomly determined); see page 12, right column, line 10, to page 14, left column, line 23. "Time-out" policies assume that, if a device has been idle for a certain time, three minutes being a common choice, this being detected by a timer timing out, it will remain idle for at least Tbe, meaning that power will be saved by putting the device to sleep when the timer times out; see page 12, right column, lines 17 to 25, and page 14, right column, lines 7 to 14 ("Timer generation"). As D1 puts it, a timer is used "to create an event in the future"; see page 14, right column, lines 8 to 9.

3.1.5 The section entitled "Timer generation" also mentions policies that do not require timers, for instance the stochastic "continuous-time Markov models", described in the paragraph bridging pages 13 and 14. According to this paragraph, "With these models, there is no need to evaluate the appropriate power states periodically. Instead, the arrival and service of requests are the events that trigger state transition decisions."

3.2 Document D3

According to its abstract, D3 concerns computer power management by reducing the clock frequency of idle devices. Whether or not a device is idle can be determined by looking inter alia at its input queue; see column 12, lines 9 to 12.

4. The relationship between the main and the auxiliary requests

Claim 1 of the main request covers not only the embodiments using a timer but also the embodiment without a timer, whilst the expression in claim 1 of the auxiliary request "without using a timer" restricts its subject-matter to only the embodiment without a timer. It follows that, if the subject-matter of claim 1 of the auxiliary request lacks inventive step, then so too does that of the main request.

5. Inventive step, Article 56 EPC 1973, auxiliary request

5.1 According to the appealed decision, the apparatus according to claim 1 differed from the disclosure of D1, the closest prior art document on file, in that:

i. the apparatus comprised a queue for the IRPs and

ii. the operating mode was set before a first request was transferred from the queue and the power down mode was set after completing handling a packet when the queue was empty.

5.2 The technical effect of difference "i" was to queue outstanding requests, thus solving the problem of buffering requests, whilst that of difference "ii" was to set the operating mode before a first request was transferred from the queue and to set the power down mode after completing handling a packet once the queue was empty. This solved the problem of determining when the device was idle.

5.3 According to D1, a device was busy when it had requests and was otherwise idle, D1 referring to a stream of requests, thus disclosing the possibility of multiple outstanding requests. D1 also mentioned that there was a delay before a device "woke up", implying that requests for that device had to be buffered during this interval. It was usual to buffer multiple requests in a queue to maintain their order. Moreover the use of the status of an input queue to indicate whether a device was idle or not would have been well known to the skilled person. Hence claim 1 lacked inventive step.

5.4 In a section entitled "Further Remarks, not forming part of the Grounds" the examining division cited inter alia D3 as evidence proving its assertion in the decision that the use of the status of a queue to determine whether a device was idle would have been common general knowledge for the skilled person.

5.5 It is common ground between the appellant and the board that the subject-matter of claim 1 differs from the disclosure of D1, in particular the policies not requiring timers (see page 14, right column, lines 24 to 28, and page 13, right column, line 15, to page 14, left column, line 4), in the following features:

a. a queue for storing IRP - input or output request packets generated by one or more control circuits,

b. wherein the filter driver is configured: if the device is in the power down mode when a packet enters into the queue, to transfer a power control message to the device driver to change the power mode of the device to the operating mode before the first packet requested to be transferred by the operation system is transferred to the device driver; to transfer the requested packet to the device after the power mode of the device is changed to the operation mode; and to set the power mode of the device to the power down mode after the device completes handling the packet, without using a timer, when the queue is empty.

5.6 It is also common ground between the appellant and the board that, as the appellant stated at the oral proceedings, the skilled person would have known at the priority date that the status of a queue could be used to tell whether a device was idle or not. The appellant has however argued that the invention lies in the filter driver using the status of the queue to determine that an event has occurred, as set out in difference feature "b". This approach had the potential to reduce the computing load due to power management on a computer system, some computer systems having a relatively low computing capacity at the priority date. It is also common ground that, although D3 discloses using the status of a device input queue to tell whether a device is idle or not, it does not disclose how this information should then be used.

5.7 The appellant has challenged the two technical problems formulated in the decision and argued that the invention solves the objective technical problem of providing an apparatus which can manage the power modes of the device in a simple and economical way which obviates the need for a timer. According to the appellant, the use of the queue reduces the shutdown delay when a device enters "power down" mode and the wake-up delay when a device enters "power up" mode. The claimed solution suffered less from the shutdown and wake-up delays and/or energy overhead than the D1 system.

5.8 The board questioned whether the queue reduced the energy overhead or the shutdown and wake-up delays when a device entered or left "power down" mode. In the board's view, these quantities depended on the device parameters rather than on the presence of a queue. The delays were caused by the unavailability of the device itself (see figure 1 in D1), and the energy overhead was device-dependant; see the Hitachi disk drive compared to that from Fujitsu in figure 6, discussed on page 16, "Device parameters". In the board's view, the queue solved a more general problem, which arose even if the device was always "awake", namely to avoid requests being lost if they arrived at a rate higher than that at which the device could process them. Equally, the queue allowed the device to maintain a constant throughput rate even if requests temporarily arrived at a lower rate. Hence the board finds that the claimed solution does not suffer less from the shutdown and wake-up delays and/or energy overhead than the D1 system, since these delays depend on the individual hardware devices, which are not changed by the invention.

5.9 The appellant has argued that the skilled person starting from D1 would never have considered changing the power states whenever the device was idle in view of the associated delay and/or energy overhead. The board is not convinced by this argument. As D1 states on page 12 (see box "Break-Even Time"), in order to achieve a net energy saving, a device should only be put into a low power state if the predicted idle time is longer than the break-even time Tbe. Hence the skilled person is taught the circumstances under which changing the power state yields a net energy benefit. Under these circumstances the skilled person would consider changing the power state.

5.10 According to the appellant, D1 (see column 11, left column, lines 3 to 5) is limited to a single device, whilst the invention involves a plurality of devices. The board is of the opinion that this does not constitute a difference between the subject-matter of claim 1 and the disclosure of D1, since claim 1 sets out "at least one device" and thus covers the case of a single device.

5.11 Regarding the objective technical problem, the board, like the appellant, does not accept the first partial problem formulated in the decision because, by using the term "buffering", it points to the claimed solution of using a queue. The board finds that the skilled person realizing the apparatus known from D1 and "filling in the gaps" would have been confronted by two partial problems:

i. What to do with IRPs that arrive for a device while it is not "working" (i.e. "sleeping", "going to sleep" or "waking up"). This partial problem is solved by feature "a".

ii. Determining whether or not a device is "idle". This partial problem is solved by feature "b".

5.11.1 Difference feature "a" (use of a queue) would have been obvious to the skilled person starting from D1. Solving the first partial problem using a queue as an input buffer to store incoming packets in order would have been a matter of common general knowledge for the skilled person, such a use of a buffer being, for instance, known per se from D3; see column 12, lines 9 to 12. The board understands from the reference in D1 to a "stream" of requests (see page 11, left column, lines 3 to 5) that the order of the requests must be preserved. The skilled person would have known that a queue achieves this.

5.12 Hence inventive step depends on feature "b". This feature uses the queue status (empty/not empty) to determine whether the device is idle and thus detect events necessitating a change in the device power mode, D1 already disclosing policies in which "the arrival and service of requests are the events that trigger state transition decisions"; see sentence bridging pages 13 and 14. D1 does not specify the events. It does however disclose the use of power IRPs, anticipating the "power control messages" in claim 1. The power IRPs control the power state of the device. The board regards putting an idle device into a "power down mode" and putting it into an "operating mode" when it has work to do as a usual matter of design.

5.13 The board can see no synergy between features "a" and "b" and agrees with the appellant that feature "b" is technically independent of feature "a", since feature "a" could exist on its own without feature "b". The appellant has argued that there is a synergy, since, starting from difference feature "b", feature "a" is mandatory. The board is not persuaded by this argument, since it does not change the fact that the skilled person could add feature "a" alone.

5.14 The board concludes that the subject-matter of claim 1 of the auxiliary request lacks inventive step, Article 56 EPC 1973. Hence, as explained above, the subject-matter of claim 1 of the main request also lacks inventive step, Article 56 EPC 1973, for the same reasons.

Order

For these reasons it is decided that:

The appeal is dismissed.