US20070245337A1 - Software-delivered dynamic persistent data - Google Patents

Software-delivered dynamic persistent data Download PDF

Info

Publication number
US20070245337A1
US20070245337A1 US11/735,019 US73501907A US2007245337A1 US 20070245337 A1 US20070245337 A1 US 20070245337A1 US 73501907 A US73501907 A US 73501907A US 2007245337 A1 US2007245337 A1 US 2007245337A1
Authority
US
United States
Prior art keywords
volatile memory
item
software
items
software load
Prior art date
Legal status (The legal status 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 status listed.)
Granted
Application number
US11/735,019
Other versions
US8677341B2 (en
Inventor
Edward Willis
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Malikie Innovations Ltd
Original Assignee
Individual
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 Individual filed Critical Individual
Priority to US11/735,019 priority Critical patent/US8677341B2/en
Publication of US20070245337A1 publication Critical patent/US20070245337A1/en
Assigned to RESEARCH IN MOTION LIMITED reassignment RESEARCH IN MOTION LIMITED ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: WILLIS, EDWARD SNOW, II
Assigned to BLACKBERRY LIMITED reassignment BLACKBERRY LIMITED CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: RESEARCH IN MOTION LIMITED
Application granted granted Critical
Publication of US8677341B2 publication Critical patent/US8677341B2/en
Assigned to MALIKIE INNOVATIONS LIMITED reassignment MALIKIE INNOVATIONS LIMITED ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: BLACKBERRY LIMITED
Expired - Fee Related legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • G06F8/65Updates
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/22Processing or transfer of terminal data, e.g. status or physical capabilities
    • H04W8/24Transfer of terminal data
    • H04W8/245Transfer of terminal data from a network towards a terminal

Definitions

  • the present invention relates to dynamic management of persistent data in the non-volatile memory of a wireless device, and in particular deals with a method and apparatus for dynamically updating the non-volatile memory when a new software load is added in a manner which allows the rollback to previous software loads if necessary.
  • Device specific, carrier specific and software-load specific persistent data is typically written to non-volatile memory at the time the device is built in the factory. If any error is introduced at this build time, or if a carrier's requirements change after the build time, or if new features are introduced in subsequent software loads which require updated persistent data, no mechanism exists to update these previously-released devices except for recalling them to a service outlet for reconfiguration.
  • the present invention allows persistent data items in non-volatile memory that require changes following the release of a device to the field to be rewritten by software during the first time the device is initialized following the loading of the new software.
  • the changes are made and implemented in such a manner that safe rollback semantics are achieved. In this way, if the user desires, loading an earlier software release will rollback the data to the previous state and thus negate the changes in the persistent data.
  • the present invention further supports the ability to change persistent data regardless of what release of the software is on the device. This may be implemented in situations where a bug is found to be caused by an incorrect value stored in the persistent data. In this case, regardless of the release, it is desirable to universally modify the persistent data.
  • the present invention further provides that changes to the persistent data can be implemented on a per-carrier basis. Alterations to persistent data can be implemented in a particular software load only for a particular carrier (or carriers). This allows carrier flexibility.
  • the present invention therefore provides a method of dynamically managing non-volatile memory items in a wireless device, said method comprising the steps of: checking the non-volatile memory items for a unique identifier item; if said unique identifier item exists, comparing an identifier stored within said unique identifier item with a software identifier located in software on said wireless device; and if said unique identifier item does not exist or if said identifier is different from said software identifier, performing the steps of: updating said non-volatile memory items; and writing said software identifier to said unique identifier item.
  • the present invention further provides a method for dynamically managing non-volatile memory items on a wireless device, said method allowing rollback to previous versions of software using said non-volatile memory items, said method comprising the steps of: checking the non-volatile memory items for a unique identifier item; if said unique identifier item exists, comparing an identifier stored within said unique identifier item with a software identifier located in software on said wireless device; and if said unique identifier item does not exist or if said identifier is different from said software identifier, performing the steps of: updating said non-volatile memory items, said updating step: creating a new non-volatile memory item rather than replacing an existing non-volatile memory item to facilitate rollback; retaining non-volatile memory items that have previously been created; and avoiding non-volatile memory items created by default or refurbished non-volatile memory files; and writing said software identifier to said unique identifier item, whereby said creating, retaining, and avoiding steps in said
  • FIG. 1 is a schematic diagram of the apparatus of the present invention.
  • FIG. 2 is a flow diagram of the method of the present invention.
  • NV file system When loading a new software load on a device, several considerations must be taken into account regarding the manipulation of persistent data in the non-volatile (NV) file system. It is important that the overall inspection and modification of the NV file system must occur only once following a software upgrade. This ensures that the software can set values and/or add new items during this first time initialization but that any changes to the NV made outside the context of Dynamic NV management do not unexpectedly reset in subsequent time periods.
  • any existing persistent data in the NV can be set to a given value and that new NV items (also referred to as NVs) can be added if necessary.
  • mobile station 100 is preferably a two-way wireless communication device.
  • mobile station 100 When mobile station 100 is enabled for two-way communication, it will incorporate a communication subsystem 111 , including both a receiver 112 and a transmitter 114 , as well as associated components such as one or more, preferably embedded or internal, antenna elements 118 , local oscillators (LOs) 113 , and a processing module such as a digital signal processor (DSP) 120 .
  • LOs local oscillators
  • DSP digital signal processor
  • a mobile station may require a removable user identity module (RUIM) or a subscriber identity module (SIM) card in order to operate on a CDMA network.
  • RUIM removable user identity module
  • SIM subscriber identity module
  • the SIM/RUIM interface 144 is normally similar to a card-slot into which a SIM/RUIM card can be inserted and ejected like a diskette or PCMCIA card.
  • mobile station 100 may send and receive communication signals over the network 119 .
  • Signals received by antenna 116 through communication network 119 are input to receiver 112 , which may perform such common receiver functions as signal amplification, frequency down conversion, filtering, channel selection and the like, and analog to digital (A/D) conversion.
  • receiver 112 may perform such common receiver functions as signal amplification, frequency down conversion, filtering, channel selection and the like, and analog to digital (A/D) conversion.
  • Mobile station 100 preferably includes a microprocessor 138 which controls the overall operation of the device. Communication functions are performed through communication subsystem 111 . Microprocessor 138 also interacts with further device subsystems such as the display 122 , non-volatile memory 124 , random access memory (RAM) 126 , auxiliary input/output (I/O) subsystems 128 , serial port 130 , keyboard 132 , speaker 134 , microphone 136 , a short-range communications subsystem 140 and any other device subsystems generally designated as 142 .
  • RAM random access memory
  • I/O auxiliary input/output
  • Operating system software used by the microprocessor 138 is preferably stored in a persistent store such as non-volatile memory 124 , which may instead be a read-only memory (ROM) or similar storage element (not shown).
  • ROM read-only memory
  • Those skilled in the art will appreciate that the operating system, specific device applications, or parts thereof, may be temporarily loaded into a volatile memory such as RAM 126 .
  • Received communication signals may also be stored in RAM 126 .
  • non-volatile memory 124 can be segregated into different areas for both programs storage 150 and non-volatile memory items 152 .
  • Microprocessor 138 in addition to its operating system functions, preferably enables execution of software applications on the mobile station.
  • a predetermined set of applications that control basic operations will normally be installed on mobile station 100 during manufacturing. Further applications may also be loaded onto the mobile station 100 through the network 119 , an auxiliary I/O subsystem 128 , serial port 130 , short-range communications subsystem 140 or any other suitable subsystem 142 , and installed by a user in the RAM 126 or preferably non-volatile memory 124 for execution by the microprocessor 138 .
  • Such flexibility in application installation increases the functionality of the device and may provide enhanced on-device functions, communication-related functions, or both. However, when software is upgraded, often non-volatile memory items 152 need to be modified dynamically.
  • step 10 the software checks, at step 10 , to see if the OS version number is written into the NV file system. If the OS version number does appear in the NV file system, the method of the present invention next moves to step 12 , and the OS version number in the NV file system is compared with the current version number found in the software load.
  • step 14 If the OS version does not appear in the NV file system, or if it does not match the current version number found in the NV file system, the method of the present invention next moves to step 14 and performs any dynamic management required for the NV items and values. Otherwise, if the two OS version numbers correspond with each other the method moves to step 16 and ends.
  • step 18 the method writes the current OS version to the predetermined location in the NV file system and ends the process in step 20 .
  • the writing of the current OS version number into the NV file system is performed in step 18 at the end of the updating algorithm. This safeguards the NV file system to ensure that a complete update is performed. If a complete update is not performed, for example if the device has reset or otherwise died before the dynamic NV manipulation have been completed, the software will try to manipulate the NV file system the next time the device is turned on. This is because the same algorithm will run as described above and will find that the NV item related to the OS version number differs from the current OS version number found in the software. At the end of a successful manipulation of the NV file system, the OS version number is updated and prevents the algorithm from running again until a new software load is loaded.
  • the key is that the dynamic management of the NVs must be performed completely. Based on the algorithm above, dynamic management occurs when the OS version number found in the NV item either does not exist or exists but has the wrong number. The other scenarios in this case are if there is a failed attempt to write to an NV or a failed attempt to read. In these cases, error messages are written and the initialization is ended without writing the new OS version to the NV item. This ensures that on the next initialization, the software will again try to complete the dynamic management of the NV.
  • An extension of the above algorithm is to query the System ID for the home network of the device and, based on the value found in this NV item, to manipulate other NV items based on the value found in the home system identification (SID) NV.
  • SID home system identification
  • NV memory items As used herein, traditional management of NV memory items indicates management through service recalls and configuration when the device is built. Dynamic management indicates management of NV items at the mobile device such as during the changing of software loads.
  • a further desired feature for NV file system management is the dynamic rollback of the NV to previous software versions.
  • a rollback scheme is proposed for the present invention.
  • Rule 1 If Rule 1 is not observed, a risk exists that dynamically managed NV settings would be overwritten at the device build time or at the factory or store device configuration time. If an NV is managed under dynamic management, it should be removed from management of any existing NV management scheme.
  • NV should be considered to be under dynamic management for all carriers from that point forward.
  • the NV should be defined and implemented with correct behaviours for those other carriers and software and that NV should be removed from any other NV management scheme.
  • Rule 2 exists to ensure that values for older loads do not get overwritten by newer loads in the case where a user may revert back to the older load. If the value is overwritten and an older load is reloaded, then a defect could occur in the software. Conversely, if a new NV is added for a new load, then the old load can still be loaded back onto the wireless device while maintaining its functionalities since the original NV has not been overwritten.
  • N1 In this load, N1 must have a value of V1. If it does not, a bug will surface in load 1 .
  • a second load alters the configuration of load 1 by adding a new NV, defined below as N3, with a value of V3.
  • N3 is added as a dynamic NV and is not managed in any other way pursuant to Rule 1.
  • N1 In a third load, the value for N1 needs to be changed to some new value V4.
  • Rule 2 indicates that we should not change the value of L1, but rather to add a new NV with the desired value and use the new NV instead of the old one.
  • L3 adds a new NV item N4 with the value V4.
  • N4 is thus under dynamic management and not managed in any other way pursuant to Rule 1.
  • the upgrade from L2 to L3 looks like this: TABLE 3 L2 L3 N1 V1 N1 V1 N2 V2 N2 V2 N3 V3 N3 N4 N/A N4 V4
  • N1 is not removed from the NV file system pursuant to Rule 3. From L3, either load 1 or load 2 could be reloaded onto the device and would still work because the previous versions of the NV file system still exist below the changes made for L3.
  • a downgrade to L1 is possible because N1 and N2 have the correct values for load 1 . While N3 and N4 appear in the NV file system, they will not be accessed by load 1 . Also, a downgrade from load 3 to load 2 is possible since all of the values of N1, N2 and N3 are correct in load 2 .
  • a further addition to ensure compatibility for dynamic management tools is to create a mapping for all NV requests not originating within the device software.
  • This mapping takes the intent of Rule 2, namely the new NV items are intended to completely replace old NV items. Once replaced, it is the intent that all uses of the old NV be replaced by uses of the new NV.
  • the dynamic management tools can ask for items by number.
  • the map may be changed in the software load to ensure that all of the values used by the load are mapped to the correct NV item.
  • the above therefore defines a method for updating the persistent data in the non-volatile memory dynamically, and further discusses an implementation which allows the rollback to previous software loads if desired by the user.

Abstract

A method and apparatus for dynamically managing non-volatile memory items in a wireless device, the method comprising the steps of: checking the non-volatile memory items for a unique identifier item; if the unique identifier item exists, comparing an identifier stored within the unique identifier item with a software identifier located in software on the wireless device; and if the unique identifier item does not exist or if the identifier is different from the software identifier, performing the steps of: updating the non-volatile memory items; and writing the software identifier to the unique identifier item. The method may further include a rollback scheme for previous software versions.

Description

    RELATED APPLICATIONS
  • The present application is a continuation of U.S. patent application Ser. No. 10/765,512, entitled “Software Delivered Dynamic Persistent Data” filed Jan. 27, 2004. The full disclosure, including the drawings, of U.S. patent application Ser. No. 10/765,512 are incorporated herein by reference.
  • FIELD OF THE INVENTION
  • The present invention relates to dynamic management of persistent data in the non-volatile memory of a wireless device, and in particular deals with a method and apparatus for dynamically updating the non-volatile memory when a new software load is added in a manner which allows the rollback to previous software loads if necessary.
  • BACKGROUND TO THE INVENTION
  • Device specific, carrier specific and software-load specific persistent data is typically written to non-volatile memory at the time the device is built in the factory. If any error is introduced at this build time, or if a carrier's requirements change after the build time, or if new features are introduced in subsequent software loads which require updated persistent data, no mechanism exists to update these previously-released devices except for recalling them to a service outlet for reconfiguration.
  • Further, even if a means for writing updated data to a wireless device existed, a potential problem is introduced for backward compatibility. A typical situation in which backward compatibility is required would be if the user has received a software update for their wireless device and then subsequently has downgraded their software load to the previous release. In this case, the new persistent data which is presented with the updated software load may not be supported by the previous software load, causing potential software errors on the wireless device.
  • SUMMARY OF THE INVENTION
  • The present invention allows persistent data items in non-volatile memory that require changes following the release of a device to the field to be rewritten by software during the first time the device is initialized following the loading of the new software. The changes are made and implemented in such a manner that safe rollback semantics are achieved. In this way, if the user desires, loading an earlier software release will rollback the data to the previous state and thus negate the changes in the persistent data.
  • The present invention further supports the ability to change persistent data regardless of what release of the software is on the device. This may be implemented in situations where a bug is found to be caused by an incorrect value stored in the persistent data. In this case, regardless of the release, it is desirable to universally modify the persistent data.
  • The present invention further provides that changes to the persistent data can be implemented on a per-carrier basis. Alterations to persistent data can be implemented in a particular software load only for a particular carrier (or carriers). This allows carrier flexibility.
  • The present invention therefore provides a method of dynamically managing non-volatile memory items in a wireless device, said method comprising the steps of: checking the non-volatile memory items for a unique identifier item; if said unique identifier item exists, comparing an identifier stored within said unique identifier item with a software identifier located in software on said wireless device; and if said unique identifier item does not exist or if said identifier is different from said software identifier, performing the steps of: updating said non-volatile memory items; and writing said software identifier to said unique identifier item.
  • The present invention further provides a method for dynamically managing non-volatile memory items on a wireless device, said method allowing rollback to previous versions of software using said non-volatile memory items, said method comprising the steps of: checking the non-volatile memory items for a unique identifier item; if said unique identifier item exists, comparing an identifier stored within said unique identifier item with a software identifier located in software on said wireless device; and if said unique identifier item does not exist or if said identifier is different from said software identifier, performing the steps of: updating said non-volatile memory items, said updating step: creating a new non-volatile memory item rather than replacing an existing non-volatile memory item to facilitate rollback; retaining non-volatile memory items that have previously been created; and avoiding non-volatile memory items created by default or refurbished non-volatile memory files; and writing said software identifier to said unique identifier item, whereby said creating, retaining, and avoiding steps in said updating step allow rollback to previous versions of software on said wireless device.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • The present invention will be better understood with reference to the drawings, in which:
  • FIG. 1 is a schematic diagram of the apparatus of the present invention; and
  • FIG. 2 is a flow diagram of the method of the present invention.
  • DETAILED DESCRIPTION OF THE INVENTION
  • When loading a new software load on a device, several considerations must be taken into account regarding the manipulation of persistent data in the non-volatile (NV) file system. It is important that the overall inspection and modification of the NV file system must occur only once following a software upgrade. This ensures that the software can set values and/or add new items during this first time initialization but that any changes to the NV made outside the context of Dynamic NV management do not unexpectedly reset in subsequent time periods.
  • It is further important that during the one-time execution of the NV file system modification, any existing persistent data in the NV can be set to a given value and that new NV items (also referred to as NVs) can be added if necessary.
  • Referring to the drawings, mobile station 100 is preferably a two-way wireless communication device.
  • Where mobile station 100 is enabled for two-way communication, it will incorporate a communication subsystem 111, including both a receiver 112 and a transmitter 114, as well as associated components such as one or more, preferably embedded or internal, antenna elements 118, local oscillators (LOs) 113, and a processing module such as a digital signal processor (DSP) 120. As will be apparent to those skilled in the field of communications, the particular design of the communication subsystem 111 will be dependent upon the communication network in which the device is intended to operate.
  • A mobile station may require a removable user identity module (RUIM) or a subscriber identity module (SIM) card in order to operate on a CDMA network. The SIM/RUIM interface 144 is normally similar to a card-slot into which a SIM/RUIM card can be inserted and ejected like a diskette or PCMCIA card.
  • When required network registration or activation procedures have been completed, mobile station 100 may send and receive communication signals over the network 119. Signals received by antenna 116 through communication network 119 are input to receiver 112, which may perform such common receiver functions as signal amplification, frequency down conversion, filtering, channel selection and the like, and analog to digital (A/D) conversion.
  • Mobile station 100 preferably includes a microprocessor 138 which controls the overall operation of the device. Communication functions are performed through communication subsystem 111. Microprocessor 138 also interacts with further device subsystems such as the display 122, non-volatile memory 124, random access memory (RAM) 126, auxiliary input/output (I/O) subsystems 128, serial port 130, keyboard 132, speaker 134, microphone 136, a short-range communications subsystem 140 and any other device subsystems generally designated as 142.
  • Operating system software used by the microprocessor 138 is preferably stored in a persistent store such as non-volatile memory 124, which may instead be a read-only memory (ROM) or similar storage element (not shown). Those skilled in the art will appreciate that the operating system, specific device applications, or parts thereof, may be temporarily loaded into a volatile memory such as RAM 126. Received communication signals may also be stored in RAM 126.
  • As shown, non-volatile memory 124 can be segregated into different areas for both programs storage 150 and non-volatile memory items 152.
  • Microprocessor 138, in addition to its operating system functions, preferably enables execution of software applications on the mobile station. A predetermined set of applications that control basic operations will normally be installed on mobile station 100 during manufacturing. Further applications may also be loaded onto the mobile station 100 through the network 119, an auxiliary I/O subsystem 128, serial port 130, short-range communications subsystem 140 or any other suitable subsystem 142, and installed by a user in the RAM 126 or preferably non-volatile memory 124 for execution by the microprocessor 138. Such flexibility in application installation increases the functionality of the device and may provide enhanced on-device functions, communication-related functions, or both. However, when software is upgraded, often non-volatile memory items 152 need to be modified dynamically.
  • Reference is now made to FIG. 2. In order to implement an NV update, it is possible to write an operating system version number into the NV file system. Then when a software load change occurs, the software checks, at step 10, to see if the OS version number is written into the NV file system. If the OS version number does appear in the NV file system, the method of the present invention next moves to step 12, and the OS version number in the NV file system is compared with the current version number found in the software load.
  • If the OS version does not appear in the NV file system, or if it does not match the current version number found in the NV file system, the method of the present invention next moves to step 14 and performs any dynamic management required for the NV items and values. Otherwise, if the two OS version numbers correspond with each other the method moves to step 16 and ends.
  • From step 14 the method next moves to step 18. In step 18 the method writes the current OS version to the predetermined location in the NV file system and ends the process in step 20.
      • The above algorithm can therefore be summarized as:
  • Check if the OS version number appears in the NV file system.
      • If the OS version number appears in the NV file system, compare it with the current software version number.
      • If the OS version number does not appear in the NV file system, or if it does appear but does not match the current version number of the new software, then:
        • Do any required dynamic management of the NV items and values.
        • Write the current OS version number to the appropriate NV item.
  • As will be realized by one skilled in the art, other identifying data besides the OS version number could be used to track software updates. This could include any identifier placed within the software that changes between software loads.
  • By performing the above algorithm, subsequent resets without changing software loads will not result in further manipulation of the NV file system. This allows changes to NV values outside the context of dynamic NV management and ensure that those values will not be reset to previous values as a side effect of resetting the device.
  • The writing of the current OS version number into the NV file system is performed in step 18 at the end of the updating algorithm. This safeguards the NV file system to ensure that a complete update is performed. If a complete update is not performed, for example if the device has reset or otherwise died before the dynamic NV manipulation have been completed, the software will try to manipulate the NV file system the next time the device is turned on. This is because the same algorithm will run as described above and will find that the NV item related to the OS version number differs from the current OS version number found in the software. At the end of a successful manipulation of the NV file system, the OS version number is updated and prevents the algorithm from running again until a new software load is loaded.
  • For error handling purposes, the key is that the dynamic management of the NVs must be performed completely. Based on the algorithm above, dynamic management occurs when the OS version number found in the NV item either does not exist or exists but has the wrong number. The other scenarios in this case are if there is a failed attempt to write to an NV or a failed attempt to read. In these cases, error messages are written and the initialization is ended without writing the new OS version to the NV item. This ensures that on the next initialization, the software will again try to complete the dynamic management of the NV.
  • The above provides the additional benefit that it is easy to implement carrier-specific dynamic NV manipulations. An extension of the above algorithm is to query the System ID for the home network of the device and, based on the value found in this NV item, to manipulate other NV items based on the value found in the home system identification (SID) NV.
  • As used herein, traditional management of NV memory items indicates management through service recalls and configuration when the device is built. Dynamic management indicates management of NV items at the mobile device such as during the changing of software loads.
  • A further desired feature for NV file system management is the dynamic rollback of the NV to previous software versions. In the situation where a user loads a new software version and decides that they want to revert back to an old version, if the NV file system has been changed, the old version of the software may be relying on an NV item that has been modified and thus may not work correctly. To overcome this, a rollback scheme is proposed for the present invention.
  • In order to avoid difficulties in rolling back the NV, the following rules should be followed:
    • Rule 1: An NV should not be both under dynamic management and traditional management. For clarity, an NV item should be set/created in software as part of a dynamic NV management scheme or it should managed in some other manner but not both.
    • Rule 2: The addition of a new NV should be favoured over changing the value of an existing NV. This allows backward compatibility by not changing the values of the present NVs to newer values.
    • Rule 3: NVs cannot be deleted from the software once a load which creates that NV has been deployed.
  • If Rule 1 is not observed, a risk exists that dynamically managed NV settings would be overwritten at the device build time or at the factory or store device configuration time. If an NV is managed under dynamic management, it should be removed from management of any existing NV management scheme.
  • The above also applies on a per carrier basis. If a particular carrier needs an NV setting to change in value for the next load, then that NV should be considered to be under dynamic management for all carriers from that point forward. The NV should be defined and implemented with correct behaviours for those other carriers and software and that NV should be removed from any other NV management scheme.
  • Once an NV is handled in dynamic management, it can never go back to any other management scheme. This avoids problems with the loading of various software loads and the changing between the software loads.
  • Rule 2 exists to ensure that values for older loads do not get overwritten by newer loads in the case where a user may revert back to the older load. If the value is overwritten and an older load is reloaded, then a defect could occur in the software. Conversely, if a new NV is added for a new load, then the old load can still be loaded back onto the wireless device while maintaining its functionalities since the original NV has not been overwritten.
  • The above is better illustrated with an example. For simplicity's sake, the example below assumes that there are only two NV items initially defined as N1 and N2 with values V1 and V2. A first software load, defined as L1, illustrates the last load created that has no dynamic NV support. This load is illustrated in the table below.
    TABLE 1
    L1
    N1 V1
    N2 V2
  • In this load, N1 must have a value of V1. If it does not, a bug will surface in load 1.
  • A second load alters the configuration of load 1 by adding a new NV, defined below as N3, with a value of V3. N3 is added as a dynamic NV and is not managed in any other way pursuant to Rule 1. When the device is upgraded from L1 to L2, the NV file system transition is as follows:
    TABLE 2
    L1 L2
    N1 V1 N1 V1
    N2 V2 N2 V2
    N3 V3 N3 V3
  • From the table above, it can be seen that a downgrade to the first load L1 is fine since the first and second NV items N1 and N2 have the values that load 1 expects for them.
  • In a third load, the value for N1 needs to be changed to some new value V4. Rule 2 indicates that we should not change the value of L1, but rather to add a new NV with the desired value and use the new NV instead of the old one. In this case, L3 adds a new NV item N4 with the value V4. N4 is thus under dynamic management and not managed in any other way pursuant to Rule 1. The upgrade from L2 to L3 looks like this:
    TABLE 3
    L2 L3
    N1 V1 N1 V1
    N2 V2 N2 V2
    N3 V3 N3 V3
    N4 N/A N4 V4
  • Despite the fact that the third load has no need for N1 anymore, N1 is not removed from the NV file system pursuant to Rule 3. From L3, either load 1 or load 2 could be reloaded onto the device and would still work because the previous versions of the NV file system still exist below the changes made for L3. A downgrade to L1 is possible because N1 and N2 have the correct values for load 1. While N3 and N4 appear in the NV file system, they will not be accessed by load 1. Also, a downgrade from load 3 to load 2 is possible since all of the values of N1, N2 and N3 are correct in load 2.
  • If a user has not implemented load 2 but moves to load 3 directly from load 1, the upgrade will add values for N3 and N4 and will look like the following table:
    TABLE 4
    L1 L3
    N1 V1 N1 V1
    N2 V2 N2 V2
    N3 N/A N3 V3
    N4 N/A N4 V4
  • A further addition to ensure compatibility for dynamic management tools is to create a mapping for all NV requests not originating within the device software. This mapping takes the intent of Rule 2, namely the new NV items are intended to completely replace old NV items. Once replaced, it is the intent that all uses of the old NV be replaced by uses of the new NV. In keeping with that intent, the dynamic management tools can ask for items by number.
  • When a new software load is added, the map may be changed in the software load to ensure that all of the values used by the load are mapped to the correct NV item.
  • Software that requests an NV item by number or logical index first goes through the mapping to determine whether it should be getting the value from a new NV item and, if so, gets the value of this new NV item. This mapping ensures that compatibility is maintained between the wireless device third party tools that know about the existence of certain NV items and ask for them by logical index.
  • The above therefore defines a method for updating the persistent data in the non-volatile memory dynamically, and further discusses an implementation which allows the rollback to previous software loads if desired by the user.
  • Although the present invention has been described with regard to the preferred embodiments thereof, one skilled in the art will realize that other variations are possible, and that the invention is only intended to be limited in scope by the following claims.

Claims (14)

1. A method to provide for rollback to a previous software load on a mobile device, the previous software load utilizing non-volatile memory item values stored in the previous software load, the method comprising the steps of:
adding, when upgrading to a new software load, a new non-volatile memory item rather than replacing a value in an existing non-volatile memory item; and
preventing deletion of any non-volatile memory items once said non-volatile memory items are created,
wherein the adding step and preventing step allow the utilization of non-volatile memory items and non-volatile memory item values from the previous software load when rolling back to the previous software load.
2. The method of claim 1, wherein said method further comprises the steps of avoiding non-volatile memory items created by default or refurbished non-volatile memory files.
3. The method of claim 2, further comprising the step of creating a new non-volatile memory item to replace non-volatile memory items created by default or part of the refurbished non-volatile memory files.
4. The method of claim 3, further comprising the step of barring use of non-volatile memory items created by default or refurbished non-volatile memory files
5. The method of claim 1, further comprising the step of mapping requests for a non-volatile memory item to a correct non-volatile memory item.
6. The method of claim 5, wherein the mapping step is based on a map that is changed in the new software load.
7. The method of claim 6, wherein the requests for a non-volatile memory item are mapped from a non-volatile memory item number or non-volatile memory item index to a correct non-volatile memory item number.
8. A wireless communications device comprising:
a receiver for receiving signals;
a transmitter for transmitting signals;
a digital signal processor for processing signals to be sent on said transmitter and received on said receiver;
a processor communicating with said digital signal processor;
non-volatile memory having program storages and non-volatile memory items, said non-volatile memory communicating with said processor; and
input and output subsystems interacting with said processor,
wherein said processor includes means for adding, when upgrading to a new software load, a new non-volatile memory item rather than replacing a value in an existing non-volatile memory item and means for preventing deletion of any non-volatile memory items once said non-volatile memory items are created, the means for adding and preventing adapted to allow the utilization of non-volatile memory items and non-volatile memory item values from a previous software load when rolling back to the previous software load.
9. The wireless communications device of claim 8, further comprising means for avoiding non-volatile memory items created by default or refurbished non-volatile memory files.
10. The wireless communications device of claim 9, further comprising means for creating a new non-volatile memory item to replace non-volatile memory items created by default or part of the refurbished non-volatile memory files.
11. The wireless communications device of claim 10, further comprising means for barring use of non-volatile memory items created by default or refurbished non-volatile memory files
12. The wireless communications device of claim 8, further comprising a map adapted to mapping requests for a non-volatile memory item to a correct non-volatile memory item.
13. The wireless communications device of claim 12, wherein the map is changed in the new software load.
14. The wireless communications device of claim 13, wherein map is adapted to map the requests for a non-volatile memory item from a non-volatile memory item number or non-volatile memory item index to a correct non-volatile memory item number.
US11/735,019 2004-01-27 2007-04-13 Software-delivered dynamic persistent data Expired - Fee Related US8677341B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US11/735,019 US8677341B2 (en) 2004-01-27 2007-04-13 Software-delivered dynamic persistent data

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/765,512 US7222340B2 (en) 2004-01-27 2004-01-27 Software-delivered dynamic persistent data
US11/735,019 US8677341B2 (en) 2004-01-27 2007-04-13 Software-delivered dynamic persistent data

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US10/765,512 Continuation US7222340B2 (en) 2004-01-27 2004-01-27 Software-delivered dynamic persistent data

Publications (2)

Publication Number Publication Date
US20070245337A1 true US20070245337A1 (en) 2007-10-18
US8677341B2 US8677341B2 (en) 2014-03-18

Family

ID=34795489

Family Applications (2)

Application Number Title Priority Date Filing Date
US10/765,512 Expired - Fee Related US7222340B2 (en) 2004-01-27 2004-01-27 Software-delivered dynamic persistent data
US11/735,019 Expired - Fee Related US8677341B2 (en) 2004-01-27 2007-04-13 Software-delivered dynamic persistent data

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US10/765,512 Expired - Fee Related US7222340B2 (en) 2004-01-27 2004-01-27 Software-delivered dynamic persistent data

Country Status (1)

Country Link
US (2) US7222340B2 (en)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110072122A1 (en) * 2009-09-18 2011-03-24 Alcatel-Lucent Usa Inc. Methods for improved server redundancy in dynamic networks
US20120198215A1 (en) * 2007-09-14 2012-08-02 International Business Machines Corporation Instruction exploitation through loader late fix-up
CN106325901A (en) * 2015-06-24 2017-01-11 南宁富桂精密工业有限公司 Software version management method and system
CN107943511A (en) * 2017-11-08 2018-04-20 上海青橙实业有限公司 Upgrade method and mobile terminal
US11288361B1 (en) * 2019-03-29 2022-03-29 NortonLifeLock Inc. Systems and methods for restoring applications

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7409685B2 (en) 2002-04-12 2008-08-05 Hewlett-Packard Development Company, L.P. Initialization and update of software and/or firmware in electronic devices
US8479189B2 (en) 2000-11-17 2013-07-02 Hewlett-Packard Development Company, L.P. Pattern detection preprocessor in an electronic device update generation system
US8555273B1 (en) 2003-09-17 2013-10-08 Palm. Inc. Network for updating electronic devices
US20050132351A1 (en) * 2003-12-12 2005-06-16 Randall Roderick K. Updating electronic device software employing rollback
US8418162B2 (en) * 2004-01-27 2013-04-09 Research In Motion Limited Network delivered dynamic persistent data
US7904895B1 (en) 2004-04-21 2011-03-08 Hewlett-Packard Develpment Company, L.P. Firmware update in electronic devices employing update agent in a flash memory card
US8526940B1 (en) 2004-08-17 2013-09-03 Palm, Inc. Centralized rules repository for smart phone customer care
US7650489B2 (en) * 2006-03-23 2010-01-19 Intel Corporation Determining coherency between a non-volatile memory and a system
EP2025095A2 (en) 2006-06-08 2009-02-18 Hewlett-Packard Development Company, L.P. Device management in a network
US7869986B2 (en) * 2006-07-10 2011-01-11 Blancha Barry E System and method for performing processing in a testing system
US8752044B2 (en) 2006-07-27 2014-06-10 Qualcomm Incorporated User experience and dependency management in a mobile device
US20080320110A1 (en) * 2007-06-25 2008-12-25 Sharp Laboratories Of America, Inc. Firmware rollback and configuration restoration for electronic devices
US9767000B1 (en) * 2010-09-20 2017-09-19 Amazon Technologies, Inc. Selecting appropriate subsets of software tests
US9158525B1 (en) * 2010-10-04 2015-10-13 Shoretel, Inc. Image upgrade
US9910659B2 (en) * 2012-11-07 2018-03-06 Qualcomm Incorporated Methods for providing anti-rollback protection of a firmware version in a device which has no internal non-volatile memory
GB2508599A (en) * 2012-12-04 2014-06-11 Ibm Software version management when downgrading software
US8918775B1 (en) * 2013-07-12 2014-12-23 Ca, Inc. Dynamic release control of software application version changes

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6347398B1 (en) * 1996-12-12 2002-02-12 Microsoft Corporation Automatic software downloading from a computer network
US20020078142A1 (en) * 2000-12-20 2002-06-20 Microsoft Corporation Method and system for enabling offline detection of software updates
US20030121033A1 (en) * 2001-12-05 2003-06-26 Peev Igor B. Installing software on a mobile computing device using the rollback and security features of a configuration manager
US20030221189A1 (en) * 2001-12-12 2003-11-27 Birum Derrick Jason Method and system for upgrading and rolling back versions
US6721767B2 (en) * 2000-01-31 2004-04-13 Commvault Systems, Inc. Application specific rollback in a computer system
US20040216133A1 (en) * 2002-09-27 2004-10-28 Roush Ellard T. Software upgrades with multiple version support

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
SE516806C2 (en) 1999-05-26 2002-03-05 Ericsson Telefon Ab L M Methods for loading software into a radio terminal, such as a mobile phone, and associated radio terminal
EP1306755A1 (en) 2001-10-29 2003-05-02 Siemens Schweiz AG Method of distributing software to a device
US20040117785A1 (en) 2002-12-13 2004-06-17 Samsung Electronics Co., Ltd. Component download manager for a wireless mobile station and method of operation

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6347398B1 (en) * 1996-12-12 2002-02-12 Microsoft Corporation Automatic software downloading from a computer network
US6721767B2 (en) * 2000-01-31 2004-04-13 Commvault Systems, Inc. Application specific rollback in a computer system
US20020078142A1 (en) * 2000-12-20 2002-06-20 Microsoft Corporation Method and system for enabling offline detection of software updates
US20030121033A1 (en) * 2001-12-05 2003-06-26 Peev Igor B. Installing software on a mobile computing device using the rollback and security features of a configuration manager
US6993760B2 (en) * 2001-12-05 2006-01-31 Microsoft Corporation Installing software on a mobile computing device using the rollback and security features of a configuration manager
US20030221189A1 (en) * 2001-12-12 2003-11-27 Birum Derrick Jason Method and system for upgrading and rolling back versions
US20040216133A1 (en) * 2002-09-27 2004-10-28 Roush Ellard T. Software upgrades with multiple version support

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120198215A1 (en) * 2007-09-14 2012-08-02 International Business Machines Corporation Instruction exploitation through loader late fix-up
US8429638B2 (en) * 2007-09-14 2013-04-23 International Business Machines Corporation Instruction exploitation through loader late fix-up
US20110072122A1 (en) * 2009-09-18 2011-03-24 Alcatel-Lucent Usa Inc. Methods for improved server redundancy in dynamic networks
US9569319B2 (en) * 2009-09-18 2017-02-14 Alcatel Lucent Methods for improved server redundancy in dynamic networks
CN106325901A (en) * 2015-06-24 2017-01-11 南宁富桂精密工业有限公司 Software version management method and system
CN107943511A (en) * 2017-11-08 2018-04-20 上海青橙实业有限公司 Upgrade method and mobile terminal
US11288361B1 (en) * 2019-03-29 2022-03-29 NortonLifeLock Inc. Systems and methods for restoring applications

Also Published As

Publication number Publication date
US7222340B2 (en) 2007-05-22
US20050166200A1 (en) 2005-07-28
US8677341B2 (en) 2014-03-18

Similar Documents

Publication Publication Date Title
US8677341B2 (en) Software-delivered dynamic persistent data
US8364942B2 (en) Electronic device having an alterable configuration and methods of manufacturing and configuring the same
US8418162B2 (en) Network delivered dynamic persistent data
RU2333612C2 (en) Method and system for data set version renewal containing in wireless device
JP4801041B2 (en) Automatic backup store for firmware upgrades
US20070169099A1 (en) Firmware update system for facilitating firmware update in mobile handset
US20040210752A1 (en) Electronic device supporting multiple update agents
US20060225069A1 (en) Firmware version managing method of computer system and information processing device
EP3518097B1 (en) Firmware updating method and electronic device using the same
CN1918932B (en) Updating of the preferred roaming list (prl) in a sim (subscriber identity module) / ruim (removable user identity module) card.
EP1761088A1 (en) Customisation of mobile stations
KR20070082894A (en) Mobile terminal and software update method
US20170185311A1 (en) Data Processing Method and Smart Device
WO2006057861A1 (en) System and method for over-the-air update of wireless communication devices
CN107220315B (en) User data protection method for database degradation during APP version updating
CA2493846C (en) Network delivered dynamic persistent data
CA2493692C (en) Software-delivered dynamic persistent data
CN101924958B (en) Updating method of optical networking unit of Ethernet passive optical network and device thereof
EP3584697B1 (en) Information processing device
KR20090070549A (en) Software update system
CN1953592A (en) Mobile communication terminal and resource management method of program
KR20070074349A (en) Method for loading different types of software images in ap system and ap system therefor
CN116528221A (en) Method and device for OTA remote upgrading single-card or double-card configuration
KR100698187B1 (en) Method and Apparatus of software upgrade in Digital receiver
CN114268941A (en) Target equipment upgrading method, device, equipment and storage medium

Legal Events

Date Code Title Description
AS Assignment

Owner name: RESEARCH IN MOTION LIMITED, CANADA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:WILLIS, EDWARD SNOW, II;REEL/FRAME:029034/0994

Effective date: 20040716

AS Assignment

Owner name: BLACKBERRY LIMITED, ONTARIO

Free format text: CHANGE OF NAME;ASSIGNOR:RESEARCH IN MOTION LIMITED;REEL/FRAME:032124/0009

Effective date: 20130709

FEPP Fee payment procedure

Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.)

LAPS Lapse for failure to pay maintenance fees

Free format text: PATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.)

STCH Information on status: patent discontinuation

Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362

FP Lapsed due to failure to pay maintenance fee

Effective date: 20180318

AS Assignment

Owner name: MALIKIE INNOVATIONS LIMITED, IRELAND

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:BLACKBERRY LIMITED;REEL/FRAME:064104/0103

Effective date: 20230511