T 0855/14 (Portable computer power management/HEWLETT-PACKARD) 28-06-2021

1. The admissibility of the appeal

In view in particular of the facts set out at points I and IV above, the appeal fulfills the admissibility requirements under the EPC and is consequently admissible.

2. The admittance of the amended claims

The amended claims received on 21 April 2021 had been amended in response to the clarity objections under Article 84 EPC raised in the annex to the summons of 11 March 2021, and their scope was not significantly changed. As the amendments were not extensive and their effect could be readily ascertained, the board admitted the amended claims, Article 13(2) RPBA 2020 (see also T 1294/16, point 18.4). Nonetheless, the decision was ready for decision in written proceedings, Article 113(1) EPC and Article 12(8) RPBA 2020.

3. A summary of the invention

3.1 The application relates to a power management system for a portable computer (such as a laptop or cellular telephone; see page 2, lines 3 to 8) powered by a battery having a limited life; see page 2, lines 9 to 13. The invention relates to achieving a desired length of battery life by reducing the functionality of the computer accordingly.

3.2 As shown in figure 1, the power management system (10) comprises a power management module (30), a power monitor (32) (for estimating the remaining battery life; see [10]), a database (62) containing hardware and software elements, for instance a graphics application (48) or a drive device (42), classed according to priority into "low", "medium" and "high" (see [14]) and stored battery duration information (64) comprising a requested duration (80) and an estimated duration (82); see [20].

3.3 As shown in figure 2 (see [45]), given a particular requested duration, for instance the duration of a flight (see [24]), the power management system turns off the lowest priority elements first, working upwards (see steps 212, 220, 224 and 230), until the power monitor determines that the estimated operating duration is greater than or equal to the requested duration; see [10] and figure 2; step 212.

3.4 As illustrated in figure 3, the priorities of certain elements can change from their default values, for instance the game playing function on a cellular phone device may be temporarily increased if the user selects this function; see [15] and step 310. This may cause an element with a lower priority, for instance the device camera, to become inoperable (see [17]), making power available for the game playing function. The priority of the game playing function returns to its default value once the user closes the game; see [17], last sentence.

3.5 The claims set out the priority of one power-consuming application being increased when the application is initiated, causing another power-consuming application to become inoperable, and returning the priority of the opened application to its default value when it is closed.

4. The board's understanding of the invention

4.1 An important question in this case concerns whether a "power-consuming software application", as set out in the claims, covers the hardware devices disclosed in D1 and D4. For example, D1 discloses (see figure 6) a floppy disk drive (FD), hard disk drive (HDD) and CPU (Central Processing Unit), while D4 discloses a "phone operating module", "PDA operating module" and "digital camera operating module"; see [25]. Clearly, "software", being a list of instructions, cannot itself "consume power". However the application discloses software applications which cause system hardware, such as the CPU, to consume power when run; see the graphics application 48 or the e-mail application 50 in paragraph [11]. Claim 1 as originally filed set out "software applications that execute with power-consuming elements in the portable computer", thus being directed to software with associated hardware, such as a drive device 42, audio component(s) 44 or a display controller 46; see [11]. Present claim 1 has been restricted to set out a first and a second "power-consuming software application". Construing this expression in the light of the description, the board understands claim 1 to cover both software applications involving only the CPU and software applications which are associated not only with the CPU but also with further power consuming hardware elements, such as a drive device, audio components or wireless components.

4.2 As the hardware devices known from D1 and D4 implicitly have associated software in the form of drivers and other applications, the board understands the expression in claim 1 "power-consuming software application" to cover the implicitly disclosed software in D1 and D4.

4.3 In the context of the application, the available battery power is distributed to the various computer modules in two steps. In a first step a priority is assigned to each module. Then, in a second step, power distribution decisions are made, based on the relative priorities. Consequently, should the priority of one module competing for power increase, then this will have the same effect on decision-making as decreasing the priority of the other modules competing for power.

5. Clarity and support, Article 84 EPC

5.1 In the annex to the summons the board argued that it was unclear why claim 1 set out the second power-consuming software application having a variable priority level, since the claim only set out the priority level of the first application being changed. Claim 1 has now been amended, based on paragraphs [15-17] of the description, to state that the "opened" power-consuming software application is moved to a higher priority level, no such change being set out for the "other" power-consuming software application, thus overcoming this objection.

