WO2013000749A1

WO2013000749A1 - Method of updating a mobile device, and an updating device

Info

Publication number: WO2013000749A1
Application number: PCT/EP2012/061549
Authority: WO
Inventors: Peter Molin; Johan Nohave
Original assignee: Malvacom Ab
Priority date: 2011-06-28
Filing date: 2012-06-18
Publication date: 2013-01-03

Abstract

There is disclosed a method and device for updating data on a wireless device, wherein, when a new data version is obtained: diff-files, which are each useful for making a transition from one older version of the data, among a number of older versions, to the latest version, with a single diff-file, are obtained, and, when a WD having an older version requests to update its data, a diff-file, which is sufficient for carrying out the transition from the requesting WDs version to the latest version, is sent to the requesting WD.

Description

METHOD OF UPDATING A MOBILE DEVICE, AND AN UPDATING DEVICE

Technical field

This disclosure relates to a method in an updating device, UD, for updating data on a wireless device, WD, on the other side a wireless interface. A corresponding updating device is also considered.

Background

A wireless device, WD, such as a mobile phone, may be used in connection with an Internet based service, IS. The connection is established via a wireless interface, such as a cellular phone base station or a wireless local area network, WLAN. The IS often generates new versions of data, and it is possible to let the WD update its data as soon as a new version is generated. Different WDs may use different data versions, and may update data in an unpredictable manner.

One general problem when updating data is how to use the wireless interface in an efficient way when updating data, as the interface's bandwidth is limited and usage costs WD battery power.

Summary

One object of the present disclosure is therefore to provide an efficient updating method.

This object is achieved by means of a method in an updating device, for updating data on a wireless device on the other side a wireless interface where a new version of said data is obtained. Diff files are generated which each define a transition from one older version of the data, among a number of older versions, to the new version, with a single diff-file. When a WD, having an older version of said data requests to update its data, a diff-file, which is sufficient for carrying out the transition from the requesting WD's version to the latest version, is sent to the requesting WD.

This provides an efficient use of the interface, as, compared to if a chain of subsequent diff files would be sent, less overhead is used to carry out the updating.

The diff-files may be created in advance only for some older versions of said data, other versions being ignored. This reduces the load on the updating device, as diff files corresponding to versions that will most likely not be requested need not be prepared in advance. It may be checked for each version whether there are any WDs that have that version, and diff-files may be created only for versions that have WDs using that version.

Alternatively, it may be checked for each version whether the number of WDs that have that version exceed a number of user threshold, and diff- files may be created only for versions that have a number of using WDs that exceed that threshold.

However, a diff file, corresponding to the difference between the new version of the data and the version immediately preceding the new version of the data, may always be created as this file will most likely be asked for.

If an update from an ignored version is requested from a WD, a corresponding diff file may be created on the fly and sent to the WD.

Alternatively, when an update from an ignored version is requested from a WD, the latest created diff file may be sent to the WD together with a message indicating that there are more updates. The WD may then retry updating.

As another alternative, when an update from an ignored version is requested from a WD, the complete data may sent to the WD. For small data entities this may be more efficient.

A corresponding updating device, UD, is also considered and comprises a processor, generating diff-files, which each define a transition from one older version of said data to the new version, with a single diff-file, and a transmitter sending such a diff-file to a requesting WD.

The diff-files may be created in advance only for some older versions of the data, based on contents in a WD database in the UD, linking versions to WDs, other versions being ignored. Brief description of the drawings

Fig 1 illustrates a system where a device and a method of the present disclosure may be employed.

Fig 2 illustrates an updating scenario.

Fig 3 illustrates a flow chart of an updating method.

Fig 4 illustrates an updating device with a WD database.

Fig 5 illustrates a modification of the flow-chart in fig 3.

Fig 6 shows a diagram illustrating the number of users or devices having different versions of a set of data.

Fig 7 illustrates a flow chart of an updating method.

Fig 8 illustrates an updating scenario.

Fig 9 shows a flowchart for updating a device requesting a new version.

Detailed description

