WO2000074412A1 - Method and apparatus of downloading into a radio terminal - Google Patents

Method and apparatus of downloading into a radio terminal Download PDF

Info

Publication number
WO2000074412A1
WO2000074412A1 PCT/SE2000/001015 SE0001015W WO0074412A1 WO 2000074412 A1 WO2000074412 A1 WO 2000074412A1 SE 0001015 W SE0001015 W SE 0001015W WO 0074412 A1 WO0074412 A1 WO 0074412A1
Authority
WO
WIPO (PCT)
Prior art keywords
software
version
radio terminal
current version
capability
Prior art date
Application number
PCT/SE2000/001015
Other languages
French (fr)
Inventor
Hans Hall
Michael Eriksson
Gunnar Forsgren
Original Assignee
Telefonaktiebolaget Lm Ericsson (Publ)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget Lm Ericsson (Publ) filed Critical Telefonaktiebolaget Lm Ericsson (Publ)
Priority to AU49688/00A priority Critical patent/AU4968800A/en
Priority to DE10084626T priority patent/DE10084626T1/en
Priority to JP2001500583A priority patent/JP2003501907A/en
Publication of WO2000074412A1 publication Critical patent/WO2000074412A1/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1433—Saving, restoring, recovering or retrying at system level during software upgrading
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M1/00—Substation equipment, e.g. for use by subscribers
    • H04M1/72—Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection
    • H04M1/724—User interfaces specially adapted for cordless or mobile telephones
    • H04M1/72403—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality
    • H04M1/72406—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality by software upgrading or downloading
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/22—Processing or transfer of terminal data, e.g. status or physical capabilities
    • H04W8/24—Transfer of terminal data
    • H04W8/245—Transfer of terminal data from a network towards a terminal

