T 2135/14 (Upgrading an application program/NTT) 25-10-2017

Reasons for the Decision

The invention

1. The application relates to upgrading software on a mobile device, typically a mobile phone, in such a way that bandwidth is not wasted on applications which are no longer used and the user is saved the bother of having to actively check for upgrades (see paragraph bridging pages 1 and 2, and page 2, penultimate paragraph).

1.1 As a solution, the invention proposes that applications are upgraded whilst in use. It is disclosed that upgrades are to take place when "specified commands are executed" (see paragraph bridging pages 2 and 3), but the description does not explain what these "specified commands" are.

1.2 The application to be upgraded is first suspended (see figure 8, SB1). It is then determined whether the "upgrade [...] can be completed" (see SB2). It is disclosed that this can be predicted if the "radio field intensity" or the remaining battery power is sufficiently high (i.e. above a "threshold"; see page 13, lines 8-18 et seq. and page 15, lines 14-23). Present claim 1 is limited to the former alternative. It is further disclosed that the upgrade may be terminated if the user does not give his confirmation (page 14, lines 5-7). The upgrade is only started if it is expected that it "can be completed" (SB4). If not, or if the upgrade fails for other reasons (SB5), the old program is resumed (SB3).

The prior art

2. D1 discloses the Mobile Information Device Profile MIDP (see page 1), which defines a set of interfaces for mobile Java applications (MIDlets; see page 431 et seq., chapter 12). D1 deals inter alia with user-initiated over-the-air provisioning of MIDlets (see page 11 et seq., esp. section 1 of chapter 2). A MIDlet can "start, pause, or destroy itself" (page 431, penultimate paragraph; pages 439-440, MIDlet states). Before a MIDlet is updated, it "MUST" be stopped; other MIDlets "MAY" have to be stopped, too (see page 15, section "MIDlet Suite Update"; pages 447-448, platformRequest; see esp. page 447, last paragraph). D1 discloses that an upgrade may fail for various reasons (including, for instance, insufficient memory or loss of service) which are reported by means of a "status code" in a status report (see page 16, paragraphs 2, 7 and 8, and the table bridging pages 16 and 17).

The issue to be decided

3. Claims 1 and 7 differ from D1 in two ways:

(a) They distinguish between terminating an application program and merely suspending it so that it can be resumed, whereas D1 discloses "stopping" and "destroying" an application program without mentioning the possibility of resuming it, and they require an application program to be suspended before being upgraded.

(b) They specify that after suspension it is determined whether the radio field intensity is larger than a threshold. Only if it is indeed larger is the upgrade started; if it is not, the suspended application program is resumed.

3.1 This largely corresponds to the differences identified in the decision under appeal (page 5, penultimate paragraph, and page 8), and the appellant has not contradicted this analysis either (see grounds of appeal, point 3.1).

3.2 The examining division took the view that these two features were merely juxtaposed and that their inventive merit could therefore be assessed separately, and found that difference (b) in particular was "an implementation detail consisting of an arbitrary choice of one or more possible failure scenarios out of a large number of readily foreseeable [...] scenarios" (see the decision, page 8, items a) and b)).

3.3 The appellant challenged both findings. It argued that there was a synergy between suspending the application program before the upgrade and the subsequent checking of the radio field intensity (see grounds of appeal, point 3.5), because suspending any potential use of "wireless communication resources" by the application program being upgraded made more reliable the "a priori consideration of the radio field intensity for determining whether the download can be completed" (see point 3.4, last paragraph). And it took the position that claim 1 was inventive over D1 by virtue of the two features, especially because D1, while mentioning several possible "failure scenarios", did not consider any "environmental factors associated with the wireless nature of the communication" or, in particular, "the radio field intensity" (see point 3.6).

3.4 Furthermore, the appellant argued that the examining division had incorrectly construed the claimed "execution means for executing [an] application program" as an execution means merely "suitable for" execution rather than, as it should have done in view of decision T 410/96, as an execution means "adapted for" execution (see the decision, page 3, third paragraph from the bottom, and the grounds of appeal, point 2).

The board's position

4. The board agrees with the appellant in principle that the "exe­cution means for executing" must, following T 410/96 (esp. reasons 6), be construed as being "adapted for" such execution rather than as merely being "suitable for" it, as the examining division stated. In the present case, however, this is not a crucial difference, because the "communication terminal device" according to D1 is clearly not only suitable but also adapted for running a program and thus any of its commands, irrespective of whether the latter are expressly specified or not.

5. In the annex to its summons to oral proceedings, the board expressed the view that claims 1 and 7 were unclear, Article 84 EPC 1973, because the "execution means" (and the corresponding "executing" step) seemed to relate to execution of an application program only "if [...] directed by a user". After amendment, the execution means and steps are now defined to be, unconditionally, "for executing an application program" and "specified commands". The board's objection has thus become moot.

