T 1379/12 (Software versioning on mobile devices/QUALCOMM) of 9.9.2016

Summary of Facts and Submissions

I. This appeal is against the decision of the examining division refusing European patent application No. 04796815.1, with publication number EP 1 678 931 A.

The refusal was based on the ground of lack of inventive step starting out from document

D1: US 6 031 830 A.

II. In the statement of grounds of appeal, the appellant requested that the decision under appeal be set aside and that a patent be granted on the basis of claims 1 to 15 as filed during the oral proceedings before the examining division on 29 November 2011, and submitted arguments in support. Oral proceedings were conditionally requested.

III. In a communication annexed to a summons to oral proceedings, the board, without prejudice to its final decision, raised objections under Article 52(1) EPC in combination with Article 56 EPC (inventive step) in respect of the subject-matter of claims 1, 5, 7, 11 and 15.

IV. With a letter dated 3 August 2016, the appellant filed a substantive response. Further, with a letter dated 9 August 2016, the appellant informed the board that it would not be attending the oral proceedings and requested a decision according to the state of the file.

V. Oral proceedings were held on 9 September 2016 in the absence of the appellant (cf. Rule 115(2) EPC and Article 15(3) RPBA).

On the basis of the written submissions, the board understood the appellant to be requesting that the decision under appeal be set aside and that a patent be granted on the basis of claims 1 to 15 as filed on 29 November 2011.

At the end of the oral proceedings, after due deliberation, the chairman announced the board's decision.

VI. Claim 1 reads as follows:

"A method of handling actions for a wireless device (12, 18, 20, 22), comprising:

receiving (505) at said wireless device (12, 18, 20, 22), over a network (14, 26, 40), a remote action list version number, the remote action list version number is associated with a remote action list, the remote action list comprising actions to be performed by the wireless device (12, 18, 20, 22) and related parameters wherein the actions are install, delete or upgrade and the parameters indicate the applications to be installed, deleted or upgraded, wherein the remote action list is associated with the wireless device (12, 18, 20, 22);

determining (510) whether the remote action list version number is different from a local action list version number;

sending (520), over a network (40), a request for the remote action list in response to determining the remote action list version number is different from the local action list version number; and

receiving (525), over a network (40), the remote action list."

Reasons for the Decision

1. Claim 1 - inventive step (Articles 52(1) and 56 EPC)

1.1 D1 is taken as representing the closest prior art, since it relates to a method in which software upgrades are provided via wireless communication to a mobile device upon detecting that the software currently in the mobile device is outdated (cf. column 1, lines 7 to 12). The method of D1 addresses a problem of a hitherto known method for updating operating software on a mobile device, in which each program of the operating software was downloaded periodically from a host computer to the mobile device, namely that frequently time was wasted due to updating the mobile device operating software with the same software version as that already in the mobile device (cf. column 2, lines 8 to 26).

In order to detect outdated software, in the method of D1, the mobile device compares the version of the operating software stored on it with the version of the operating software stored in the host computer (column 6, lines 21 to 25). For this purpose, a "Package Definition Packet" containing details of a given software package is transmitted to the mobile device (column 11, lines 15 to 19). The mobile device, based on the received "Package Definition Packet", determines whether its software is outdated and, if necessary, downloads a new version (column 11, lines 36 to 51).

More specifically, the "Package Definition Packet" (cf. column 11, lines 15 to 19, and Fig. 7(d)) includes the contents of a "package definition file" (cf. Fig. 5a-d) which includes a package name, identifying the particular package of operating software which is to be utilised by the mobile terminal (column 8, lines 28 to 32), a unique version identifier of that package (column 8, lines 37 to 44), an action to be performed (e.g. "replace" (Fig. 5b)), a list of file names, and further information about of each of these files ("Mobile Terminal Path", "Host Path", "Type", "ROM/RAM").

The "Package Definition Packet" is transmitted to the mobile terminal, where, subject to a comparison between the version identifier and a locally stored version number, the download and installation of the files listed in the "package definition file" is triggered (column 11, lines 33 to 51).

The version identifier stored in the package definition file is modified each time at least one of the listed files is added, deleted or modified (column 8, lines 44 to 48). The board notes that the actions to be performed by the mobile terminal imply installing and upgrading since, if an existing file is replaced with a listed file, downloading the new version of this file and replacing the local file by installing the downloaded file result in the local file being upgraded.

1.2 According to present claim 1, the "remote action list" comprises actions to be performed by a wireless device and related parameters, wherein the actions are an install, an upgrade or a delete action and wherein the parameters indicate the applications to be installed, upgraded or deleted. Further, the "remote action list version number" is associated with the "remote action list".

From the above, it follows that the "version identifier" in the package definition file of D1 corresponds to the "remote action list version number" referred to in claim 1 and that the actions and the further information about of the files as listed in the packet definition file of D1 correspond respectively to the "actions to be performed by the wireless device" and the "related parameters" in the "remote action list" as referred to in claim 1. It follows that the package definition file of D1 includes both the "remote action list version number" and the "remote action list".