Definitions

  • the invention is concerned with a method and apparatus of downloading software into a radio terminal, e.g. a mobile phone, and more particularly it is concerned with remotely upgrading of software.
  • Radio terminals are typically programmed with two pieces of the software, a first piece is hard coded in a programmable read only memory (PROM) and a second, upgradable piece is loaded into flash Programmable Read Only Memory (flash- PROM).
  • PROM programmable read only memory
  • flash- PROM flash Programmable Read Only Memory
  • the cellular telephone of this document includes two memories for storing software with one memory storing the current software and the second memory available for downloading new software.
  • the cellular telephone also includes a controller for loading the received software into the cellular telephone and for performing a checksum on the new software to control the process for downloading the new software into the phone. If the calculated checksum does not match the transmitted checksum, a retransmission of the new software is carried out.
  • the radio terminal In some situations it is extremely important that the radio terminal, especially if it is a mobile phone, is functioning, e.g. in situations of emergency calls fort the user's security.
  • the software therefore has to be very robust.
  • the so t jajg) ⁇ downloaded over a wireless or other network, and updated in the radio terminal, it is possible that a new version contains bugs and will perhaps not start properly or even not start at all. This might be the case when the software is written by a third party.
  • the software could be quite advanced, so it could be hard to tell, from a programmer's view, when the application really has been started, even if a checksum process for the downloading process itself has been carried out.
  • the checksum only controls if the program sent from the server still is in the same form when received by the radio terminal. If the program has bugs at the server, the same bugs are transferred to the radio terminal.
  • One object of the invention is a method and apparatus with which the user always knows if the current software in the radio terminal is functioning.
  • Another object of the invention is a method and apparatus of downloading and installing software into the radio terminal in such a way that the above object is fulfilled.
  • the method of the invention is therefore mainly characterized in that the capability of functioning of the current version of the software in the radio terminal is determined.
  • a possible existence of a new version of the software is then notified before or after said determination.
  • another version is selected to be downloaded. If according to said determination, the current version of the software does not work, another version of the software will be downloaded.
  • the current version of the software is preferably stored if it is a working version accordingl#. ⁇ S _ determination.
  • the selected version of the software is downloaded into the radio terminal to be the current version if there according to said determination or said notifying is a reason thereto.
  • the capability of functioning of the version of the software is then tested.
  • the current version might be the one which was in the terminal in the beginning, when the terminal was turned on, it can be another version or it can be a new version.
  • the result of said test is indicated in such a form that the capability of functioning of said tested version of the software can be determined.
  • the invention also covers the methods, wherein the step of notifying the existence of a new version is excluded as well as methods wherein this step is a necessary step.
  • One version can alternatively also be tested more than once, before another version is installed.
  • the apparatus of the invention is mainly characterized by means for determination the capability of functioning of the current version of the software in the radio terminal, notifying a possible existence of a new version of the software, selecting another version of software to be downloaded to replace the current version, storing the current version of the software, downloading another version of the software into the radio terminal to be the current version, testing the capability of functioning of the actual current version of the software, and of indicating the result of said test in such a form that the capability of functioning of said tested version of the software can be determined.
  • downloading means both remotely downloading and installing and reinstalling and reloading from another memory.
  • current version means the active version of software in the terminal. The other versions stored are inactive. It is pointed out that when a new version is available it is not necessary to download it immediately. If it is downloaded it is not necessary to start it immediately and it can be done later on, for example the next time the terminal is turned on.
  • the new version of the software can be a later version qfK g. software, a better version or an improved version. The idea is that the possible existence of a "new" version is notified so that it would be possible to download some version wished which is not already stored in the terminal.
  • the first thing that preferably is done is to determine if the current version of the software is functioning.
  • the determination can be done by identifying the presence or absence of an indicator that shows the software situation, and has been inserted in the terminal.
  • the indicator can be the result of said test, which is indicated by the presence or absence of a special indicator that can be handled by an object in the program.
  • the sign can be a persistent object. If the object exists, it is known that the previous boot for downloading a new version of the software or the installing of another version failed. Such an embodiment is also possible, wherein the absence of the sign means that the current version does not work. A version that is supposed to work is then installed and the method can be repeated immediately or later until the result of the test shows that the current version of the terminal is working. The method can also be repeated the next time the radio terminal is turned on, preferably each time the terminal is turned on.
  • Said other version of the software can be an earlier stored older version, preferably the foregoing version used.
  • the number of versions to be stored is selected by deleting one or more of the older versions, preferably according as new versions are installed.
  • Said other version selected to be downloaded can be a new version of the software if such a new version exist according to said notifying.
  • the other version of the software selected to be downloaded is an earlier stored older version, if the current active version is not working according to said determination and if there is no new version or the new version is not wished to be installed. If the persistent object exists when the system is booted up (or in the alternative embodiment, does not exist), it is a sign of that something went wrong the last time. As explained above, a working version is then installed to be the current version or the version is tested at least once more.
  • said other version of the software to be installed as the current version can be a basic version stored in ROM or can be downloaded from the manufacturer's server if none of the stored older versions or the current version works. In some embodiments, there might be an option that the basic version can always be installed, if wished.
  • the result of said test is indicated by the presence or absence of a special indicator to show the software situation in the mobile phone by means of which indication the capability of functioning of the current version of the software in the mobile phone is notified.
  • the indicator is removed, when according to the test, a working version of the software has been started.
  • said indicator is updated every time the functionality test is carried out to show the number of tests performed or to identify the current version of the software.
  • the other version of software selected to be downloaded can be selected on the basis of the updated indicator. If the indicator for example shows that the test has been carried out many times, it may be advisable to reload a basic version of the software.
  • the existing object is updated to give information of number of tests performed, of the actual version of the software etc. It can be decided in forward how many times a program shall be tested before another or a basio version shall be installed. If the indicator shows up more thaii ⁇ -ft ⁇ , it usually indicates that something else is wrong and in that case it might be preferable to install the basic first version mentioned above already in this stage. Something might for example have gone wrong when the program was stored in the memory. In case of a third party code, another program might have destroyed the actual version. The copying of files in the radio terminal is a further possible reason. It can therefore also be advisable to test the same program more than once before installing an earlier version or the basic version.
  • Said special indicator can be made in such a form that the actual version of the software can be identified and it can be in form of an ordinary file.
  • Each checkpoint can for example be a critical point per thread in the software or per terminal resource in the software that has to be passed.
  • a resource can be a network, a file system, sound, etc. Other alternatives are also possible and they are chosen depending on the program.
  • a checkpoint counter can be used for counting the checkpoints passed, the number of passed checkpoints can be checked, and the special sign can be deleted or updated if the number of checkpoints in the counter is equal to the number of checkpoints to be passed.
  • the current version can be stored by packing it with a compressing program to reduce the amount of space required on the phone, for example the zip program.
  • the problem with knowing whether a new version of the software has successfully started is thus solved in the invention by having an indicator, that either exists or not, depending on the functionality of the software.
  • the indicator will be deleted if the new version has started or in an alternative embodiment, is retained if the new version has started.
  • the radio terminal of the invention can be a computer or a mobile phone or the like.
  • Figure 1 illustrates a schematic view of an apparatus for downloading software into a radio terminal
  • FIG. 2 is a general flow scheme of the invention.
  • Figure 3 is a flow scheme of two examples of a procedure in accordance with the invention.
  • Figure 4 is a more detailed example of an embodiment of the invention.
  • Figure 5 is a detailed example of steps 5,8 and 9 of figure 2
  • FIG 1 there is illustrated an example of an apparatus for remotely downloading software into a radio terminal 10.
  • An update server processor 11 communicates with a network 12, which has a wireless communication link 13 to the radio terminal 10.
  • New versions of software are sent from the update server processor 11 via the network 12 and the wireless communication link 13 to the. radio terminal 10 through the antenna 14.
  • the terminal 10 in figure 1 contains a transceiver 15, a controller 16, a first memory 17 and a second memory 18.
  • the downloading of software from the update server 11 to the radio terminal 10 is carried out through the antenna 14 via the controller 15 to one of the memories.
  • the update server processor 11 can transmit a message to the radio terminal 10 under control of controller 16, which can either choose to download the new version or not in accordance with the invfefttft_ ⁇ 2
  • controller 16 can either choose to download the new version or not in accordance with the invfefttft_ ⁇ 2
  • the availability of new versions of software can also be known for the radio terminal 10 so that the radio terminal 10 ask the update server 11 about the existence of a new version.
  • the downloading itself is usually carried out by means of messages between server processor 11 and radio terminal 10.
  • the update processor 11 can also send older versions of the software to the radio terminal 10 in accordance with the invention.
  • a checkpoint counter can be used for counting the checkpoints passed, the number of passed checkpoints can be checked, and a special indicator can be created, deleted or updated in dependence of the number of checkpoints in the counter being equal to the number of checkpoints to be passed.
  • FIG 2 there is presented a detailed embodiment of the invention by means of a flow scheme.
  • One way of proceeding in the invention is by following the unbroken arrows. Alternative ways of proceeding are indicated with dotted arrows.
  • the alternatives can be selected in accordance with predefined criteria.
  • the method is carried out each time the terminal is turned on in accordance with reference number 1.
  • the first thing to do is to check if the current version of the software is a working version as indicated with step 2 in the figure.
  • This determination is in accordance with figure 1 carried out by means of the indication of a test result, the test having been carried out in accordance with step 8 and the indication in accordance with step 9 explained below.
  • the changing of information between the indication of the test result of step 9 and the checking of step 2 is indicated with a two-way arrow 3.
  • the indication of the test result can be performed in many ways. It can be a sign in form of a persistent object that is an ordinary file.
  • Step 4a can now be carried out, according to which another version that is supposed to work is installed. This version might be an earlier stored working version of the software or it can even be a basic version stored in ROM or it can even be downloaded from the server of the manufacturer. If the current version appears not to work, it can also be tested once more in steps 8 and 9. This alternative way is presented with a dotted arrow in the figure.
  • step 9 If the current version in accordance with the test result presentation of step 9 is a working version considered in step 2, then, it is in step 4b of figure 2 checked if there is a new version existing.
  • the alternative of not checking for a new version is indicated with a dotted arrow, and in that case the current version is started as indicated in step 5.
  • the capability of functioning of the current version is tested as indicated in step 8 when the software is started in accordance with checkpoints set in the program.
  • the first step in the invention is to download the new version, which then is started and tested and the test result is indicated as is described.
  • step 8 If there is no new* version (or it is not downloaded), the current version is started as indicated in step 5, and tested, as indicated in step 8.
  • step 6 If there is a new version, the current version is in figure 2 stored in step 6 and the new version is downloaded in step 7.
  • a functionality test is performed in connection with starting up as indicated in steps 5 and 8.
  • the capability of functioning of the downloaded or installed version of the software is tested as indicated in step 8 by setting a number of checkpoints the software should pass to start up correctly as a working version.
  • a checkpoint counter can be used for counting the checkpoints passed, the number of passed checkpoints can be checked, and the special sign can be deleted or updated if the number of checkpoints in the counter is equal to the number of checkpoints to be passed.
  • step 9 The result of the test is indicated in step 9 in such a form that the capability of functioning of a current version of the software always can be determined. Therefore, the result of said test is indicated by the presence or absence of a special indicator or sign to show the software situation in the terminal by means of which indication the capability of functioning of the current version of the software in the terminal is notified.
  • a new downloaded version or an installed version is tested in step 8 in connection with the starting of the program. There are, however, checkpoints embedded, and if these checkpoints are not passed, it shall appear in the presentation of the test result.
  • Figure 3 is a detailed flow scheme of two examples of how the method of the invention might proceed. It has to be pointed out that the downloading procedure depends on how the software in the terminal works and on the availability of new versions why the example is not intended to restrict the invention in anyway, but is shown for illustrating purposes only.
  • the terminal is turned on in accordance with reference number 100.
  • the' indication of the test result is performed in form of a persistent object, the existence of which shows that the current version of the software in the terminal is not working.
  • step 200 shows in the first example shown in figure 3 that the object exists, which means that something went wrong in the previous boot of the software.
  • Step 400 al can now be carried out, according to which another version that is supposed to work is installed.
  • This version might be an earlier stored working Ve_ftt ⁇ 0 of the software or it can even be a basic version stored in ROM or it can even be downloaded from the server of the manufacturer.
  • the downloaded version is started in step 500 whereby a new persistent object is created.
  • step 800:2 the downloaded version is tested and, since the test is passed, the persistent object is deleted in step 900:2.
  • step 200 the absence of a persistent object in the second example causes the program to execute step 400 b, whereby it is now checked if there is a new version existing. Since there is a new version, the current version is stored in step 600 and the new version is stored in step 700 to be the current version. The new version is started in step 800:1 hereby a persistent object is created and a number of checkpoints to be passed is set. In step 900:1, the new version is tested. As this version did not start up correctly, actions are taken in step 400:a2 to remedy the fault by for example by going to step 400al and by proceeding as was explained in the first example.
  • the user of the terminal may conclude, from an improper program behaviour, that something is wrong and restart the terminal by first turning it off and immediately thereafter turning it on again which effectively means to turn to step 100.
  • the program execution is terminated and control is handed over to the kernel whereby the number of passed checkpoints may be checked. Automatic actions may then be executed in response to a mismatch between the preset counter value and the number of passed checkpoints.
  • a low level interrupt in step 800, whereby the kernel may detect that the program execution has stopped or entered into a loop.
  • the kernel may then, in step 400 :a2, execute automatic actions to remedy the fault, e.g. restart the program execution from step 200.
  • the kernel can take control, the automatic actions in case of a faulty program can be varied.
  • the kernel may indicate to the user that a program error has been detected but that certain functions will be allowed.
  • the user may, e.g., be allowed to manage a local calendar whereas a network connection may not be allowed.
  • the kernel may determine which functions of the program that are working from an analysis of data compiled from the checkpoints having been passed.
  • figure 4 there is shown a detailed example of an embodiment of the invention.
  • the different steps corresponding to the steps of figure 2 have been indicated with corresponding reference numbers as in figure 2, except that in this embodiment, the upper indexes ' and " and "' is used to indicate this special embodiment.
  • Lower indexes a, b, c have been used to indicate alternative ways.
  • the different steps in themselves have been earlier explained in the text, and the intention with this figure is to show an example of an implementation of the invention.
  • the terminal is turned on in step 1 ' .
  • the existence of a new version is notified in step 4b'. If there is a new version, the current version is moved in step 6'. (If the current version is a working version it is stored, otherwise it is deleted).
  • the new version is loaded in step T and started in step 5a'. In connection with the starting there is created an object in step 9b' to indicate passing of the test performed in step 8'. The passing of the test is notified in step 2b' .
  • a restart according to step lb' is carried out if the test is not passed. In that case the capability of functioning of the current version is notified in step 2'.
  • step 2 if an object exist, it is notified in step 2" if this is the second try of booting the software. (This can be notified by updating the object in such a way in every test not being passed).
  • a basic version is reloaded in step 4a' , if in step 2" , it was notified that this was the second try of booting.
  • step 2 If step 2" showed that this was not the second try, it is notified in step 2'", if an old current version exists e.g. as indicated by the second memory 18 in figure 1 being loaded. This can be notified for example with creating an own object for this purpose. If this is the case, the old version is reloaded in step 4" and started and tested in step 5c' also comprising the creation of a new object. The passing of the test is notified in step 2c'. If the test is passed, the object is deleted in step 9d' and the current software version can be used.
  • step 2c' If it was notified in step 2c', that the test was not passed, the current object is updated in step 9e' to indicate in a subsequent execution of step 2", a second try. A restart, manual or automatical, is thereafter carried out in step lb'. If according to step 2'", there is no older working version, the basic version is reloaded in step 4a'. Program execution then. proceeds from steps 5b', 9b' by testing the reloaded basic version.
  • step 2' If according to step 2', there is no object, it means that the current version is working and it is starte " d in steps 5b'.
  • An object is created in step 9a', which is deleted in step 9c' if the test according to step 8a' is passed, after which the program is ready for use.
  • step lb' If the test is not passed in step 2a', a restart is carried out in step lb'.
  • step 4b' If there is no new version of software available according to step 4b', the next step is 2', which is explained above.
  • Figure 5 is a detailed example of a functionality test performed for the current software in the terminal in connection with the starting in step 5.
  • An object 52 is created in step 51 A.
  • the functionality of the version of the software is tested by setting a number of checkpoints Cl, C2, C3 called checkpoint 1, checkpoint 2 and checkpoint 3 in figure 5, the software should pass to start up correctly as a working version.
  • the number of checkpoints to be passed is defined in step 5 IB and stored in step 53 in the object 52.
  • the number of checkpoints can vary, but for illustrative purposes, there are three indicated in figure 5.
  • the number of checkpoints is contained in the program and copied to the object 52 at an early, phase of program execution.
  • Each checkpoint can for example be a critical point per thread in the software that has to be passed. In figure 5, only one thread is described. Other alternatives are also possible and they are chosen depending on the program.
  • a checkpoint counter 54 can be used in the object for counting the checkpoints passed, and each time a checkpoint is passed, the counter number is increased by one. In figure 5, there has been illustrated the case, wherein all three checkpoints has been passed.
  • the number of checkpoints passed is compared to the defined amount in step 55, and if the number of checkpoints defined in the object is equal to the number of checkpoints passed according to the counter, the test is passed as indicated by ⁇ tep'96' and the software is ready for use. If the number defined in the object is not equal to the number of checkpoints passed, in this embodiment, the old object is updated in step 57 or a new object is created.

