Method and system for controlling software version updates

Technical field of method and system for controlling software version update

[0001] The present invention relates to wireless communication devices, and more particularly, to a method and system for controlling software version updates of wireless terminal devices.

Background technique

[0002] The number and types of wireless terminal devices such as mobile phones, laptops capable of wireless communication, PDAs with wireless communication capabilities, self-service kiosks, and two-way pagers are increasing rapidly. The software applications running on these devices also increase their utility. For example, a mobile phone may contain an application to retrieve weather conditions within a city, or a PDA may contain an application to enable users to purchase groceries. These software applications take advantage of connectivity to the network in order to provide users with timely and effective services.

[0003] As is well known in the art, software application developers frequently propose new and/or updated versions of their software. These software updates may be released very frequently, for example, as patches to address deficiencies in previously released software. For example, important upgrades can be released once a year or two, and new features are often provided to enhance the utility of specific equipment.

[0004] However, although software developers may easily develop and release software updates, it is very complicated to actually perform the updates on all affected devices. For example, in wireless networks, connectivity is often intermittent, so that a particular device may not be connected to the network when an update is released. In this case, some method is needed to enable the update to be downloaded and installed at a later time. Even when this is done, some devices may lack resources (such as enough memory) to download and successfully install specific updates. In other cases, application updates may require updating the device's controller software before the application is installed. In other cases, it may be necessary to download and install a series of application upgrades in a specific order. Therefore, for example, it is necessary to install application upgrades that provide new features before service patches for correcting many problems including defects in new features.

[0005] Therefore, there is always a great need for methods and systems for controlling the installation of software updates to wireless terminal devices.

[0006] Summary of the Invention

[0007] Accordingly, the purpose of the present invention is to provide a method and system for controlling the installation of software updates to wireless terminal devices.

[0008] Therefore, one aspect of the present invention provides an asynchronous installation method for controlling software updates on multiple terminal devices of a wireless network. According to the present invention, the application gateway hosting the corresponding terminal device receives the update notification message in response to the software update. The update notification message includes: a software identifier that uniquely identifies the application program affected by the update; a version number associated with the software update; and the address of the update script in the data network accessible by the corresponding terminal device. The update script is suitable for installing software updates on the corresponding terminal devices. The update notification message is recorded in the update registry, and the notification message is forwarded to the terminal device affected by the software update. The notification message includes: the software identifier, the version number, and the address of the update script, so that the terminal device can access and execute the update script to install the software update.

[0009] Another aspect of the present invention provides an asynchronous installation method for controlling software updates on a terminal device of a wireless network. According to the present invention, an update notification message including information related to available software updates is received by the runtime environment of the terminal device. The update notification message includes: a software identifier that uniquely identifies the application affected by the update;

CN 101040552 Β

The version number associated with the software update; and the address of the update script in the data network accessible by the terminal device, the update script being suitable for installing the software update in the terminal device. Use the update version number to determine the compatibility of the software update. After that, use the address to access the update script and execute it to install the software update.

[0010] Another aspect of the present invention provides a method capable of controlling the distribution of software updates affecting application programs installed on multiple terminal devices of a wireless network. According to the present invention, the version number distribution plan is defined as including fields corresponding to each of the various aspects of the application. When publishing the initial application load, the initial value of each field is defined. For each successive software update that affects the application, identify each aspect of the application that the software update affects, and increment the value of each field.

[0011] Description of the drawings

[0012] With reference to the accompanying drawings, more features and advantages of the present invention will become apparent from the following detailed description. In the accompanying drawings:

[0013] FIG. 1 is a block diagram schematically showing a network system;

[0014] FIG. 2 is a block diagram schematically showing the structure and operation of an application development environment according to an aspect of the present invention;

[0015] FIG. 3 is a message flow diagram schematically showing the processing of publishing software upgrades according to an aspect of the present invention; [0016] FIG. 4 is a schematic diagram showing installation on a terminal device according to an embodiment of the present invention Message flow chart for the processing of software upgrades; and