Fig 1 illustrates a system where devices and methods of the present disclosure may be employed. A wireless device, WD, 101 , which is here illustrated as a mobile phone, is utilized by a user in connection with a num- ber of Internet based services, IS, 102, 103, 104.

Even if the WD 101 is here illustrated as a mobile phone, other WDs are conceivable, such as laptop computers and the like. A broad definition of a WD is a device that, at least temporarily, is capable of communicating via a wireless interface. Hence, the WD could in principle be part of a fixed structure, for instance a surveillance or alarm system operating via a cellular phone system.

The WD is connected to the ISs via a wireless interface, in the illustrated case via a cellular phone base station 106 or via a wireless local area network, WLAN, access point, AP, 107. The base station 106 may be connected to the Internet 109 via a public land mobile network, PLMN, 1 10 and the AP may be connected to a network forming part of the Internet as is well known and will not be discussed further. Needless to say, other access methods are conceivable, e.g. via BLUETOOTH connections. The WD may also switch between different access methods during use or in between sessions.

ISs and other entities often generate new versions of data, and it is possible to let the WD update its data as soon as a new version is generated. However, different WDs may use different versions of data and may update this data in an unpredictable fashion, typically when a WD is switched on or roams, or when a user activates or uses a particular service on the WD. The term data is here used in its broadest sense and may include anything from program files and other files to data in databases and wheather data or stock quotes.

There is generally a desire to use the wireless interface in an efficient way. If the WD is battery operated this is one reason to use the wireless interface as little as possible, as transmissions and receptions of data con- sume power. Further, the bandwidth of the wireless interface is limited, and excessive bandwidth usage is sometimes heavily charged. Also, the wireless interface may sometimes be slow and function intermittently, which is another reason to use it efficiently.

It will now be disclosed an updating device, UD, and an updating method. This device may carry out updating in an efficient manner and may, as illustrated, be arranged in general as an entity conntected to the Internet. As an alternative the UD may be arranged in an internet service, or in connection with a PLMN. Other alternatives do exist. In general, the UD is situated on the other side of the air interface as seen from the WD. Typically, the UD need not have dedicated hardware, but can be implemented as a software block that runs on one or more servers.

Fig 2 illustrates a simple updating scenario. Initially, data with a first version 201 is generated, then the data with a second version 202, then with a third 203 and then with a fourth 204. While it is possible, for a user having the first version of data 201 and desiring to have the second version 202 to simply load the second version, it is in many case efficient to instead load a transition- or delta- or diff-file 205 that includes the changes needed to go from the first version to the second. A UD can prepare such a file in advance, such that a WD can quickly aquire a data update.

When the third version 203 is generated, the UD can create two new diff-files, one 206 to go from the second version 202 to the third 203, and one 207 to go from the first 201 version to third 203. The latter can be created by merging the ones 205, 206 already created.

Similarly, the UD can create three new diff-files 208, 209, 210 when the fourth version 204 of the data is created.

In general it is more efficient for a WD to obtain one already combined diff-file, such as 207, rather than obtaining two corresponding one-step diff- files, such as 205, 206, as less overhead is needed in the transmission and application of a single diff-file.

Fig 3 illustrates a flow chart of an updating method that creates such diff-files which can be carried out in a UD. In a first step 301 , a new data version is created (e.g. 204 in fig 2). In a second step 302, a diff-file (210 in fig 2) is created ND, which reflects changes between the two most recent versions.

Then, in a third step diff files corresponding to changes from each of the other previous versions to the lates version are created (208, 209 in fig 2).

As can be seen in fig 2, already four versions of the data may require the generation of 6 different diff-files. Correspondingly, combinatorics implies that the generation of 100 different versions of data would require almost 5000 different diff-files. While this need not be a problem with services that update infrequently, such as larger software patches and the like, other types of data change versions very often, and this contributes to a great UD load.

