as) United States
`a2) Patent Application Publication (0) Pub. No.: US 2006/0236083 A1
`
` Fritsch et al. (43) Pub. Date: Oct. 19, 2006
`
`
`US 20060236083A 1
`
`(54) METHOD AND SYSTEM FOR
`CONTROLLING SOFTWARE VERSION
`
`(22)
`
`Filed:
`
`Apr. 11, 2006
`
`UPDATES
`
`Related U.S. Application Data
`
`(75)
`
`Inventors: Brindusa L. Fritsch, Toronto (CA);
`Viera Bibr, Kilbride (CA); Vladimir
`Blagojevic, Manchester (GB); Bryan R.
`Goring, Milton (CA); Michael
`Shenfield, Richmond Hill (CA);
`KamenB. Vitanov, Mississauga (CA)
`
`Correspondence Address:
`Brij K. Agarwal
`Eckert Seamans Cherin & Mellott, LLC
`44th Floor
`600 Grant Street
`Pittsburgh, PA 15219 (US)
`
`(73) Assignee: Research In Motion Limited, Waterloo
`(CA)
`
`(21) Appl. No.:
`
`11/402,112
`
`(60) Provisional application No. 60/672,096, filed on Apr.
`18, 2005.
`
`Publication Classification
`
`(51)
`
`Int. Cl.
`(2006.01)
`GO6F 15/177
`(52) US. Che
`eeeeeccececeeseessesessesseesessnesneententensensens 713/1
`op
`vp
`(67)
`ABSTRAC |
`.
`Methods and systemsare provided for controlling asynchro-
`nous distribution andinstallation of software updates affect-
`ing applications installed on terminal devices of a wireless
`network. A versioning schema enforced by the application
`development environment enables the runtime environment
`of a terminal device to evaluate a software update to identify
`potential compatibility issues and control installation of the
`update.
`
`
`
` Versioning
`Module
`70
`
`
`
`
`
`Revisions
`|
`Update Script
`Editor
` AD
`Log
`
`
`56
`
`Tootkit
`
`
`
`58
`Updatefiles
`Update Script
`
`
`
`
`60 40
`
`Update Files
`
`
`
`42
`
`Data Co Exhibit 1040
`Data Co Exhibit 1040
`Data Co v. Bright Data
`
`Data Cov. Bright Data
`
`

`

`Patent Application Publication Oct. 19,2006 Sheet 1 of 5
`
`US 2006/0236083 Al
`
`Figure1
`
`AD-REG
`
`Update
`Files
`
`Profiles
`
`12
`
`
`TL 3g
`
`
`
`Data Network
` 10
`ee,>
`|
`
`
`
`
`Wireless Network
`
`
`
`
`
`

`

`Patent Application Publication Oct. 19,2006 Sheet 2 of 5
`
`US 2006/0236083 Al
`
`Figure 2
`
`50
`
` Versioning
`Module
`
`70
`
`
`
`
`Update Script
`Revisions
`Log
`Editor
`
`26
`
`
`
`AD
`
`Toolkit
`
`
`
`
`Updatefiles
`Update Script
`58
`
`
`
`
`60 Update Files
`
`42
`
`