Abstract

The invention is concerned with a method of downloading software into a radio terminal having at least two pieces of the software, one of which works as the current version. The capability of functioning of the current version of the software in the radio terminal is determined when the terminal is turned on. Another version of the software is downloaded if it is notified that there is a new version or if the current version does not work. If the current version is working, it is stored before a new version is downloaded. The capability of functioning of a current version of the software is tested before use. The result of the test is indicated in such a form that the capability of functioning of said tested version of the software can be determined. The invention is also concerned with a radio terminal comprising means to carry out the method of the invention.

Description

METHOD AND APPARATUS OF DOWNLOADING INTO A RADIO TERMINAL
TECHNICAL FIELD
The invention is concerned with a method and apparatus of downloading software into a radio terminal, e.g. a mobile phone, and more particularly it is concerned with remotely upgrading of software.
DESCRIPTION OF BACKGROUND ART
Radio terminals are typically programmed with two pieces of the software, a first piece is hard coded in a programmable read only memory (PROM) and a second, upgradable piece is loaded into flash Programmable Read Only Memory (flash- PROM). The software loaded in the flash-PROM may be periodically upgraded.
Usually, new versions of programs are made regularly and therefore there are methods and apparatuses to reprogram radio terminals, such as cellular telephones, remotely using a wireless communication link. It is advantageous if such methods retain the old software until the upgraded software has been tested and verified.
In the international patent application WO 98/38820 of the applicant, there is presented a method and radio apparatus for downloading software into a remotely located cellular telephone via wireless communication. The cellular telephone of this document includes two memories for storing software with one memory storing the current software and the second memory available for downloading new software. The cellular telephone also includes a controller for loading the received software into the cellular telephone and for performing a checksum on the new software to control the process for downloading the new software into the phone. If the calculated checksum does not match the transmitted checksum, a retransmission of the new software is carried out.
In some situations it is extremely important that the radio terminal, especially if it is a mobile phone, is functioning, e.g. in situations of emergency calls fort the user's security. The software therefore has to be very robust. When the so t jajg)^ downloaded over a wireless or other network, and updated in the radio terminal, it is possible that a new version contains bugs and will perhaps not start properly or even not start at all. This might be the case when the software is written by a third party. Moreover, the software could be quite advanced, so it could be hard to tell, from a programmer's view, when the application really has been started, even if a checksum process for the downloading process itself has been carried out. Even if a version is supposed to work, the program itself might have been corrupted in some way. The checksum only controls if the program sent from the server still is in the same form when received by the radio terminal. If the program has bugs at the server, the same bugs are transferred to the radio terminal.
If a version of the software that has been installed appears not to work, there should be some method to obtain a working version. There is also a problem with knowing when the application software has been started successfully.
SUMMARY OF THE INVENTION
One object of the invention is a method and apparatus with which the user always knows if the current software in the radio terminal is functioning.
Another object of the invention is a method and apparatus of downloading and installing software into the radio terminal in such a way that the above object is fulfilled.
The method of the invention is therefore mainly characterized in that the capability of functioning of the current version of the software in the radio terminal is determined. Optionally, a possible existence of a new version of the software is then notified before or after said determination. As a possible result of said determination and/or said notifying, another version is selected to be downloaded. If according to said determination, the current version of the software does not work, another version of the software will be downloaded. Before another version is downloaded, the current version of the software is preferably stored if it is a working version accordingl#.βS _ determination. The selected version of the software is downloaded into the radio terminal to be the current version if there according to said determination or said notifying is a reason thereto. The capability of functioning of the version of the software, that now is the current version in the radio terminal, is then tested. As is indicated above, the current version might be the one which was in the terminal in the beginning, when the terminal was turned on, it can be another version or it can be a new version. The result of said test is indicated in such a form that the capability of functioning of said tested version of the software can be determined.
Thus, the invention also covers the methods, wherein the step of notifying the existence of a new version is excluded as well as methods wherein this step is a necessary step.
One version can alternatively also be tested more than once, before another version is installed.
The apparatus of the invention is mainly characterized by means for determination the capability of functioning of the current version of the software in the radio terminal, notifying a possible existence of a new version of the software, selecting another version of software to be downloaded to replace the current version, storing the current version of the software, downloading another version of the software into the radio terminal to be the current version, testing the capability of functioning of the actual current version of the software, and of indicating the result of said test in such a form that the capability of functioning of said tested version of the software can be determined.
In this application the term "downloading" means both remotely downloading and installing and reinstalling and reloading from another memory. The term "current version" means the active version of software in the terminal. The other versions stored are inactive. It is pointed out that when a new version is available it is not necessary to download it immediately. If it is downloaded it is not necessary to start it immediately and it can be done later on, for example the next time the terminal is turned on. Furthermore, the new version of the software can be a later version qfK g. software, a better version or an improved version. The idea is that the possible existence of a "new" version is notified so that it would be possible to download some version wished which is not already stored in the terminal.
In the following there are presented some further, preferable characteristics for the method and apparatus of the invention.
When the radio terminal is turned on, the first thing that preferably is done is to determine if the current version of the software is functioning. The determination can be done by identifying the presence or absence of an indicator that shows the software situation, and has been inserted in the terminal. The indicator can be the result of said test, which is indicated by the presence or absence of a special indicator that can be handled by an object in the program.
The sign can be a persistent object. If the object exists, it is known that the previous boot for downloading a new version of the software or the installing of another version failed. Such an embodiment is also possible, wherein the absence of the sign means that the current version does not work. A version that is supposed to work is then installed and the method can be repeated immediately or later until the result of the test shows that the current version of the terminal is working. The method can also be repeated the next time the radio terminal is turned on, preferably each time the terminal is turned on.
Said other version of the software can be an earlier stored older version, preferably the foregoing version used. The number of versions to be stored is selected by deleting one or more of the older versions, preferably according as new versions are installed.
Said other version selected to be downloaded can be a new version of the software if such a new version exist according to said notifying. The other version of the software selected to be downloaded is an earlier stored older version, if the current active version is not working according to said determination and if there is no new version or the new version is not wished to be installed. If the persistent object exists when the system is booted up (or in the alternative embodiment, does not exist), it is a sign of that something went wrong the last time. As explained above, a working version is then installed to be the current version or the version is tested at least once more.
In one embodiment, said other version of the software to be installed as the current version can be a basic version stored in ROM or can be downloaded from the manufacturer's server if none of the stored older versions or the current version works. In some embodiments, there might be an option that the basic version can always be installed, if wished.
As indicated above, the result of said test is indicated by the presence or absence of a special indicator to show the software situation in the mobile phone by means of which indication the capability of functioning of the current version of the software in the mobile phone is notified.
When the capability of functioning of said installed/downloaded version of the software is presented by the absence of said special indicator and the opposite situation with the presence of said indicator, in one embodiment of the invention the indicator is removed, when according to the test, a working version of the software has been started. In another embodiment said indicator is updated every time the functionality test is carried out to show the number of tests performed or to identify the current version of the software.
The other version of software selected to be downloaded can be selected on the basis of the updated indicator. If the indicator for example shows that the test has been carried out many times, it may be advisable to reload a basic version of the software.
Thus, in one embodiment of the invention, instead of deleting the object when a test is passed and then creating a new one in the next test, the existing object is updated to give information of number of tests performed, of the actual version of the software etc. It can be decided in forward how many times a program shall be tested before another or a basio version shall be installed. If the indicator shows up more thaiiθ-ftδ, it usually indicates that something else is wrong and in that case it might be preferable to install the basic first version mentioned above already in this stage. Something might for example have gone wrong when the program was stored in the memory. In case of a third party code, another program might have destroyed the actual version. The copying of files in the radio terminal is a further possible reason. It can therefore also be advisable to test the same program more than once before installing an earlier version or the basic version.
Said special indicator can be made in such a form that the actual version of the software can be identified and it can be in form of an ordinary file.
The capability of functioning of said version of the software is tested by setting a number of checkpoints the software should pass to start up correctly as a working version. Each checkpoint can for example be a critical point per thread in the software or per terminal resource in the software that has to be passed. A resource can be a network, a file system, sound, etc. Other alternatives are also possible and they are chosen depending on the program. A checkpoint counter can be used for counting the checkpoints passed, the number of passed checkpoints can be checked, and the special sign can be deleted or updated if the number of checkpoints in the counter is equal to the number of checkpoints to be passed.
The current version can be stored by packing it with a compressing program to reduce the amount of space required on the phone, for example the zip program.
The problem with knowing whether a new version of the software has successfully started is thus solved in the invention by having an indicator, that either exists or not, depending on the functionality of the software. The indicator will be deleted if the new version has started or in an alternative embodiment, is retained if the new version has started.
With the method and apparatus of the invention, one can always be sure to have a working version and the system is very robust. The radio terminal of the invention can be a computer or a mobile phone or the like.
In the following, the invention is described more in detail by means of four flow schemes and a schematic view. It is pointed out that these descriptions only are examples of embodiments of the invention and that the details of the inventions can vary within the scope of the claims.
BRIEF DESCRIPTION OF THE DRAWINGS
Figure 1 illustrates a schematic view of an apparatus for downloading software into a radio terminal
Figure 2 is a general flow scheme of the invention.
Figure 3 is a flow scheme of two examples of a procedure in accordance with the invention.
Figure 4 is a more detailed example of an embodiment of the invention. Figure 5 is a detailed example of steps 5,8 and 9 of figure 2
DETAILED DESCRIPTION OF THE DRAWINGS
In figure 1, there is illustrated an example of an apparatus for remotely downloading software into a radio terminal 10. An update server processor 11 communicates with a network 12, which has a wireless communication link 13 to the radio terminal 10. New versions of software are sent from the update server processor 11 via the network 12 and the wireless communication link 13 to the. radio terminal 10 through the antenna 14. In addition to the normal functions of a radio terminal, the terminal 10 in figure 1 contains a transceiver 15, a controller 16, a first memory 17 and a second memory 18. The downloading of software from the update server 11 to the radio terminal 10 is carried out through the antenna 14 via the controller 15 to one of the memories.
When a new version of the software is available, the update server processor 11 can transmit a message to the radio terminal 10 under control of controller 16, which can either choose to download the new version or not in accordance with the invfefttft_ή2 The availability of new versions of software can also be known for the radio terminal 10 so that the radio terminal 10 ask the update server 11 about the existence of a new version. The downloading itself is usually carried out by means of messages between server processor 11 and radio terminal 10. The update processor 11 can also send older versions of the software to the radio terminal 10 in accordance with the invention.
When a new version has been downloaded in the terminal, it is considered as the current version, the capability of functioning of which is tested in connection with the starting of the program. The starting process of the software is followed up through a number of checkpoints the software should pass in a correct start. A checkpoint counter can be used for counting the checkpoints passed, the number of passed checkpoints can be checked, and a special indicator can be created, deleted or updated in dependence of the number of checkpoints in the counter being equal to the number of checkpoints to be passed.
In figure 2 there is presented a detailed embodiment of the invention by means of a flow scheme. One way of proceeding in the invention is by following the unbroken arrows. Alternative ways of proceeding are indicated with dotted arrows. In some embodiments, the alternatives can be selected in accordance with predefined criteria.
Preferably, the method is carried out each time the terminal is turned on in accordance with reference number 1. In figure 2, the first thing to do is to check if the current version of the software is a working version as indicated with step 2 in the figure. This determination, based on the checking, is in accordance with figure 1 carried out by means of the indication of a test result, the test having been carried out in accordance with step 8 and the indication in accordance with step 9 explained below. The changing of information between the indication of the test result of step 9 and the checking of step 2 is indicated with a two-way arrow 3. The indication of the test result can be performed in many ways. It can be a sign in form of a persistent object that is an ordinary file. If the current version, according to the test result indication of step 9, appearsHioPtβ* work, it means that something went wrong in the previous boot of the software. Step 4a can now be carried out, according to which another version that is supposed to work is installed. This version might be an earlier stored working version of the software or it can even be a basic version stored in ROM or it can even be downloaded from the server of the manufacturer. If the current version appears not to work, it can also be tested once more in steps 8 and 9. This alternative way is presented with a dotted arrow in the figure.
If the current version in accordance with the test result presentation of step 9 is a working version considered in step 2, then, it is in step 4b of figure 2 checked if there is a new version existing. The alternative of not checking for a new version is indicated with a dotted arrow, and in that case the current version is started as indicated in step 5. The capability of functioning of the current version is tested as indicated in step 8 when the software is started in accordance with checkpoints set in the program.
It is possible to download a new version of the software even if there is no earlier version in the radio terminal, but this embodiment is not illustrated. In that case, the first step in the invention is to download the new version, which then is started and tested and the test result is indicated as is described.
If there is no new* version (or it is not downloaded), the current version is started as indicated in step 5, and tested, as indicated in step 8.
The alternative of not downloading the new version of the software is indicated with a dotted arrow.
If there is a new version, the current version is in figure 2 stored in step 6 and the new version is downloaded in step 7.
For the new version downloaded in step 7 a functionality test is performed in connection with starting up as indicated in steps 5 and 8. The capability of functioning of the downloaded or installed version of the software is tested as indicated in step 8 by setting a number of checkpoints the software should pass to start up correctly as a working version. A checkpoint counter can be used for counting the checkpoints passed, the number of passed checkpoints can be checked, and the special sign can be deleted or updated if the number of checkpoints in the counter is equal to the number of checkpoints to be passed.
The result of the test is indicated in step 9 in such a form that the capability of functioning of a current version of the software always can be determined. Therefore, the result of said test is indicated by the presence or absence of a special indicator or sign to show the software situation in the terminal by means of which indication the capability of functioning of the current version of the software in the terminal is notified.
A new downloaded version or an installed version is tested in step 8 in connection with the starting of the program. There are, however, checkpoints embedded, and if these checkpoints are not passed, it shall appear in the presentation of the test result.
Figure 3 is a detailed flow scheme of two examples of how the method of the invention might proceed. It has to be pointed out that the downloading procedure depends on how the software in the terminal works and on the availability of new versions why the example is not intended to restrict the invention in anyway, but is shown for illustrating purposes only.
The terminal is turned on in accordance with reference number 100. In this embodiment, the' indication of the test result is performed in form of a persistent object, the existence of which shows that the current version of the software in the terminal is not working.
In figure 3, step 200 shows in the first example shown in figure 3 that the object exists, which means that something went wrong in the previous boot of the software. Step 400 al can now be carried out, according to which another version that is supposed to work is installed. This version might be an earlier stored working Ve_ftt ι 0 of the software or it can even be a basic version stored in ROM or it can even be downloaded from the server of the manufacturer. The downloaded version is started in step 500 whereby a new persistent object is created. In step 800:2, the downloaded version is tested and, since the test is passed, the persistent object is deleted in step 900:2.
Returning now to step 200, the absence of a persistent object in the second example causes the program to execute step 400 b, whereby it is now checked if there is a new version existing. Since there is a new version, the current version is stored in step 600 and the new version is stored in step 700 to be the current version. The new version is started in step 800:1 hereby a persistent object is created and a number of checkpoints to be passed is set. In step 900:1, the new version is tested. As this version did not start up correctly, actions are taken in step 400:a2 to remedy the fault by for example by going to step 400al and by proceeding as was explained in the first example.
Other alternatives are discussed in the following. For example, the user of the terminal may conclude, from an improper program behaviour, that something is wrong and restart the terminal by first turning it off and immediately thereafter turning it on again which effectively means to turn to step 100. It is also possible that the program execution is terminated and control is handed over to the kernel whereby the number of passed checkpoints may be checked. Automatic actions may then be executed in response to a mismatch between the preset counter value and the number of passed checkpoints. It is also possible to implement a low level interrupt in step 800, whereby the kernel may detect that the program execution has stopped or entered into a loop. The kernel may then, in step 400 :a2, execute automatic actions to remedy the fault, e.g. restart the program execution from step 200. If the kernel can take control, the automatic actions in case of a faulty program can be varied. For example the kernel may indicate to the user that a program error has been detected but that certain functions will be allowed. The user may, e.g., be allowed to manage a local calendar whereas a network connection may not be allowed. The kernel may determine which functions of the program that are working from an analysis of data compiled from the checkpoints having been passed. In figure 4, there is shown a detailed example of an embodiment of the invention. In the figure, the different steps corresponding to the steps of figure 2 have been indicated with corresponding reference numbers as in figure 2, except that in this embodiment, the upper indexes ' and " and "' is used to indicate this special embodiment. Lower indexes a, b, c have been used to indicate alternative ways. The different steps in themselves have been earlier explained in the text, and the intention with this figure is to show an example of an implementation of the invention.
The terminal is turned on in step 1 ' . The existence of a new version is notified in step 4b'. If there is a new version, the current version is moved in step 6'. (If the current version is a working version it is stored, otherwise it is deleted). The new version is loaded in step T and started in step 5a'. In connection with the starting there is created an object in step 9b' to indicate passing of the test performed in step 8'. The passing of the test is notified in step 2b' . A restart according to step lb' is carried out if the test is not passed. In that case the capability of functioning of the current version is notified in step 2'. In this embodiment, if an object exist, it is notified in step 2" if this is the second try of booting the software. (This can be notified by updating the object in such a way in every test not being passed). In figure 4, a basic version is reloaded in step 4a' , if in step 2" , it was notified that this was the second try of booting.
If step 2" showed that this was not the second try, it is notified in step 2'", if an old current version exists e.g. as indicated by the second memory 18 in figure 1 being loaded. This can be notified for example with creating an own object for this purpose. If this is the case, the old version is reloaded in step 4" and started and tested in step 5c' also comprising the creation of a new object. The passing of the test is notified in step 2c'. If the test is passed, the object is deleted in step 9d' and the current software version can be used.
If it was notified in step 2c', that the test was not passed, the current object is updated in step 9e' to indicate in a subsequent execution of step 2", a second try. A restart, manual or automatical, is thereafter carried out in step lb'. If according to step 2'", there is no older working version, the basic version is reloaded in step 4a'. Program execution then. proceeds from steps 5b', 9b' by testing the reloaded basic version.
If according to step 2', there is no object, it means that the current version is working and it is starte"d in steps 5b'. An object is created in step 9a', which is deleted in step 9c' if the test according to step 8a' is passed, after which the program is ready for use.
If the test is not passed in step 2a', a restart is carried out in step lb'.
If there is no new version of software available according to step 4b', the next step is 2', which is explained above.
Figure 5 is a detailed example of a functionality test performed for the current software in the terminal in connection with the starting in step 5. An object 52 is created in step 51 A. The functionality of the version of the software is tested by setting a number of checkpoints Cl, C2, C3 called checkpoint 1, checkpoint 2 and checkpoint 3 in figure 5, the software should pass to start up correctly as a working version. The number of checkpoints to be passed is defined in step 5 IB and stored in step 53 in the object 52. The number of checkpoints can vary, but for illustrative purposes, there are three indicated in figure 5. The number of checkpoints is contained in the program and copied to the object 52 at an early, phase of program execution.
Each checkpoint can for example be a critical point per thread in the software that has to be passed. In figure 5, only one thread is described. Other alternatives are also possible and they are chosen depending on the program. A checkpoint counter 54 can be used in the object for counting the checkpoints passed, and each time a checkpoint is passed, the counter number is increased by one. In figure 5, there has been illustrated the case, wherein all three checkpoints has been passed.
The number of checkpoints passed is compared to the defined amount in step 55, and if the number of checkpoints defined in the object is equal to the number of checkpoints passed according to the counter, the test is passed as indicated by ϊtep'96' and the software is ready for use. If the number defined in the object is not equal to the number of checkpoints passed, in this embodiment, the old object is updated in step 57 or a new object is created.