[0017] FIG. 5 is a message flow diagram schematically showing a process of installing a software upgrade on a terminal device according to another embodiment of the present invention.

[0018] It should be noted that in all the drawings, the same parts are identified with the same reference numbers.

Detailed ways

[0019] The present invention provides a method and system for controlling the distribution and installation of software updates on wireless terminal devices. The following are only examples, and the embodiments of the present invention will be described with reference to FIGS. 1-5.

[0020] Referring to FIG. 1, a system according to an exemplary embodiment of the present invention generally includes an application gateway (AG) 2 connected between a wireless network 4 and a data network 6 (for example, the Internet). The system also has an online registry 8, including: a profile registry 10, containing information tables for each subscriber's terminal devices 14a, 14b, 14c, used to identify the software applications stored on each terminal device; and update The registry 12 contains information identifying any available application updates.

[0021] In accordance with the applicant's simultaneous pending US Patent Publication Nos. 2004/0215700 and 2004/0220998 (the two are hereby incorporated by reference) described in the manner, the AG2 is usually operated in order to connect to the wireless network 4. The message flow is communicated between the terminal devices 14a, 14b, 14c and the data services accessible through the data network 6.

[0022] The online registry 8 can be co-resident with the AG 2 or can be remote from the AG and accessed by the AG through the data network 6. In the embodiment of FIG. 1, the online registry 8 includes a profile registry 10 and an update registry 12. The profile registry 10 contains a profile for each of a plurality of terminal devices. Each profile contains at least a list of software identifiers (SW-ID) that uniquely identify the runtime environment (RE) and each application installed on the respective terminal device. The respective "current" version number of each application installed on the terminal device can also be stored in the online registry 8 in association with the respective SW-ID, or can be stored in the terminal device. For each software update, the separate script registry 40 contains one or more scripts designed to perform software updates on the terminal device.

[0023] Generally, the terminal device can be any of a variety of software-controlled wireless devices, including but not limited to: none

CN 101040552 Β

A line-enabled laptop computer 14a, a mobile or cellular phone 14b, a PDA 14c with wireless communication capabilities, a self-service phone booth, and a two-way pager. As can be seen from FIG. 1, these devices generally include: a microprocessor 16 connected to an RF component 18 for wireless communication, a memory 20 (at least part of which is generally non-volatile), and a display 24 and one or A user interface (UI) 22 of a plurality of user input devices (UID) 26 (eg, keyboard, thumbwheel, stylus, microphone, etc.). The microprocessor 16 operates under software control to provide the functions of the terminal device. Preferably, the software is designed in a layered model, in which the RE 32 performs translation between the application software 30 and the native language 34 of the terminal device to control the hardware of the terminal device and communicate with data services. This layered software model and its operation method can be obtained from the applicant's pending US Patent Publication Nos. 2004/0215700 and 2004/0220998. The RE can also maintain a terminal device registry 28 (denoted as "TD-REG" in FIG. 1), which is used to identify each application program installed on the terminal device and the current version number of each application program. The operation of the RE capable of asynchronously distributing and installing software upgrades to terminal devices will be described in detail below.

[0024] As described in the applicant's pending US Patent Publication Nos. 2004/0215700 and 2004/0220998, the operation of AG 2 enables software applications to be executed in the terminal device to communicate with the data services provided by the data network 6 ( Not shown) to communicate. For example, this operation may include accessing and downloading files from a back-end data source (not shown) connected to the data network 6. As can be seen in Figure 1, and described in more detail below, the application developer (AD) 36 may also distribute and support new or updated software via the data network 6. For example, downloadable application software and installation scripts may be stored in an application developer registry 38 that can be accessed by users (directly or indirectly) through the data network 6.

[0025] Application Development Environment