`

`Patent Application Publication Oct. 19,2006 Sheet 3 of 5
`
`US 2006/0236083 Al
`
`
`
`(THN‘#49‘aI-ms)eepdn-607
`
`
`
`(an
`
`#J9A‘CI-MS)AJION
`
`ge
`
`ou‘935u-0V
`
`
`
`OvSail4“4s}duogayepdn
`
`ov
`
`©ainbi4
`
`
`
`
`
`
`

`

`Patent Application Publication Oct. 19,2006 Sheet 4 of 5
`
`US 2006/0236083 Al
`
`Ov
`
`‘Day-dv
`
`sally
`
`BE
`
`cv
`
`ch
`
`sayepdn
`SO|YOld
`
`
`
`(q]eolAeq)usnjey
`
`(GI-Ms)4oees
`
`LI BES
`
`painbi4
`
`
`
`
`
`(THN'#48A‘CI-AAS)AJION
`
`eee
`
`
`
`(TUN)xUyuado
`
`
`
`ayepdyj/e3su|
`
`
`
`
`
`Sayayepdnpeojumop/sseooy@)n08xy
`
`ydiosg
`
`
`
`
`
`(#48‘CI-MS)a}@|dwooayepdn
`
`
`
`
`
`(#49,‘GI-MS)@1NOdayepdn
`
`
`
`
`
`
`
`

`

`Patent Application Publication Oct. 19,2006 Sheet 5 of 5
`
`US 2006/0236083 Al
`
`(al
`
`
`
`
`
`
`
`
`
`(#49,JUOLIND‘QI-MS)ye4xXg
`
`Sa|yajepdnpeojumop/ssacoy
`‘dI-MS)21yOdayepdry
`
`
`
`(THN'#42A‘CI-AAS)ANION
`
`
`(#49A‘CI-MS)e}e[duo0oayepdy
`
`
`
`-MS)yose3ag(TaN‘#8farmsjumeg|“——__
`
`(#8A
`
`CteJOACte
`
`-9D1A9Q)a[yO1qguadoO
`
`(al-a01A9q)ucbo7
`
`gaunBie
`
`(THN)yuusdoO
`
`
`
`ayepdyteysu]
`
`9)Nd8xy
`
`yduos
`
`
`
`
`
`

`

`US 2006/0236083 Al
`
`Oct. 19, 2006
`
`METHOD AND SYSTEM FOR CONTROLLING
`SOFTWARE VERSION UPDATES
`
`CROSS-REFERENCE TO RELATED
`APPLICATION
`
`[0001] The instant application claims priority from U.S.
`Provisional Patent Application Ser. No. 60/672,096 filed
`Apr. 18, 2005, the disclosures of which are incorporated
`herein by reference.
`
`
`TECHNICAL FIELD
`
`Thepresent invention relates to wireless commu-
`[0002]
`nications devices, and in particular to a method and system
`for controlling software version updates for wireless termi-
`nal devices.
`
`BACKGROUND OF THE INVENTION
`
`[0003] The number and variety of wireless terminal
`devices, such as mobile telephones, wireless-enabled lap-
`tops and PDAs with wireless communication capabilities,
`self-service kiosks and two-way pagers are rapidly increas-
`ing. Software applications which run on these devices
`increase their utility. For example, a mobile phone may
`include an application which retrieves the weather for a
`range of cities, or a PDA mayinclude an application that
`allows a user to shop for groceries. These software appli-
`cations take advantage of the connectivity to a network in
`order to provide timely and useful services to users.
`
`[0004] As is well known in the art, software application
`developers frequently produce new and/or updated versions
`of their software. Such software updates may be released on
`a very frequent basis, as, for example, in the case of patches
`to resolve defects in previously released software. Major
`upgrades may be released on, for example, a yearly or bi-
`yearly basis, and often provide new functions to enhance the
`utility of a particular device.
`
`[0005] However, while software developers may readily
`develop andrelease software updates, actual implementation
`of updates on all of the affected devices is highly complex.
`For example,
`in a wireless network, connectivity is fre-
`quently intermittent, so that a particular device may not be
`connected to a network when an update is released. In this
`case, some means is needed to enable the update to be
`downloadedandinstalled at somelater time. Even whenthis
`
`is accomplished, some devices may lack resources (such as
`sufficient memory) to download and successfully install a
`particular update. In other cases, an application update may
`require that a device’s controller software be updated before
`the application update is installed. In still other cases, a
`series of application updates must be downloaded and
`installed in a particular order. Thus, for example, an appli-
`cation upgrade which provides a new feature, must be
`installed before a service patch which corrects several issues
`including a deficiency in the new feature.
`
`[0006] Accordingly, methods and systems for controlling
`the installation of software updates to wireless terminal
`devices remains highly desirable.
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`[0007] Further features and advantages of the present
`invention will become apparent from the following detailed
`description, taken in combination with the appended draw-
`ings, in which:
`
`[0008] FIG. 1 is a block diagram schematically illustrat-
`ing a network system;
`
`[0009] FIG.2 is a block diagram schematically illustrat-
`ing components and operation of an application develop-
`ment environment
`in accordance with an aspect of the
`present invention;
`
`[0010] FIG. 3 is a message flow diagram schematically
`illustrating a process for publishing a software upgrade in
`accordance with an aspect of the present invention;
`
`[0011] FIG. 4 is a message flow diagram schematically
`illustrating a process for installing a software upgrade on a
`terminal device in accordance with an embodiment of the
`present invention; and
`
`[0012] FIG. 5 is a message flow diagram schematically
`illustrating a process for installing a software upgrade on a
`terminal device in accordance with another embodiment of
`the present invention.
`
`the appended
`throughout
`It will be noted that
`[0013]
`drawings,
`like features are identified by like reference
`numerals.
`
`DETAILED DESCRIPTION OF THE
`PREFERRED EMBODIMENT
`
`[0014] An object of the present invention is to provide
`methods and systems for controlling the installation of
`software updates to wireless terminal devices.
`
`[0015] Thus, an aspect of the present invention provides a
`method of controlling asynchronousinstallation of a soft-
`ware update on a terminal device of a wireless network.
`According to the present invention, an update notification
`message in respect of the software update is received by an
`Application Gateway hosting the terminal device. The
`update notification message includes a software identifier
`uniquely identifying an application affected by the update; a
`version numberassociated with the software update; and an
`address of an update script on a data network accessible by
`the terminal device. The update script is adapted to install
`the software update on the terminal device. The update
`notification message is logged in an updates registry, and a
`notification message is forwarded to the terminal device.
`Thenotification 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.
`
`[0016] A further aspect of the present invention provides
`a method of controlling installation of a software update on
`a terminal device of a wireless network. According to the
`present invention, an update-notification message including
`information respecting an available software update is
`received by a runtime environment of the terminal device.
`The update notification message comprises: a software iden-
`tifier uniquely identifying an application affected by the
`update; a version number associated with the software
`update; and an address of an update script on a data network
`accessible by the terminal device, the update script being
`adaptedto install the software update on the terminal device.
`A compatibility of the software update is determined using
`the update version number. Thereafter, the update script is
`accessed using the address, and executed to install
`the
`software update.
`
`

`

`US 2006/0236083 Al
`
`Oct. 19, 2006
`
`{0017] A still further aspect of the present invention pro-
`vides a method of enabling controlled distribution of soft-
`ware updates affecting an application installed on a plurality
`of terminal devices of a wireless network. According to the
`present invention a version schema is defined including a
`respective field for each one ofa plurality of aspects of the
`application. An initial value of each field is defined when an
`initial application load is released. For each successive
`software update affecting the application, each aspect of the
`application affected by the software updateis identified, and
`the value of the respective field is incremented.
`
`[0018] The present invention provides methods and sys-
`tems for controlling the distribution and installation of
`software updates on wireless terminal devices. Embodi-
`ments of the invention are described below, by way of
`example only, with reference to FIGS. 1-5.
`
`[0019] Referring to FIG. 1, a system in accordance with a
`representative embodiment of the present invention gener-
`ally comprises an Application Gateway (AG) 2 coupled
`between a wireless network 4 and a data network 6, such as
`for example, the Internet. The system also has an online
`registry 8 including: a profiles registry 10 containing, for
`each subscriber’s terminal device(s) 14a, 14, 14c, a listing
`of information identifying software applications stored on
`the respective terminal device; and an updates registry 12
`containing information identifying any available application
`updates.
`
`[0020] The AG 2 generally operates to mediate message
`flows between terminal devices 14a, 144, 14c connected to
`the wireless network 4 and data services accessible through
`the data network 6 in the manner described in Applicant’s
`co-pending United States Patent Publications Nos. 2004/
`0215700 and 2004/0220998, both of which are incorporated
`herein by reference.
`
`[0021] The online registry 8 can be co-resident with the
`AG 2 or may be located remotely from the AG and accessed
`by the AG via the data network 6. In the embodiment of
`FIG.1, the online registry 8 includes a profiles registry 10
`and an updates registry 12. The profiles registry 10 contains
`a profile for each one ofa plurality of terminal devices. Each
`profile contains, at a minimum,a listing of software iden-
`tifiers (SW-IDs) uniquely identifying the runtime environ-
`ment (RE) and each application installed on the respective
`terminal device. A respective “current” version number of
`each application installed on the terminal device mayalso be
`stored in the online registry 8 in association with the
`respective SW-ID, or may be stored in the terminal device.
`A separate scripts registry 40 contains, for each software
`update, one or more scripts designed for implementing the
`software update on a terminal device.
`
`In general, the terminal devices can be any of a
`[0022]
`wide variety of software-controlled wireless devices includ-
`ing but not limited to wireless-enabled laptop computers
`14a, mobile or cellular telephones 146, PDAs with wireless
`communication capabilities 14c, self-service kiosks and
`two-way pagers. As may be seen in FIG. 1, such devices
`generally include a microprocessor 16 connected to an RF
`section 18 for wireless communications, a memory 20 (at
`least a portion of which will normally be non-volatile), and
`a user interface (UI) 22 including a display 24 and one or
`more user input devices (UID) 26, e.g. a keyboard, thumb-
`wheel, stylus, microphone, etc.). The microprocessor 16
`
`operates under software control to provide the functionality
`of the terminal device. Preferably, the software is designed
`on a layered model, in which an RE 32 translates between
`application software 30 and the native machine-language 34
`of the terminal device to control the terminal device hard-
`ware, and communicate with data services. This layered
`software model, and the manner in which it operates,
`is
`known from Applicant’s co-pending United States Patent
`Publications Nos. 2004/0215700 and 2004/0220998. The
`
`RE can also maintain a terminal device registry 28 (denoted
`“TD-REG”in FIG.1) identifying each application installed
`on the terminal device, and the current version number of
`each application. Operation of the RE to enable asynchro-
`nous distribution and installation of software upgrades to
`terminal devices will be described in detail below.
`
`[0023] As described in Applicant’s co-pending United
`States Patent Publications Nos. 2004/0215700 and 2004/
`0220998, operation of the AG 2 enables a software appli-
`cation executing in a terminal device to communicate with
`data services (not shown) offered through the data network
`6. This operation may, for example, include accessing and
`downloading files from back-end data sources (not shown)
`connected to the data network 6. As may be seen in FIG.1,
`and described in greater detail below, an application devel-
`oper (AD) 36 can also distribute and support new or updated
`software through the data network 6. For example, down-
`loadable application software and installation scripts can be
`stored in an application developer registry 38 which can be
`accessed by users (either directly or indirectly) through the
`data network 6.
`
`Application Development Environment
`
`[0024] Referring now to FIG.2, the application developer
`uses an application development toolkit (ADT) 52 of an
`application development environment (ADE) 50 running on
`a computing device to code, test, and debug application
`software,
`in a manner generally known in the art. The
`computing device can be a personal computer or laptop
`connected or connectable to the data network or other
`networked workstation. This same ADE is also used for
`developing subsequent updates of the application, again ina
`manner known in the art. In accordance with the present
`invention, the ADE 50 also includes a versioning module 70,
`which automatically assigns a version number based on
`changes made in the application source code during the
`process of coding, testing, and debugging. The versioning
`module 70 can also be used to generate an update script 60
`which, when executed in a terminal device, will download
`and install the update on the terminal device.
`
`[0025] For example, the versioning module 70 can be used
`to identify any of the following:
`
`changes in existing data components, such as
`[0026]
`data structures, i.e. by adding or removing fields, or
`changing field type definition; changes in global vari-
`able definitions or enumerations;
`
`changes in existing messages, i.e. by adding or
`[0027]
`removing fields, or changing field type definition;
`
`[0028]
`
`changes in existing application logic;
`
`new data components, messages or application
`[0029]
`logic to be added to the application.
`
`

`

`US 2006/0236083 Al
`
`Oct. 19, 2006
`
`[0035] Both of these functions are enabled by a versioning
`schema that formats the version numberinto multiplefields,
`with each field representing a respective different aspect of
`the application. For example,
`the versioning module is
`designed to detect changes in existing data components,
`messages or logic, as well as the addition of new data
`components, messages or logic. In principle, each of these
`elements can be represented by a respective field of the
`version number. However, in practice it has been foundthat
`satisfactory performance can be obtained using a three-field
`schemaof the form “Data.Messages.Features”’, as described
`in Table 1 below.
`
`In each of these cases, the changes and additions
`[0030]
`detected by the versioning module 70 are those relative to
`the “current” version of the application (that is, the initial
`release with any subsequently released updates installed). As
`may be appreciated, detection of changes can be performed
`by either real-time tracking of actions (e.g. keystrokes) of
`the application developer during the editing process using a
`revisions log 54, or by comparing “before” and “after”
`versions of the application source code or by any other
`means for comparing an updated version of the application
`with a previous version of the application to determine what
`changes have been made. In either case,
`the versioning
`module 70 identifies new and/or revised data components,
`messages, and application logic, which are then written to
`one or more update files 58. These update files 58 can then
`be saved to an update files registry 42, which is preferably
`resident within the application developer registry 38 as
`Changes in existing Data definitions. This may
`depicted in FIGS. 1 and2. Alternatively, in the embodiment
`include, for example: changes in data components
`as shown in FIG.2, a revisions log 54 tracks the changes
`(e.g. to add or remove a datafield, of change a
`field type definition); persistent global
`made to the application source cade by the AD toolkit 52. It
`variables; or enumerations.
`will be appreciated that
`the versioning module 70 can
`Changes in Existing Messages used by the
`contain the revisions log 54 or the revisions log 54 can be a
`application. This may include, for example,
`separate module within the ADE 50.
`changes in message components (e.g. to add or
`remove a field, change a field type definition,
`[0031]
`Inaddition, an update script 60 can be generated to
`or change a mapping).
`control a terminal device to downloadandinstall the update
`Addition of features of the application. This
`may, for example, include additions or changes to
`file(s) 58, as will be described in greater detail below. The
`application logic, screens and/or globals;
`update script 60 can be savedtoascripts registry 40, which
`addition of new messages; and/or addition of data
`is preferably resident within the application developer reg-
`components or fields.
`istry 38 as depicted in FIG. 2.
`[0032]
`If desired, a script editor module or update script
`editor 56 can be provided to enable the application devel-
`oper to either compose the update script 60 manually, or to
`review and edit an auto-generated update script.
`[0033] The update script 60 may conveniently be devel-
`oped in a structured language, such as Java, JavaScript or
`XML, which thereby enables the device to access one or
`more back-end data sources, via the data network 6, during
`the update process. This enables the update script 60 to
`access and downloadthe update file(s) 58 as needed, during
`execution. This facilitates the asynchronous distribution of
`the update, because the update script 60 can “pull” the
`necessary update files 58 from the back-end data source(s)
`during execution. Furthermore, in certain implementations,
`the notification message for the upgrade could contain
`enough information to enable the RE in the terminal device
`to pull the application updatesitself.
`Versioning Schema
`[0034] As mentioned above, the versioning module 70
`automatically assigns a respective version number to the
`initial release and each update of an application. In the case
`of an initial release, any desired “initial” version number can
`be used. However, following its initial release, each subse-
`quent update is assigned an auto-generated version number
`[0038] As will be appreciated, this pattern can be contin-
`based on the type of changes made by that update. This
`ued for any numberof updates, each of which mayaffect any
`arrangement has a number of advantages. For example,
`one or more aspects of the application.
`It will also be
`because each version numberis assigned by the versioning
`appreciated that the version number schema can be extended
`module 70,
`consistency between version numbers
`is
`to provide finer granularity. For example, the Features field
`enforced. This means, for example, that a terminal device’s
`
`RE can use the version number of an update to determine could be replaced byaset of fields respectively indicating
`whether any other updates must be installed first. Another
`the addition of new data, messages or application logic. In
`advantage is that the RE of a terminal device can evaluate
`another example, a field could be added to the version
`
`the version numberof an update to detect potential compat-
`number to indicate whether or not the RE must be updated
`ibility issues, before attempting to install the update.
`before installation of the application update.
`
`TABLE 1
`
`Description
`
`Field
`
`Data
`
`Messages
`
`Features
`
`[0036] With this versioning schema, each field of the
`version number can be assigned an initial value (e.g. D=1,
`M=1, F=0) for the initial release of the application. There-
`after, for each update release, the versioning module auto-
`matically generates a respective version number for the
`update, by incrementing the value of the applicable fields.
`
`[0037] For example, consider an application which is
`released bearing the version number “1.1.0”, as described
`above. Following initial release, the application developer
`produces an application update, which modifies existing
`data fields, and adds new application logic. These changes
`will be reflected in the update’s version number by incre-
`menting the Data andIeatures fields. Thus, the first update’s
`version number will be 2.1.1. Following release of the first
`update, its version number (2.1.1) becomes the “current”
`version number of the application, against which the next
`released application update will be compared. Thus, for
`example, consider a second application update, which modi-
`fies the format of an existing message. This change will be
`reflected in the second update’s version number by incre-
`menting the Messages field, so that the second update’s
`version number will be 2.2.1.
`
`

`

`US 2006/0236083 Al
`
`Oct. 19, 2006
`
`It will also be appreciated that the present invention
`[0039]
`limited to applications per se. For example,
`the
`is not
`versioning number schema, and the updating methods
`described herein may equally be applied to the RE itself,
`thereby enabling controlled updating of the RE.
`
`Asynchronous Software Distribution
`
`[0040] Referring to FIG. 3, when the application devel-
`oper (AD) 36 issues a software release (of either an initial
`software load or an update), the versioning module assigns
`a version number, and stores the update script(s) and update
`file(s) in the AD registry 38. The AD 36 then sends an update
`notification message to the AG 2. The update notification
`message preferably includes a software identifier (SW-ID)
`uniquely identifying the application, the version number,
`and a link (e.g. a URL) to the update script stored in the
`scripts registry 40. When the AG 2 receives the update
`notification message from the AD 36, the AG 2 logs the
`update by storing the software ID, version numberandscript
`URLin the updates registry 12. Once the update has be
`logged by the AG 2, asynchronousdistribution to users’
`terminal devices can be accomplished in a numberof ways.
`Two representative distribution scenarios are described
`below with reference to FIGS. 4 and 5.
`
`[0041] FIG. 4 illustrates an asynchronous distribution
`scenario which is initiated by the AG 2, for example, in
`response to receipt of the update notification message from
`the AD 36. In this case, the AG 2 uses the software ID (e.g.
`contained in the update notification) to search the profiles
`registry 10. This search returns information (e.g. device IDs)
`identifying all terminal devices on which the application has
`been installed. The AG 2 can then generate and send a
`notification message to each of the identified terminal
`devices. The notification message may, for example, contain
`the software ID and version number of the update, as well
`as a link (e.g. a URL) to the update script stored in a scripts
`portion 40 of application developer registry 38.
`
`[0042] Uponreceiptof the notification message, the Runt-
`ime Environment (RE) can extract the software ID and
`version numberfrom the message, and use this information
`to determine whether or not
`the update can be safely
`installed on the terminal device. This evaluation may take
`the form of the following compatibility checks:
`
`[0043] Compare the “new” version number with the
`current version number saved in the terminal device
`registry (TD-REG) 28 to identify which aspects of the
`application are changed by the update. This function
`can, for example, be accomplished by field-wise sub-
`traction of the new and current version numbers. For
`
`example, consider a case in which the current version
`numberis “2.2.1”, and the new version number con-
`tainedin the notification message is “2.3.2”. Field-wise
`subtraction of the current version numberfrom the new
`
`version numberyields “0.1.1”, which indicates that the
`update involves: no changes to existing data compo-
`nents; a change to at least one existing message; and
`adds at least one new feature.
`
`[0044] Determine whether any intervening updates
`mustbe installed before the “current” update identified
`in the notification message. This can be done using the
`subtraction result calculated above. In particular, if any
`field of the subtraction result has a value greater than
`
`“1”, then there is at least one update that must be
`installed before the “current” update.
`
`In general, addition of new features will not create
`[0045]
`any compatibility issues. However, changes to existing data
`components or messages can have compatibility problems,
`because it there is a possibility that user-data saved in the
`memory may not be compatible with the revised data and/or
`message definitions. In such cases, installation of the update
`will require conversion of the saved data, and the ability to
`perform such conversion may be limited by the hardware
`capabilities of the terminal device. In addition, data conver-
`sion carries a risk that some data may becorruptedor lost,
`and thus it is possible that the user may prefer to not install
`the update, even if the required conversion function is within
`the abilities of the terminal device.
`
`[0046] Accordingly, if the RE determines that the update
`affects existing data components and/or existing messages,
`then the RE can provide a warning message to the user,
`indicating that an update is available but that its installation
`may cause a loss or corruption of data. The user can then
`choose whether or not
`the update should be installed.
`Alternatively, the update script defined by the application
`developer using the AD tool may perform data transforma-
`tions on incompatible updates.
`
`[0047] When(orif) the user elects to install the update, or
`if the RE determines that there are no compatibility issues
`(i.e. the update ONLYadds new features), the RE can initiate
`installation of the update by opening the link (URL) con-
`tainedin the update notification message, and thereby access
`and download the update script. Upon successful download
`of the update script from the scripts portion 40 of the
`application developer registry (AD-REG) 38, the RE can
`then launch the script, which then controls the downloading
`and installation of the update files from an update files
`portion 42 of the application developer registry 38.
`
`[0048] Upon successful installation of the update, the RE
`then updates the “current” version numberofthe application
`stored in the terminal device registry, using the update
`version numberreceived in the update notification message,
`and sends an update complete message to the AG 2. On
`receipt of the update complete message, the AG 2 updates
`the device profile with the new version number, to thereby
`indicate that
`the software update has been successfully
`installed on the terminal device 146.
`
`[0049] A limitation of the scenario depicted in FIG.4 is
`that the AG 2 initiates the update distribution scenario (e.g.
`in response to receipt of the update notification message
`from the AD 36) by sending notifications to every terminal
`device on which the affected software is installed. This can
`result in an undesirable flooding of notification messages
`into the network, which may tax wireless network band-
`width. In addition some terminal devices may not be con-
`nected when the AG sends the notifications, with the result
`that
`the “disconnected” terminal device could miss the
`
`update. These problems can be overcome by the asynchro-
`nousdistribution scenario described below with reference to
`FIG.5.
`
`In the distribution scenario illustrated in FIG. 5,
`[0050]
`asynchronous distribution is
`triggered by the terminal
`device. In the illustrated example, the triggering event is
`whenthe terminal device logs onto the AG 2, although other
`
`

`

`US 2006/0236083 Al
`
`Oct. 19, 2006
`
`events may also be used. For example, the RE could send a
`message to the AG 2 to check for updates in accordance with
`a predetermined schedule, or when an application is
`launched on the terminal device 148. In any case, the AG 2
`respondsto the terminal device 145 by accessing the termi-
`nal device’s profile to identify each application installed on
`the terminal device 14, and the current version number.
`This information is then used to search the updates registry
`12 to identify any logged update affecting the terminal
`device 144, and the corresponding update version numbers.
`Comparison between the current and update version num-
`bers then enables the AG 2 to determine whether there are
`any updates for the terminal device 145 which havenot yet
`been installed.
`
`[0051] The AG 2 then formulates an appropriate update
`notification message for each un-installed update, which is
`forwarded to the terminal device 145. Subsequent process-
`ing by the terminal device 146 to examine the update
`notification message andinstall updates follows the process
`described above with reference to FIG. 4,
`that
`is,
`the
`terminal device 146 checks compatibility, and then installs
`the update by opening a link (URL) to download a script
`from the AD-REG 38. Executing the script on the terminal
`device enables access and downloading of the updatesfiles
`stored in the AD-REG 38. Whenthe update is complete, the
`terminal device signals the completion of the update to the
`AG 2 by communicating to the AG the software ID and the
`version number. The AG then updates the profile in the
`profiles registry 10 by communicating the software ID and
`the version numberto the profiles registry 10.
`
`[0052] The embodiments of the invention described above
`are intended to be exemplary only. The scope of the inven-
`tion is therefore intended to be limited solely by the scope
`of the appendedclaims.
`
`[0053] A portion of the disclosure of this patent document
`may contain material that is subject to copyright protection.
`The copyright owner has no objection to the facsimile
`reproduction by anyone of the patent document or patent
`disclosure, as it appears in the Patent and Trademark Office
`patent file or records, but otherwise reserves all copyright.
`
`Weclaim:
`
`1. A methodof controlling asynchronousinstallation of a
`software update on a terminal device of a wireless network,
`the method comprising steps of:
`
`receiving an update notification message in respect of the
`software update, the update notification message com-
`prising:
`
`a software identifier uniquely identifying an application
`affected by the update;
`
`a version numberassociated with the software update;
`and
`
`an address of an update script on a data network
`accessible by the terminal device, the update script
`being adapted to install the software update on the
`terminal device;
`
`logging the update notification message in an updates
`registry; and
`
`forwarding a notification message to the terminal device,
`the notification message including the software identi-
`fier, the version numberandthe address of the update
`script.
`2. A method as claimed in claim 1, wherein the data
`networkis an Internet