Claims

1. A method of downloading software into a radio terminal having at least two pieces of the software, one of which works as the current version, c h a r a c t e r i z e d by the steps of a) determining the capability of functioning of the current version of the software in the radio terminal, b) optionally, notifying a possible existence of a new version of the software, c) selecting another version of the software to be downloaded as a possible result of step a) or b), d) possibly storing the current version of the software, before a new version is downloaded, e) downloading of the other version of the software selected in step c) into the radio terminal to be the current version, f) testing the capability of functioning of the current version of the software of step a) or step e), and g) indicating the result of the test of step f) in such a form that the capability of functioning of said tested version of the software can be determined.
2. A method of downloading software into a radio terminal having at least two pieces of the software, one of which works as the current version, c h a r a c t e r i z e d by the steps of a) determining the capability of functioning of the current version of the software in the radio terminal, b) notifying a possible existence of a new version of the software, c) selecting another version of the software to be downloaded if the current version does not work or if there is a new version of the software available, d) storing the current version of the software, before a new version is downloaded, if the current version is a working version, e) downloading of the other version of the software selected in step c) into the radio terminal to be the current version, f) testing the capability of functioning of the current version of the software of step a) or step e), and g) indicating the result of the test of step f) in such a form that the capability of functioning of said tested version of the software can be determined.
3. A method of downloading software into a radio terminal having at least two pieces of the software, one of which works as the current version, c h a r a c t e r i z e d by the steps of a) determining the capability of functioning of the current version of the software in the radio terminal, c) selecting another version of the software to be downloaded if the current version does not work, e) downloading of the other version of the software selected in step b) into the radio terminal to be the current version, f) testing the capability of functioning of the current version of the software of step a) or step c), and g) indicating the result of the test of step d) in such a form that the capability of functioning of said tested version of the software can be determined.
4. Method of claim 1, c h a r a c t e r i z e d in that in step d), the current version is stored before a new version is downloaded if the current version according to step a) is a working version.
5. Method of claim 1, c h a r a c t e r i z e d by the steps of a) determining the capability of functioning of the current version of the software in the radio terminal, c) selecting another version of the software to be downloaded if the current version is not a working version according to step a), e) downloading of the other version of the software selected in step c) into the radio terminal to be the current version, f) testing the capability of functioning of the current version of the software of step e), and g) indicating the result of said test in such a form that the capability of functioning of said tested version of the software can be determined.
6. Method of claim 1, characterized by the steps of a) determining the capability of functioning of the current version of the software in the radio terminal, b) notifying a possible existence of a new version of the software, before or after step a), c) selecting another version of the software to be downloaded as a possible result of step a) or b), d) storing the current version of the software, before a new version is downloaded, if the current version according to step a) is a working version, e) downloading of the other version of the software selected in step c) into the radio terminal to be the current version, f) after step a), or e), testing the capability of functioning of the current version of the software of step a) or step e), and g) indicating' the result of said test in such a form that the capability of functioning of said tested version of the software can be determined.
7. Method of any of claims 1-6, characterized in that the method is repeated until there is a working version of the software in the radio terminal.
8. Method of any of claims 1-7, characterized in that the capability of functioning of a current version is tested and determined at least once.
9. Method of any of claims 1-8, characterized in that steps a) - g) are carried out each time the mobile phone is turned on.
10. Method of any of claims 1-9, characterized in that the number of versions stored in the radio terminal is selected by deleting one or more of the older versions.
11. Method of claim 10, characterized in that the number of versions stored in the radio terminal is selected by deleting one or more of the older versions, according as new versions are installed.
12. Method of any of claims 1 - 2, 4,6 -11, c h a r a c t e r i z e d in that in stejl- $)?§.?' other version selected to be downloaded is a new version of the software if such a new version exist according to step b).
13. Method of any of claims 1-11, characterized in that in step c) the other version of the software selected to be downloaded is an earlier stored older version, if according to step a), the current version is not working.
14. Method of any of claims 1-1 ^characterized in that in step c) the other version of the software selected to be downloaded is an earlier stored older version, preferably the foregoing working version stored, if according to step a), the current version is not working and according to step b), there is no new version available.
15. Method of any of claims 1-11, characterized in that in step c), the other version of the software selected to be downloaded is a basic version stored in ROM if that is the foregoing stored working version or if the method is repeated until that is the only working version of the software in the radio terminal.
16. Method of any of claims 1-11, characterized in that in step c), the other version of the software selected to be downloaded is downloaded from the manufacturer's server.
17. Method of any of claims 1-16, characerized in that in step g), the result of said test is indicated by the presence or absence of a special indicator to show the software situation in the mobile phone by means of which indicator the capability of functioning of the current version of the software in the mobile phone is notified in step a).
18. Method of claim 17, characterized in that in step g), the capability of functioning of said current version of the software is indicated by the absence of said special indicator and the opposite situation with the presence of said indicator, which is removed when, according to the test, a working versionl#|&2t software has been started.
19. Method of claim 17, characterized in that in step g), the capability of functioing of said current version of the software is indicated by the absence of said special indicator and the opposite situation with the presence of said indicator, which is updated every time step g) is carried out to show the number of tests performed.
20. Method of claim 19, characterized in that the other version of software selected to be downloaded is selected in step c) on the basis of the updated indicator.
21. Method of claim 17, characterized in that in step g), the capability of functioning of said current version of the software is indicated by the absence of said special indicator and the opposite situation with the presence of said indicator, which is updated every time step g) is carried out so that the current version of the software can be identified.
22. Method of any of claims 17-20,characterized in that said special indicator is made in such a form that the current version of the software can be identified.
23. Method of any of claims 17- 22, characterized in that said indicator is in form of an ordinary file.
24. Method of any of claims 1-23, characterized in that in step f), the capability of functioning of said current version of the software is tested by setting a number of checkpoints the software should pass to start up correctly as a working version.
25. Method of claim 24, characterized in that each checkpoint is madel_ -ft>____1 of one critical point per thread in the software or per terminal resource in the software that has to be passed.
26. Method of claim 24 or 25, characterized in that in the testing of step t), the following steps are included notifying each checkpoint passed with a checkpoint counter, checking the number of checkpoints, and indicating the tested version of software as a working version in step g) if the number of checkpoints in the checkpoint counter correspond to the number of checkpoints to be passed.
27. Method of any of claims 1-26, characterized in that in step d), the current version is stored by packing it with a compressing program to reduce the amount of space required on the phone.
28. Method of any of claims 1-27, characterized in that said radio terminal is a mobile phone.
29. Radio terminal having at least two pieces of software, one of which works as the current version, characterized by means for a) checking the capability of functioning of the current version of the software in the radio terminal, b) notifying a possible existence of a new version of the software, c) selecting another version of software to be downloaded to replace the current version, d) storing the current version of the software, e) downloading another version of the software into the radio terminal to be the current version, testing the capability of functioning of the current version of the software, and of g) indicating the result of said test in such a form that the capability of functioning of said tested version of the software can be checked.
30. Radio terminal of claim 29, characterized in that there is one or more working versions stored.
31. Radio terminal of claim 30, characterized in that one of the versions of the software stored is a basic version stored in ROM.
32. Radio terminal of any of claims 29-31,characerized by means for indicating the. result of said test by the presence or- absence of a special indicator to show the software situation in the radio terminal.
33. Radio terminal of claim 32, characterized by means for updating the indicator every time said test is repeated to show the number of tests performed.
34. Radio terminal of claim 32, characterized by means for creating said special indicator in such a form that the current version of the software can be identified.
35. Radio terminal of any of claims 29 - 34, c h a r a c.t e r i z e d by means for creating said indicator in form of an ordinary file.
36. Radio terminal of any of claims 29-35, characterized by means for testing the current version of the software by setting a number of checkpoints the software should pass to start up correctly as a working version.
37. Radio terminal of claim 36, characterized by a checkpoint counter notifying each checkpoint passed , means forchecking the number of checkpoints, and means for indicating the test result in accordance with the number of checkpoints passed.
38. Radio terminal of any of claims 29-37, characterized by means for storing the current version by packing it with a compressing program to reduce the amount of space required on the phone.
39. Radio terminal of any of claims 29-38, characterized in that it is a mobile phone.
PCT/SE2000/001015 1999-05-26 2000-05-19 Method and apparatus of downloading into a radio terminal WO2000074412A1 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
AU49688/00A AU4968800A (en) 1999-05-26 2000-05-19 Method and apparatus of downloading into a radio terminal
DE10084626T DE10084626T1 (en) 1999-05-26 2000-05-19 Method and arrangement for downloading into a radio terminal
JP2001500583A JP2003501907A (en) 1999-05-26 2000-05-19 Method and apparatus for downloading to wireless terminal

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
SE9901904-4 1999-05-26
SE9901904A SE516806C2 (en) 1999-05-26 1999-05-26 Methods for loading software into a radio terminal, such as a mobile phone, and associated radio terminal