[0026] Referring now to FIG. 2, application developers use the application development toolkit (ADT) 52 of the application development environment (ADE) 50 running on the computing device to perform the application software development in a manner generally known in the art. Perform coding, testing, and debugging. The computing device may be a personal computer or laptop computer connected or connectable to a data network or other network workstation. Again, in a manner known in the art, the same ADE can also be used to develop subsequent updates of the application. According to the present invention, the ADE 50 further includes a versioning module 70, which automatically assigns a version number based on changes in the source code of the application program during the processing of encoding, testing, and debugging. The version number distribution module 70 can also be used to generate an update script 60. When the update script 60 is executed in the terminal device, the update script 60 will download and install the update on the terminal device.

[0027] For example, the version number assignment module 70 can be used to identify any one of the following:

[0028] Changes in existing data composition (such as data structure), that is, by adding or removing fields, or changing the definition of field types; changes in global variable definitions and enumerations;

[0029] Changes to existing messages, that is, by adding or removing fields, or changing the field type definition;

[0030] · Changes to existing application logic;

[0031] New data composition, messages or application logic to be added to the application.

[0032] In each case, the changes and additions detected by the version number assignment module 70 are related to the "current" version of the application (that is, the initial version with any subsequently released updates installed). As needed, the application developers actions (such as keystrokes) can be tracked in real time during the editing process by using the revision log 54, or by comparing the "past" and "after" versions of the application source code, or by comparing the application's Any other way to detect the change by comparing the updated version with the previous version of the application to determine what has changed. In any case, the version number assignment module 70 identifies new and/or revisions that are subsequently written to one or more update files 58

CN 101040552 Β

The composition of data, messages, and application logic. Then, these update files 58 can be saved to the update file registry 42. Preferably, as shown in FIGS. 1 and 2, the update file registry 42 resides in the application developer registry 38. Optionally, in the embodiment shown in FIG. 2, the revision log 54 tracks the changes made by the AD toolbox 52 to the application source code. It can be understood that the version number assignment module 70 may include the revision log 54, or the revision log 54 may be an independent module in the ADE50.

[0033] In addition, as described in more detail below, an update script 60 may be generated to control the terminal device to download and install the update file 58. The update script 60 may be saved in the script registry 40, and preferably, as shown in FIG. 2, the script registry 40 resides in the application developer registry 38.

[0034] If necessary, a script editing module or an update script editor 56 can be provided, so that the application developer can manually write the update script 60, and can also review and edit the automatically generated update script.

[0035] The update script 60 can be conveniently developed in a structured language (such as Java, JavaScript or XML) so that the device can access one or more back-end data sources through the data network 6 during the update process. This enables the update script 60 to access and download the update file 58 as needed during execution. Since the update script 60 can "pull" the required update file 58 from the back-end data source during execution, this facilitates the asynchronous distribution of updates. In addition, in a specific implementation manner, the notification message used for the upgrade may contain enough information so that the RE in the terminal device can pull out the application program update by itself.

[0036] Version number distribution plan

[0037] As described above, the version number assignment module 70 automatically assigns a respective version number to the initial version and each update of the application program. In the case of the initial version, any required "initial" version number can be used. However, after the initial version, based on the type of changes made by the update, each subsequent update is assigned an automatically generated version number. This setting has many advantages. For example, since each version number is allocated by the version number allocation module 70, the continuity between the version numbers is mandatory. For example, this means that the RE of the terminal device can use the updated version number to determine whether any other updates must be installed first. Another advantage is that the RE of the terminal device can estimate the version number of the update to detect potential compatibility issues before attempting to install the update.

[0038] These functions are enabled by formatting the version number into a version number distribution plan of multiple fields, each of which represents a different aspect of the application. For example, the version number distribution module is designed to detect changes in existing data composition, messages or logic, and the addition of new data composition, messages or logic. In theory, each of these factors can be represented by the various fields of the version number. However, in fact, it has been found that the three-field plan using the combination of "data·message·features" can get satisfactory performance, as shown in Table 1 below.