5.2 Whilst claim 1 sets out moving an opened software application to a higher priority level, a change relating to the "first step", defined above, it does not set out the steps involved in achieving the effect of the other software application becoming inoperable, a change relating to the "second step", defined above. The claim covers any method of carrying out the "second step" which causes the other application to become inoperable, whilst figure 2 and paragraphs [45-51] only set out a particular method of suspending elements with progressively higher priorities (220,224,230) until the requested duration is no longer greater than the estimated duration. In view of the conclusion regarding inventive step, set out below, the question of whether the claims are supported by the description can remain undecided.

6. The prior art on file

6.1 Document D1 (US 5 915 120 A)

6.1.1 D1 concerns a battery-operated information processing apparatus, such as a notebook (see column 4, lines 22 to 24, and figures 13 and 14A), in which parameters such as the CPU clock rate and backlight brightness are adjusted (see column 6, lines 58 to 67) to make the predicted operable time exceed the desired operating time; see figure 4 and column 1, lines 9 to 59. The user enters the desired operating time using a slider switch next to the keyboard of the laptop; see figure 14B and column 15, lines 3 to 13. A preferential order table, shown in figure 8, contains the priorities of the various modules of the apparatus; see column 2, lines 4 to 13, column 9, lines 22 to 56, and figure 34. D1 discloses hardware modules, such as the CPU, HDD and I/O, it being implicit that associated software is also present and that a plurality of software applications run on the CPU.

6.1.2 It is common ground between the board and the appellant that D1 (see figure 8) discloses elements of the computer having "default", meaning "preset", priority levels.

6.1.3 Hence, in the terms of claim 1, D1 discloses a method of operating a portable computer (see column 4, lines 22 to 24), the portable computer comprising a database (see figure 8; preferential order table) having information associated with a prioritization of power-consuming software applications of the portable computer, wherein a first power-consuming software application and a second power-consuming software application have a variable priority level (see figures 6 and 8), wherein a default priority level of the first and a second power-consuming software applications is a low priority, the method comprising: receiving a desired time to operate the portable computer (see figure 14B) while the portable computer (10) is powered by a battery (16); estimating a battery power duration time for the portable computer to operate by the battery (see column 7, lines 26 to 33) and comparing the battery power duration time with the desired time; see figure 4; 404, 405.

6.1.4 The appellant disputed in the submission of 21 April 2021 whether D1 disclosed applications which are to be executed being controlled by the power management system. The board is not persuaded that this is a difference, since, as stated in the annex to the summons of 11 March 2021, the hardware devices known from D1 and D4, which both concern power management, implicitly have associated software in the form of drivers and other applications which fall under the term in the claims "power-consuming software application". These implicitly disclosed software applications are controlled by the power management system.

6.1.5 In view of the above analysis, the board takes the view that the subject-matter of claim 1 differs from the disclosure of D1 in the following features:

a. when the battery power duration time is less than the desired time, in response to a user opening one of the first and second power-consuming software applications, moving the opened power-consuming software application to a higher priority level so that another power-consuming software application becomes inoperable in order to support use of the opened power-consuming software application, and

b. in response to a user closing the opened power-consuming software application, returning the priority level associated with the opened power-consuming software application to its default priority level.

6.2 Document D4 (US 2003/0149904 A1)

6.2.1 D4 relates to power management in battery-powered portable electronic terminals, such as a notebook computer; see [6], line 2 and [5], line 5. As shown in figure 1, such a terminal comprises several modules (50, 60, N), for instance a main module with a PDA (Personal Data Assistant) function with an attached auxiliary module with a telephone function. Other possible modules are a LCD (Liquid Crystal Display) operating module, a radio module and a backlight module; see [19], lines 6 to 8. Modules can be classified according to their duty cycle: continuously operating, cyclically operating (such as a radio module) and those waiting for an "external request", for example user input; see [19], lines 13 to 24.

6.2.2 According to paragraph [28], some module priorities are predefined and cannot be changed by the user. In other cases a priority rank is accorded to each module based on user choices; see [17]. The total power that would be required to turn on all modules is then determined. Thereafter, at regular intervals, said total is compared to the currently available power. If the currently available power is less than said total then power consumption is reduced by providing power to at least one module depending on its priority rank; see figures 3a and 3c and [9 and 31-34].

6.2.3 The terminal comprises a menu of power management options (see [21]), giving the user the choice between automatic priority setting and user priority setting and the choice between "time priority" (allowing an individual module to operate as long as possible; see [23], lines 1 to 5) and "function priority" (applying the priorities to enable as many modules as possible to operate); see [23], lines 5 to 9.