1.3 Applying the above understanding, D1, using the language of claim 1, discloses a method of handling actions for a wireless device, comprising:

receiving at said wireless device, over a network, a remote action list version number ("version identifier", column 11, lines 25 to 35), wherein the remote action list version number is associated with a remote action list (column 8, lines 40 to 44), the remote action list comprising actions to be performed by the wireless device and related parameters ("replace", "file names", "type"), wherein the actions are install, delete or upgrade (column 8, lines 44 to 48) and the parameters indicate the applications ("file names") to be installed, deleted or upgraded, wherein the remote action list is associated with the wireless device (column 8, lines 23 to 32);

determining whether the remote action list version number is different from a local action list version number (column 11, lines 36 to 41);

and receiving, over a network, the remote action list ("Package Definition Packet", column 11, lines 25 to 35).

1.4 The method of claim 1 thus differs from the method disclosed in D1 in that the remote action list is requested in response to having determined that the remote action list version number is different from a local action list version number, whereas in D1 the remote action list is already received together with the remote action list version number.

A technical advantage which is thereby achieved is that the remote action list is downloaded only if really necessary, namely if the remote action list version number is different from the local action list version number and, hence, the operating software needs to be upgraded.

1.5 Starting out from D1, the technical problem underlying the subject-matter of claim 1 may thus be seen in further reducing the amount of data transmitted for those cases in which the software of the mobile terminal does not need to be modified.

The appellant argued that this formulation of the technical problem contained a pointer to the solution, because it explained that the amount of data could be reduced and under which circumstances this was possible. The correct technical problem would rather be further improving the efficient use of network resources in connection with modifying applications at the wireless device.

The board is not convinced by this argument for the following reasons:

As set out above, D1 already distinguishes between cases in which the operating software of the mobile terminal, i.e. the wireless device, needs to be modified and those cases in which no update is required, in that in the latter cases less data is transmitted than was achieved in the prior art acknowledged in D1, by no longer unnecessarily downloading the same software version (see above point 1.1). The board notes that formulating the problem as further reducing the amount of data transmitted is, in any case, fully in line with the general aim in the field of data telecommunications of using network resources as efficiently as possible. The formulation of the problem as set out above by the board does not therefore contribute to an inventive step.

1.6 Since D1 teaches that a reduction in the amount of data transmitted can be achieved by conditionally downloading the operating software, namely subject to a comparison between a received version number and a locally stored version number of the operating software, it would be obvious to the skilled person to consider that, if a further data reduction is desired, any further data which is not required for the comparison of the version numbers need not be transmitted together with the version number either. In the case of D1, the additional data in the package definition file, i.e. the specified actions, the file names, types, etc., which is, together with the version number, included in the package definition file (column 11, lines 24 to 33), is evidently an example of such data.

Hence, in order to further minimise the amount of data transmitted before determining whether or not a modification of the software and, thus, further downloads are actually needed, it would be obvious to the skilled person to limit the data in the first transmission to the version identifier only.

The board notes that a subsequent transmission of the remaining data, i.e. file names, etc., may involve an additional transmission step, which entails additional signalling. This, however, is based on the well-known trade-off between the average number of transmission steps required and the average total amount of data to be transmitted, a matter to be decided on the basis of the likelihood of updates being actually needed. Choosing one or the other implementation cannot therefore contribute to inventive step either.

Since D1 already teaches a conditional download of data based on a comparison of version numbers in order to reduce the amount of data to be transmitted, the board concludes that the skilled person, when faced with the above-mentioned technical problem, would, without the exercise of inventive skill, apply this teaching in the same way and with the same advantage, by further reducing the first transmission to a transmission of the version number only, which is then followed, only if necessary, by a transmission of the remaining data of the package definition file.

The appellant argued in response to the communication annexed to the summons to oral proceedings that it might have been well-known to use the trade-off for a separation of the software version and the software itself, but no document had been found describing that this trade-off was used for an action list and the version number of the action list.

The board notes however that the term "action list" leaves open whether or not it includes software, and that the application as filed does not give the term "action list" a specific meaning which would exclude software. In this respect, the board notes that, cf. claim 3 of the application as filed, the method includes the step of "executing" the instruction "contained in the remote action list".

1.7 Hence, the skilled person would, starting out from D1 and faced with the problem of further reducing the amount of transmitted data for those cases in which a modification of the software of the mobile device is not necessary, arrive, without the exercise of inventive skill, at a method which includes all the features of claim 1.

1.8 For the above reasons, the board concludes that the subject-matter of claim 1 does not involve an inventive step (Articles 52(1) and 56 EPC).

2. Conclusion

As the only request is not allowable, it follows that the appeal must be dismissed.