Fig 4 illustrates an updating device 1 1 1 including a processor 403 for determining whether diff files should be created, and a transmitter 405 sending diff files to WDs by a wired or wireless medium. The updating device is provided with a WD database 401 . This is one way to reduce the UD load. The WD database 401 keeps track of which versions of the data each WD that it services has. If for instance no device has the second version 202 of the data when the fourth version 204 of the data is generated, there is little point in creating the diff-file 209 that goes from the second 202 to the fourth version 204. Thus, the step 303 of fig 3 can be modified into step 503 as illustrated in fig 5. Then, a merge operation is carried out between each diff- file and the newest diff-file, ND, to create new diffs, for all diffs where the originating version has at least one user. As no WD will ask for the diff-files that are not created, this will not impose any problems and saves operations at the UD.

In a further development, a WD number threshold 601 is introduced, as is illustrated in fig 6. In this illustration there are seven different versions numbered 1 -7 and more than 200 users. The WD number threshold is set to 10, and two of the versions, 4 and 6, have fewer than 10 users. The updating method carried out by the UD can use the threshold 601 as illustrated by the flowchart in fig 7. The basic outline of this flow chart resembles the one outlined in fig 3, i.e. steps 700-702 and 704 correspond to steps 300-302 and 304, but instead of simply creating diff-files by merging all existing diff-files with the latest diff-file ND, as shown in step 303 in fig 3, the following is carried out for each of the diff-files kept in store by the UD: In step 705 it is checked if the originating version corresponding to the diff-file is tagged as ignored, i.e. if it has already been noticed that the number of users having that version of the file is lower than the threshold. If so, the UD does nothing more with respect to that diff-file. If not tagged as ignored, it is checked 706 whether the number of users having that version is below the threshold. If so, that version is flagged 708 as ignored and the method proceeds to the next diff-file. If not, the merge is carried out 707 to provide a new diff-file in addition to the old one.

Of course it is possible to test the threshold for all diff-files thereby not needing to handle the ignore flags. If so, steps 705 and 708 are short- circuited.

It should further be noted that diff-files can be efficiently handled in groups as a lot of them will relate to the same originating version.

If a version has been ignored and one of the WDs, which has that version, asks for an update, this can be handeled in different ways. To start with, the UD can send a number of smaller diff-files which together brings the WD from its current version to the latest version. This can be done in smaller or bigger steps depending on the situation.

Another option is to create a diff-file on the fly that satisfies the requesting WDs needs with only one diff-file.

A third option can be to send the entire file with the latest version rather than the diff-files. This could particularly be used when the complete file is relatively small.

The way chosen to update an ignored version may depend on UD server load, estimated time to merge a new diff-file, time of initialization, and different policies. For instance, a premium user may in principle always receive a merged version created on the fly.

Fig 8 illustrates an updating scenario which resembles the one shown in fig 2, but where, when the fourth version is generated version 2 is ignored for having too few users. Hence the diff-file that is needed to go directly from version 2 to version 4 is not generated (corresponds to 209 in fig 2).

Then, with the above indicated approaches the UD can handle this with the following different sets of actions.

The UD can provide the requesting WD with the 2-3 d iff, and allow the WD to request the 3-4 diff, thereby ultimately receiving the latest version.

The UD alternatively can merge the 2-3 diff with the 3-4 diff thereby obtaining a 2-4 diff-file which is sent to the WD. In many cases a whole chain of smaller diff-files may need be merged, particularly if there are a number of ignored versions on the way to the current version.

The UD can as a further alternative re-initialize the WD and send data corresponding to version 4 in its entirety. This latter alternative may however be very cumbersome for large file data.

One example of an algorithm intended to select between these three options is now outlined with reference to fig 9. Some parameters are used.

The server load factor SL (0-100) is measured and is based on a combination of UD central processing unit, CPU, usage and memory usage.

A server load threshold "heavy load", HL, is defined e.g. to SL=65. The number of mergers needed in sequence to obtain a single diff-file, SEQ, is calculated.

A threshold is defined which indicates the maximum allowed on the fly merger sequence, SEQMAX.

The file size needed for complete re-initialization is measured, IS, i.e. the size of the final version data file.

A function is used that calculates the size of diff-files needed, size(SEC).

A further function is used that returns the minimum number of d iff files in a sequence, nr (SEQ).

The method starts in step 900, and in step 901 a request of an update from version v is received. In step 902, it is checked whether the version v is ignored. If not, the UD simply delivers 910 the diff-file needed to go from v to the latest version and the procedure ends 91 1 .