6. The board also raised a clarity objection because claims 1 and 7 failed to specify when the radio field intensity was measured, and an objection under Article 123(2) EPC because they also failed to specify that the upgrading was started if and only if the detected radio field intensity was above the threshold. As claims 1 and 7 now specify both missing features, these objections too have become moot.

7. As regards the alleged synergy between features (a) and (b), the board takes the following view.

7.1 Claims 1 and 7 refer to radio field intensity, i.e. the strength of the relevant signal.

7.2 It is well known that signal strength is related to bandwidth. Reduced signal strength increases the risk of transmission failure and protective measures against failure require some bandwidth.

7.3 Obviously, if the application program being upgraded consumes "wireless communication resources" the bandwidth available for other purposes is reduced. However, the signal strength is not substantially affected. Therefore, the same radio field intensity will be determined irrespective of whether the application program being upgraded is suspended before such determination or only thereafter.

7.4 In its letter of 21 September 2017, the appellant conceded this point (see page 3, point 3, paragraphs 1 and 2), but argued that synergy existed nonetheless, because suspending the application program according to (a) rather than stopping it made it possible to resume it if the upgrade was not initiated due to an in­sufficient radio field intensity according to (b) (see the same letter, paragraph bridging pages 3 and 4).

7.5 The board is not convinced. It notes in particular that anticipation of download failure due to a low radio field intensity would also work without suspension, namely if the application program to be upgraded was not stopped until the radio field intensity could be measured and it was decided to start the upgrade. And, conversely, the advantage that a suspended program can be resumed if necessary is independent of the criterion relied upon to decide whether an upgrade can be started.

7.6 The board therefore agrees with the decision under appeal that there is no non-trivial synergy between features (a) and (b) and that, hence, their inventive merit can be assessed separately.

8. On the question of inventive step, the board takes the following view.

8.1 Re (a). In the board's view it is obvious for the skilled person - and also known from D1 (see page 16, paragraph 2) - that upgrades may fail and that, in this situation, execution of a program that has been "stopped" or "terminated" for an upgrade may have to be resumed. Furthermore, the board considers it to be straightfor­ward for the skilled person to provide this option in the context of D1.

8.2 Re (b). The board considers that feature (b) solves the technical problem of avoiding upgrade failure.

8.2.1 The board notes that low radio field intensity does not imply that an upgrade cannot be completed at all. It may just take longer to complete, which may well be acceptable to a user. And radio field intensity might vary in an unpredictable way. Nonetheless, the board accepts that the signal strength allows a reasonable prediction of whether the upgrade will succeed within an acceptable time frame, or at all.

8.2.2 D1 mentions the possibility of upgrade failure for a number of reasons, but does not explicitly mention low signal strength as one of them (see esp. the table bridging pages 16 and 17). Moreover, it does not discuss any means of dealing with an upgrade failure when it occurs, or of anticipating failure (apart from mentioning that "status reports" may have to be resent; see page 16, paragraphs 2, 7 and 8).

8.2.3 In the decision (see page 8), it is suggested that low "radio field intensity" is one of several commonly known parameters that might cause an upgrade to fail. Furthermore, it is stated that these "failure scenarios" were readily foreseeable so that resuming the old program and not carrying out an upgrade was an "arbitrary choice of [...] readily foreseeable [failure] scenarios".

8.2.4 It is true in principle that an upgrade may fail for many reasons. However, the board disagrees that they are necessarily foreseeable. While, for instance, it is clear that the download of the new program - and thus the upgrade - must fail if the remaining working memory is too small, it may not be foreseeable when and for how long a server might become unreachable. Also, while it may be obvious ex post to determine that an upgrade failure was due to insufficient signal strength, this alone does not, in the board's view suggest that the initial signal strength should be used as an indicator for the likely success of an upgrade.

8.2.5 The board concludes that feature (b) would not have been obvious to the skilled person from D1 and common general knowledge alone.

Remittal to the examining division

9. As a consequence, the decision under appeal must be set aside.

9.1 The board notes that feature (b) was not specifically contained in the claims as originally filed. However, the feature of determining whether an upgrade "can be completed" was contained in original claim 3. Given that the description is fairly short and discloses only a small number of clearly identifiable instances of that determination, the board considers that feature (b) at least should have been searched (see T 789/07, headnote). The board is not in a position to decide whether it actually was, but notes that the examining division did not question that feature (b) was covered by the search when admitting, considering and deciding on the third auxiliary request.

9.2 However, in view of the fact that a number of further documents (D2-D7) were cited during examination but neither discussed with the examining division nor dismissed as irrelevant, the board considers that inventive step has not yet been exhaustively discussed with the examining division.

9.3 Therefore, the board exercises its discretion under Article 111(1) EPC and remits the case to the examining division for further prosecution.