[0039] Table 1

<td>Field</td><td>description</td>

<td>data</td><td>Changes in the definition of existing data. For example, this can include: changes in data composition (such as adding or removing data fields, changing the definition of field types); permanent global variables; or enumerations.</td>

<td>news</td><td>Changes to existing messages used by the application. For example, this can include: a change in message composition (for example, adding or removing fields, changing field type definitions, or changing mappings).</td>

<td>feature</td><td>The addition of application features. For example, this may include: adding or changing application logic, screens and/or globals; the addition of new messages; and/or the addition of data components or fields.</td>

[0040] With this version number distribution plan, an initial value (for example, D=1, M=1, F=0) can be assigned to each field of the version number for the initial version of the application. After that, for each updated version, The version number allocation module automatically generates each version number for update by incrementing the value of the application program field.

[0041] For example, as described above, consider an application that was released with the version number "1.1.0". After the initial release, should

CN 101040552 Β

Application developers propose application updates, modify existing data fields and add new application logic. By incrementing the data and feature fields, these changes will be reflected in the updated version number. Therefore, the version number of the first update will be 2.1.1. After the release of the first update, its version number (2.1.1) becomes the "current" version number of the application and is compared with the next application update released. So, for example, consider a second application update that modifies the format of existing messages. By incrementing the message field, this change is reflected in the version number of the second update, so the second update version number will be 2. 2. Ε

[0042] It should be understood that this mode can continue any number of updates, and each time may affect any or multiple aspects of the application. It will also be understood that the version number allocation plan can be extended to provide finer granularity. For example, a set of added fields representing new data, messages, or application logic can be used to replace characteristic fields. In another example, a field can be added to the version number to indicate whether REo must be updated before the installation of the application

[0043] It can also be understood that the present invention is not limited to the application itself. For example, the version number distribution plan and the update method described here can be equally applied to the RE itself, so that the update of the RE can be controlled.

[0044] Asynchronous Software Distribution

[0045] Referring to FIG. 3, when the application developer (AD) 36 releases the software version (initial software loading or update), the version number assignment module assigns the version number, and stores the update script and update file in the AD registry 38 . Then, AD 36 sends an update notification message to AG 2. Preferably, the update notification message includes a unique identifier identifying the application software (SW-ID), a version number, and the script is stored in the register 40 further link (e.g. URL) for the new script. When AG 2 receives the update notification message from AD 36, AG 2 records the update by storing the software ID, version number, and script URL in the update registry 12. Once the update is recorded by AG 2, it can be distributed asynchronously to the user's terminal equipment in a variety of ways. Two representative distribution schemes are described below with reference to Figures 4 and 5.

[0046] FIG. 4 shows an asynchronous distribution scheme. For example, the AG 2 responds to an update notification message received from the AD 36 to initiate the scheme. Therefore, AG 2 uses the software ID (e.g. included in the update notification) to search the profile registry 10. The search returns information (such as device ID) that identifies all terminal devices on which the application has been installed. Then, AG 2 can generate a notification message and send the notification message to each terminal device identified. For example, the notification message may include the updated software ID and version number, and a link (for example, URL) to the update script stored in the script section 40 of the application developer registry 38. [0047] When the notification message is received , The runtime environment (RE) can extract the software ID and version number from the message, and use this information to determine whether the update can be safely installed on the terminal device. This estimate can take the form of the following compatibility checks:

[0048] Compare the "new" version number with the current version number saved in the terminal device registry (TD-REO28) to identify which aspects of the application will be changed during the update. For example, you can change the new version This function is realized by subtracting the current version number and the current version number field by field. For example, consider that the current version number is "2. 2. 1" and the new version number contained in the notification message is "2. 3. 2" Situation. Subtract the current version number from the new version number field by field to get "0.1.1", which means that the update involves: the existing data composition does not change; at least one existing message has changed; at least one new feature has been added .