Publications (1)

Publication Number Publication Date
WO2000074412A1 true WO2000074412A1 (en) 2000-12-07

Family

ID=20415736

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SE2000/001015 WO2000074412A1 (en) 1999-05-26 2000-05-19 Method and apparatus of downloading into a radio terminal

Country Status (6)

Country Link
JP (1) JP2003501907A (en)
CN (1) CN1147190C (en)
AU (1) AU4968800A (en)
DE (1) DE10084626T1 (en)
SE (1) SE516806C2 (en)
WO (1) WO2000074412A1 (en)

Cited By (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001067785A2 (en) * 2000-03-04 2001-09-13 Motorola Inc. Secure data download
EP1217856A2 (en) * 2000-12-20 2002-06-26 Telecom Italia Lab S.p.A. A mobile telephony operator random selection device and procedure for cellular phones
WO2002063903A2 (en) * 2000-12-21 2002-08-15 Nokia Corporation Method and apparatus for managing applications and data in a mobile device
EP1235447A2 (en) * 2001-02-26 2002-08-28 Kabushiki Kaisha Toshiba Radio communication apparatus and qualification method of the same
EP1253793A2 (en) * 2001-04-27 2002-10-30 Siemens Information and Communication Networks S.p.A. Communication system with a configurable interface for a peripheral unit, and configuration procedure of said interface
WO2003010662A2 (en) * 2001-07-26 2003-02-06 Kyocera Wireless Corporation System and method for field downloading a wireless communication device software code section
GB2388497A (en) * 2002-03-27 2003-11-12 Nec Corp Mobile communication terminal able to download and store additional dictionaries for temporary or permanent use
EP1395074A1 (en) * 2002-08-30 2004-03-03 Siemens Aktiengesellschaft Method for operation of a terminal in a radio communication system, radio communication system, terminal and confirmation unit for a radio communication system
US6918108B2 (en) 2001-07-26 2005-07-12 Kyocera Wireless Corp. System and method for field diagnosis of wireless communications device system software
EP1560446A1 (en) * 2004-01-27 2005-08-03 Research In Motion Limited Method and device for updating non-volatile memory items on a wireless device by checking and comparing a unique identifier item stored in said memory with a software identifier
EP1560447A1 (en) * 2004-01-27 2005-08-03 Research In Motion Limited Method and device for updating non-volatile memory items on a wireless device by checking and comparing a unique identifier item stored in said memory with a software identifier
US6961537B2 (en) 2001-08-10 2005-11-01 Kyocera Wireless Corp. System and method for peer-to-peer handset communication
US7027806B2 (en) 2001-07-26 2006-04-11 Kyocera Wireless, Corp. System and method for field downloading a wireless communications device software code section
GB2425193A (en) * 2005-04-14 2006-10-18 Nec Technologies Method for updating the software in a processor unit
US7159214B2 (en) 2001-07-26 2007-01-02 Kyocera Wireless Corp. System and method for compacting field upgradeable wireless communication device software code sections
US7184759B2 (en) 2001-07-26 2007-02-27 Kyocera Wireless Corp. Modular software components for wireless communication devices
US7222340B2 (en) 2004-01-27 2007-05-22 Research In Motion Limited Software-delivered dynamic persistent data
US7359698B2 (en) 2003-09-08 2008-04-15 Kyocera Wireless Corp. Systems and methods for enhanced over-the-air programming
US7386846B2 (en) 2001-07-26 2008-06-10 Kyocera Wireless Corp. System and method for the management of wireless communications device system software downloads in the field
US7743115B2 (en) * 2002-02-27 2010-06-22 Motorola, Inc. Software content downloading methods in radio communication networks
US8418162B2 (en) 2004-01-27 2013-04-09 Research In Motion Limited Network delivered dynamic persistent data
JP2016219033A (en) * 2001-04-03 2016-12-22 クゥアルコム・インコーポレイテッドＱｕａｌｃｏｍｍ Ｉｎｃｏｒｐｏｒａｔｅｄ Method and apparatus for network initiated uninstallation of application program over wireless network
US9554268B2 (en) 2001-07-26 2017-01-24 Kyocera Corporation System and method for updating persistent data in a wireless communications device

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100484288C (en) * 2003-12-22 2009-04-29 艾利森电话股份有限公司 Terminal software for downloading and upgrading wireless device over the air conveying
WO2006000122A1 (en) * 2004-06-23 2006-01-05 Zte Corporation A method of ensuring version matching in mobile communication system
JP2008299709A (en) * 2007-06-01 2008-12-11 Nec Corp Firmware updating system, network connection apparatus, firmware updating method, and program
CN102014419A (en) * 2009-09-09 2011-04-13 苏州工业园区科升通讯有限公司 Method for 2G and 3G network testing by adopting terminal mobile phone

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5155837A (en) * 1989-03-02 1992-10-13 Bell Communications Research, Inc. Methods and apparatus for software retrofitting
EP0767426A1 (en) * 1995-10-05 1997-04-09 Siemens Aktiengesellschaft Method for programming an apparatus
WO1997016938A1 (en) * 1995-10-30 1997-05-09 Nokia Telecommunications Oy Upgrading software in a mobile telephone
DE19741703A1 (en) * 1997-09-22 1999-04-01 Siemens Ag Loading operating software into mobile telephone
US5956481A (en) * 1997-02-06 1999-09-21 Microsoft Corporation Method and apparatus for protecting data files on a computer from virus infection

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5155837A (en) * 1989-03-02 1992-10-13 Bell Communications Research, Inc. Methods and apparatus for software retrofitting
EP0767426A1 (en) * 1995-10-05 1997-04-09 Siemens Aktiengesellschaft Method for programming an apparatus
WO1997016938A1 (en) * 1995-10-30 1997-05-09 Nokia Telecommunications Oy Upgrading software in a mobile telephone
US5956481A (en) * 1997-02-06 1999-09-21 Microsoft Corporation Method and apparatus for protecting data files on a computer from virus infection
DE19741703A1 (en) * 1997-09-22 1999-04-01 Siemens Ag Loading operating software into mobile telephone

Cited By (43)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001067785A3 (en) * 2000-03-04 2001-12-27 Motorola Inc Secure data download
WO2001067785A2 (en) * 2000-03-04 2001-09-13 Motorola Inc. Secure data download
GB2359908B (en) * 2000-03-04 2004-09-15 Motorola Inc Communication system architecture and method of controlling data download to subscriber equipment
EP1217856A2 (en) * 2000-12-20 2002-06-26 Telecom Italia Lab S.p.A. A mobile telephony operator random selection device and procedure for cellular phones
EP1217856A3 (en) * 2000-12-20 2003-05-02 Telecom Italia Lab S.p.A. A mobile telephony operator random selection device and procedure for cellular phones
WO2002063903A2 (en) * 2000-12-21 2002-08-15 Nokia Corporation Method and apparatus for managing applications and data in a mobile device
WO2002063903A3 (en) * 2000-12-21 2002-11-21 Nokia Corp Method and apparatus for managing applications and data in a mobile device
EP1235447A3 (en) * 2001-02-26 2003-04-23 Kabushiki Kaisha Toshiba Radio communication apparatus and qualification method of the same
EP1235447A2 (en) * 2001-02-26 2002-08-28 Kabushiki Kaisha Toshiba Radio communication apparatus and qualification method of the same
JP2016219033A (en) * 2001-04-03 2016-12-22 クゥアルコム・インコーポレイテッドＱｕａｌｃｏｍｍ Ｉｎｃｏｒｐｏｒａｔｅｄ Method and apparatus for network initiated uninstallation of application program over wireless network
EP1253793A2 (en) * 2001-04-27 2002-10-30 Siemens Information and Communication Networks S.p.A. Communication system with a configurable interface for a peripheral unit, and configuration procedure of said interface
EP1253793A3 (en) * 2001-04-27 2003-03-19 Siemens Information and Communication Networks S.p.A. Communication system with a configurable interface for a peripheral unit, and configuration procedure of said interface
US7159214B2 (en) 2001-07-26 2007-01-02 Kyocera Wireless Corp. System and method for compacting field upgradeable wireless communication device software code sections
WO2003010662A2 (en) * 2001-07-26 2003-02-06 Kyocera Wireless Corporation System and method for field downloading a wireless communication device software code section
EP1973035A1 (en) * 2001-07-26 2008-09-24 Kyocera Wireless Corp. System and method for the management of wireless communications device system software downloads in the field
WO2003012639A3 (en) * 2001-07-26 2003-12-24 Kyocera Wireless Corp System and method for compacting field upgradeable wireless communication device software code sections
WO2003010663A3 (en) * 2001-07-26 2003-12-24 Kyocera Wireless Corp System and method for the management of wireless communications device system software downloads in the field
WO2003010662A3 (en) * 2001-07-26 2003-12-24 Kyocera Wireless Corp System and method for field downloading a wireless communication device software code section
WO2003010664A3 (en) * 2001-07-26 2003-12-24 Kyocera Wireless Corp System and method for updating persistent data in a wireless communications device
US9554268B2 (en) 2001-07-26 2017-01-24 Kyocera Corporation System and method for updating persistent data in a wireless communications device
WO2003012639A2 (en) * 2001-07-26 2003-02-13 Kyocera Wireless Corporation System and method for compacting field upgradeable wireless communication device software code sections
WO2003010664A2 (en) * 2001-07-26 2003-02-06 Kyocera Wireless Corporation System and method for updating persistent data in a wireless communications device
US6918108B2 (en) 2001-07-26 2005-07-12 Kyocera Wireless Corp. System and method for field diagnosis of wireless communications device system software
US7386846B2 (en) 2001-07-26 2008-06-10 Kyocera Wireless Corp. System and method for the management of wireless communications device system software downloads in the field
US7184759B2 (en) 2001-07-26 2007-02-27 Kyocera Wireless Corp. Modular software components for wireless communication devices
WO2003010663A2 (en) * 2001-07-26 2003-02-06 Kyocera Wireless Corporation System and method for the management of wireless communications device system software downloads in the field
US7143407B2 (en) 2001-07-26 2006-11-28 Kyocera Wireless Corp. System and method for executing wireless communications device dynamic instruction sets
US7027806B2 (en) 2001-07-26 2006-04-11 Kyocera Wireless, Corp. System and method for field downloading a wireless communications device software code section
KR100913658B1 (en) * 2001-07-26 2009-08-24 키오세라 와이어리스 코포레이션 System and method for compacting field upgradeable wireless communication device software code sections
US6961537B2 (en) 2001-08-10 2005-11-01 Kyocera Wireless Corp. System and method for peer-to-peer handset communication
US7743115B2 (en) * 2002-02-27 2010-06-22 Motorola, Inc. Software content downloading methods in radio communication networks
GB2388497B (en) * 2002-03-27 2005-11-16 Nippon Electric Co Mobile communication terminal
GB2388497A (en) * 2002-03-27 2003-11-12 Nec Corp Mobile communication terminal able to download and store additional dictionaries for temporary or permanent use
WO2004021724A1 (en) * 2002-08-30 2004-03-11 Siemens Aktiengesellschaft Operating method for a terminal in a radio communication system, a radio communication system, terminal and acknowledgement unit for said radio communication system
EP1395074A1 (en) * 2002-08-30 2004-03-03 Siemens Aktiengesellschaft Method for operation of a terminal in a radio communication system, radio communication system, terminal and confirmation unit for a radio communication system
US7359698B2 (en) 2003-09-08 2008-04-15 Kyocera Wireless Corp. Systems and methods for enhanced over-the-air programming
US7222340B2 (en) 2004-01-27 2007-05-22 Research In Motion Limited Software-delivered dynamic persistent data
EP1560447A1 (en) * 2004-01-27 2005-08-03 Research In Motion Limited Method and device for updating non-volatile memory items on a wireless device by checking and comparing a unique identifier item stored in said memory with a software identifier
US8418162B2 (en) 2004-01-27 2013-04-09 Research In Motion Limited Network delivered dynamic persistent data
US8677341B2 (en) 2004-01-27 2014-03-18 Blackberry Limited Software-delivered dynamic persistent data
EP1560446A1 (en) * 2004-01-27 2005-08-03 Research In Motion Limited Method and device for updating non-volatile memory items on a wireless device by checking and comparing a unique identifier item stored in said memory with a software identifier
GB2425193B (en) * 2005-04-14 2007-10-17 Nec Technologies Method of software updating and related device
GB2425193A (en) * 2005-04-14 2006-10-18 Nec Technologies Method for updating the software in a processor unit

Also Published As

Publication number Publication date
SE9901904D0 (en) 1999-05-26
SE516806C2 (en) 2002-03-05
JP2003501907A (en) 2003-01-14
AU4968800A (en) 2000-12-18
DE10084626T1 (en) 2002-05-16
CN1147190C (en) 2004-04-21
CN1364390A (en) 2002-08-14
SE9901904L (en) 2000-11-27

Similar Documents

Publication Publication Date Title
WO2000074412A1 (en) Method and apparatus of downloading into a radio terminal
US7275153B2 (en) Booting and boot code update system using boot strapper code to select between a loader and a duplicate backup loader
US6615404B1 (en) Method and apparatus for downloading software into an embedded-system
US7971199B1 (en) Mobile device with a self-updating update agent in a wireless network
EP2229625B1 (en) Updating firmware of an electronic device
US8196130B2 (en) Tri-phase boot process in electronic devices
EP1142309B1 (en) Method and apparatus for operating system downloads in a set-top box environment
US7082549B2 (en) Method for fault tolerant updating of an electronic device
JP4482029B2 (en) Radio base station and radio base station operation method
EP1639468B1 (en) Network equipment and a method for monitoring the start up of a such an equipment
JP2003029997A (en) Software upgrading method in network environment and network device by the same
CN111562934A (en) Software system upgrading method based on hot patch, terminal and storage medium
KR100986487B1 (en) Mobile handset with a fault tolerant update agent
CN113821238A (en) Method and device for updating external firmware of intelligent wearable device, mobile terminal and medium
CN111273928B (en) Bootloader design method for self-upgrading
JP2005284902A (en) Terminal device, control method and control program thereof, host device, control method and control program thereof, and method, system, and program for remote updating
US11768669B2 (en) Installing application program code on a vehicle control system
CN115185958A (en) Radio frequency parameter updating system
CN106104474B (en) Method for updating firmware on low memory devices
CN113452550A (en) Information acquisition device, firmware updating method and system of embedded system device
CN110659052A (en) Method and system for updating system software in network equipment and readable storage medium
KR20010007066A (en) A method and apparatus for downloading software into an embedded system
CN116719681A (en) Fault testing system and testing method
CN115599405A (en) Docker-based extended service management method and device
KR20050060494A (en) Method for upgrading executable code of mobile communication terminal

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
ENP Entry into the national phase

Ref document number: 2001 500583

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 008107912

Country of ref document: CN

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

RET De translation (de og part 6b)

Ref document number: 10084626

Country of ref document: DE

Date of ref document: 20020516

WWE Wipo information: entry into national phase

Ref document number: 10084626

Country of ref document: DE

122 Ep: pct application non-entry in european phase