If version v is ignored however, the sequence of diff-files needed to update the WD is identified 903. It is then tested 904 whether SL<HL and nr(SEQ)<SEQMAX, i.e. whether the the UD server is not too busy and the sequence of diff-files is not too long. If this is the case, the merging of the required sequence is carried out 905. Optionally, the version v's ignore flag may be removed 906. The thus created new diff-file is sent 910 to the WD and the procedure ends 91 1 .

If the test in step 904 was negative it is tested 907 whether

size(SEQ)<IS, i.e. whether more efficient to send all the diff-files needed or the entire data of the latest version. If so, the first diff-file in order is selected 908, and sent 910 to the WD, at the same time the WD is informed of the fact that there are further updates. If the test in 907 is negative, the last version of the data is selected 909 and sent 910 in its entirety to the WD whereafter the procedure ends.

The disclosure is not limited to the described embodiment and may be varied and altered in different ways within the scope of the appended claims.

Claims

1 . A method in an updating device, UD, (1 1 1 ) for updating data on a wireless device, WD, (101 ) on the other side a wireless interface wherein, a new version of said data is obtained, characterised by:

-generating diff-files (205-210), which each define a transition from one older version of said data, among a number of older versions, to the new version, with a single diff-file, and

-sending, when a WD having an older version of said data requests to update its data, a diff-file, which is sufficient for carrying out the transition from the requesting WD's version to the latest version, to the requesting WD.

2. A method according to claim 1 , wherein corresponding diff-files are created in advance only for some older versions of said data, other versions being ignored.

3. A method according to claim 2, wherein it is checked for each version whether there are any WDs that have that version, and wherein diff- files are created (503) only for versions that have WDs using that version.

4. A method according to claim 2, wherein it is checked for each version whether the number of WDs that have that version exceed a number of user threshold, and wherein diff-files are created only for versions that have a number of using WDs that exceed that threshold.

5. A method according to any of the preceding claims, wherein a diff file corresponding to the difference between the new version of the data and the version immediately preceding the new version of the data is always created (302).

6. A method according to any of claims 2-4, wherein, when an update from an ignored version is requested from a WD, a corresponding diff file is created (906) and sent to the WD.

7. A method according to any of claims 2-4, wherein, when an update from an ignored version is requested from a WD, the latest created diff file is sent (908) to the WD together with a message indicting that there are more updates.

8. A method according to any of claims 2-4, wherein, when an update from an ignored version is requested from a WD, the complete data is sent (909, 910) to the WD.

9. An updating device, UD, (1 1 1 ) for updating data on a wireless device, WD, (101 ) on the other side a wireless interface when a new version of said data is obtained, characterised by:

-a processor (403), generating diff-files (205-210), which each define a transition from one older version of said data, among a number of older versions, to the new version, with a single diff-file, and

-a transmitter (405) sending, when a WD having an older version of said data requests to update its data, a diff-file, which is sufficient for carrying out the transition from the requesting WD's version to the latest version, to the requesting WD.

10. A UD according to claim 9, wherein corresponding diff-files are created in advance only for some older versions of said data, based on contents in a WD database (401 ) linking versions to WDs, other versions being ignored.

1 1 . A UD according to claim 10, wherein it is checked for each version whether there are any WDs that have that version, and wherein diff-files are created (503) only for versions that have WDs using that version.

12. A UD according to claim 10, wherein it is checked for each version whether the number of WDs that have that version exceed a number of user threshold, and wherein diff-files are created only for versions that have a number of using WDs that exceed that threshold.

13. A UD according to any of claims 9-12, wherein a diff file

corresponding to the difference between the new version of the data and the version immediately preceding the new version of the data is always created.

14. A UD according to any of claims 10-12, wherein, when an update from an ignored version is requested from a WD, a corresponding diff file is created and sent to the WD.

15. A UD according to any of claims 10-12, wherein, when an update from an ignored version is requested from a WD, the latest created diff file is sent to the WD together with a message indicating that there are more updates.

16. A UD according to any of claims 10-12, wherein, when an update from an ignored version is requested from a WD, the complete data is sent to the WD.