6.2.4 Table 1 on page 2 shows the priority ranks of a device having a phone module (priority 1), a PDA module (priority 2) and a camera module (priority 3). Here the priority ranks are all different. It is also possible to allocate modules equal priorities, as shown in table 3 on page 3, in which the PDA has priority 1 and both the phone and the camera share priority 2. Given modules of equal priority, the user can set a "lend power" flag, meaning that that module can be turned off to support a module in the same rank; see [27, 35], lines 6 to 11. In table 3 this means that the phone can be turned off to support the camera. Similarly, when a module operating at an external request needs to turn on to service the request, modules with a lower priority or the same priority with "lend power" flag set (see figure 3c; steps 135 and 141) are temporarily turned off while the external request module is active, then being turned on again; see [30], last 11 lines, [34] and figure 3c.

6.2.5 The board takes the view that the camera and phone modules in D4 (see table 3) not only comprise hardware but also an associated software application to operate that hardware. The board regards the camera and phone in table 3 as each having a corresponding power-consuming software application. In D4, as in the invention, power is distributed between modules based on their relative priorities. Hence the relative priority of the camera is variable because that of one of its competitors for power, the phone, varies due to the "lend power" flag. The table of priorities referred to in paragraph [25], last two lines, qualifies as a database of prioritization information.

6.2.6 Hence, in the terms of claim 1, D4 discloses the features of

i. when the battery power duration time is less than the desired time, in response to a user opening the one of the first and second power-consuming software applications (camera), moving the opened power-consuming software application to a higher priority level so that another power-consuming software application (phone) becomes inoperable in order to support use of the opened power-consuming software application (camera), and

ii. in response to a user closing the opened power-consuming software application (camera), returning the priority level associated with the opened power-consuming software application to its default priority level; see [35], last four lines.

6.2.7 The appellant has argued that D4 does not disclose features "a" and "b" because D4 (see table 3) uses a "Lend Power" flag to determine which module should, if need be, lend power to another module of equal priority rank. The board finds that this argument does not succeed, since claim 1 does not exclude the use of "Lend Power" flags, as known from D4, the flag has the effect of increasing the priority level of the recipient module, the "first step" discussed above at point 4.3. The priority of the camera module is thus temporarily increased from its default priority rank of 2 when it "borrows" power from the phone module; see D4; table 3 and [30], last 11 lines.

6.2.8 Hence the board concludes that features "a" and "b" are known from D4 (see [30], last 11 lines) in which, due to the "Lend power" flag of the phone module, the camera module operating at an external request receives power which would otherwise flow to a module of equal priority, namely the phone module (difference feature "a"). This means that the priority of the camera module is temporarily increased, as stated in the last sentence of [30], but returns to its previous state once the camera module finishes its operation (difference feature "b"). The appellant has argued that D4 does not disclose changing priorities, but the board takes the view that this change is the effect of the "Lend power" flag in the case where power is being supplied to a module of the same priority rank.

7. Inventive step, Article 56 EPC

7.1 According to the appealed decision, the subject-matter of claim 1 did not involve an inventive step starting from D1, the problem to be solved being how to implement dynamic prioritisation among power-consuming software applications. According to the reasons for the decision, it was known from D4 that external requests, such as user input ([19]), could override default settings. In [30], for example, D4 disclosed an external request resulting in power to a module "among the modules having the same priority rank with the operating module at an external request" being temporarily suspended, the module becoming inoperable. D4 (see [35]) described the user inputting a request to operate a camera module which resulted in suspending the power supply to the phone operating module having the same priority rank 2 (the low priority in table 3). Since table 3 was stored in memory ([35]), its values were used as default priority levels. [35] further disclosed that, when the operation of the camera module was completed, the controller returned power to the phone operating module, implying that the priority of the camera module returned to its default low priority level. The claimed dynamic prioritisation had the same technical effect as the override feature of D4, particularly in the case of two priority levels as in table 3. Hence the claimed dynamic prioritisation was known from D4.

7.2 The appellant argued in the submission of 21 April 2021 that the claimed subject-matter involved an inventive step in view of D1 alone and the combination of D1 and D4. D1 did not mention the power management system controlling the applications to be executed or changing the priority levels of the controlled elements. The objective technical problem was to improve the control of power consumption of the portable computer. It was not obvious for the skilled person solving this problem to arrive at the invention.

7.3 As the appellant has stated, "The problem with the approach described in document D1 is that the priority scheme is fixed ..." Hence the board takes the view that the objective technical problem starting from D1 is, as the appellant has argued, to improve the control of power consumption of the portable computer. The skilled person would have recognised that D4 teaches a solution to this problem by adding difference features "a" and "b" to allow power to be shared between elements of the same priority rank, thus arriving at the subject-matter of claim 1.

7.4 Hence the subject-matter of claim 1 lacks an inventive step in view of the combination of D1 and D4.