[0049] Determine whether any inserted updates must be installed before the "current" update identified by the notification message. This can be done by the above subtraction result. Specifically, if any field of the subtraction result has a value greater than "1", then at least one update must be installed before the "current" update.

[0050] Generally speaking, the addition of new features will not cause any compatibility problems. However, the existing data composition or message

CN 101040552 Β

The changes may have compatibility issues, because the user data stored in the memory may be incompatible with the revised data and/or message definitions. Therefore, the installation of the update will require the conversion of the saved data, and the ability to perform such conversion may be limited by the hardware performance of the terminal device. In addition, there is a risk that some data may be damaged or lost in data conversion, so users may prefer not to install the update, even if the required conversion function is the performance of the terminal device.

[0051] Therefore, as long as the RE determines that the update affects the existing data composition and/or existing messages, the RE can provide a warning message to the user indicating that the update is available, but its installation may cause data loss or damage. Then, the user can choose whether to install the update. Optionally, the update script defined by the application developer using the AD tool can perform data conversion for incompatible updates.

[0052] When (or if) the user chooses to install the update, or if the RE determines that there is no compatibility problem (that is, the update only adds new features), the RE can open the link (URL) contained in the update notification message To initiate the installation of the update, and access and download the update script from this. When the update script is successfully downloaded from the application developer registry (the script component 40 in the AD-REO38, the RE can load the script, and then the script controls the download and download from the update file section 42 of the application developer registry 38). Install the update file.

[0053] When the update is successfully installed, the RE uses the update version number received in the update notification message to update the "current" version number of the application stored in the terminal device registry, and sends an update completion message to AG2 . When receiving the update completion message, AG 2 updates the device profile with the new version number, thereby indicating that the software update has been successfully installed on the terminal device 14b.

[0054] The limitation of the scheme described in FIG. 4 is that AG 2 initiates an update distribution scheme by sending a notification message to each terminal device on which the affected software is installed (for example, in response to receiving an update notification message from the AD36). This may cause a large number of undesired notification messages to flood into the network, which may increase the load on the wireless network bandwidth. In addition, when the AG sends a notification, some terminal devices may not be connected, and as a result, the "disconnected" terminal devices may miss the update. These problems can be solved by the asynchronous distribution scheme described below with reference to FIG. 5.

[0055] In the distribution scheme shown in FIG. 5, asynchronous distribution is triggered by the terminal device. In the example shown, the trigger event is when the terminal device logs on to the AG 2, although other events can also be used. For example, the RE may send a message to the AG 2 to check for updates according to a predetermined schedule, or to check for updates when the application program is loaded into the terminal device 14b. In any case, the AG 2 responds to the terminal device 14b by accessing the profile of the terminal device in order to identify each application installed on the terminal device 14b and the current version number. This information is then used to search the update registry 12 to identify any update that affects the terminal device 14b and the corresponding update version number. Then, the comparison between the current and updated version numbers enables the AG to determine whether there are any updates that have not been installed on the terminal device 14b.

[0056] Then, AG 2 customizes an appropriate update notification message for each uninstalled update, and sends it to the terminal device 14b. Then, the terminal device 14b checks that the update notification message and the subsequent processing of installing the update conforms to the description with reference to FIG. 4 The above processing, that is, the terminal device 14b checks the compatibility, and then installs the update by opening a link (URL) to download the script from the AD-REG 38. Executing the script on the terminal device enables access and download of the update file stored in the AD-REG 38. When the update is completed, the terminal device signals the completion of the update by notifying the AG of the software ID and version number. Then, the AG updates the profile file in the profile registry 10 by notifying the profile registry 10 of the software ID and version number.

[0057] The embodiments of the present invention described above are intended to be examples only. Therefore, the scope of the present invention is only limited by the appended claims.

<img file="CN101040552B_D0001.tif" />

Figure 1 ίο

CN 101040552 Β