WO2004008781A2 - Remote device updater operating system for mobile devices - Google Patents

Abstract

A remote device updater operating system for mobile devices. The device allows updating on schedule or user command without awaiting a demand from a server. The updater includes parameters for determining the type and nature of updates, including replacement of operating systems. The device further includes the ability to alter the nature of the device upon which it is running by user or server command as a security feature.

Description

REMOTE DEVICE UPDATER OPERATING SYSTEM FOR MOBILE DEVICES

TECHNICAL FIELD

[0001] This invention relates to operating systems for mobile devices. In particular, the

invention relates to operating systems for use with multi-function devices. With still greater

particularity, the invention relates to remote device updater operating systems for miniature

devices.

BACKGROUND ART

[0002] Operating systems are used in a wide variety of electrical devices. Operating systems are used in calculators, phones and several other devices. Miniature devices such

as Personal Digital Assistants (PDS) generally use either Windows CE, a product of

Microsoft of Redmond, Washington, or a variation of the Palm operating system of Palm,

Inc. of Santa Clara, California. The operating system of such devices frequently includes a

remote device updater which allows updating of user information and portions of the

operating system of the device.

[0003] The previous architecture of the Remote Device Updater (RDU) client software was

based on a "push" architecture. To configure device configuration settings or device update

settings, the Remote Device Administrator (RDA) server software sent HTTP commands

directly to the device. To accomplish this, RDU sent an initial discovery string to RDA via

a HTTP post which indicated some initial information about the client software and the

device (such as the processor type and operating system). From this initial discovery, RDA

is also able to discover the LP address of the client device. This architecture supports devices connected via Ethernet or other types of persistent internet connections as long as

no security "firewalls" or NAT (network address translation) gateway existed between the

device and the server machine running RDA. This implementation also required that a

software component actively poll for any incoming HTTP communications.

DISCLOSURE OF THE INVENTION

[0004] A problem has arisen in operating system technology. To configure device

configuration settings or device update settings, the Remote Device Administrator (RDA)

server software sent HTTP commands directly to the device. To accomplish this, RDU sent

an initial discovery string to RDA via a HTTP post which indicated some initial

information about the client software and the device (such as the processor type and

operating system). From this initial discovery, RDA was also able to discover the IP

address of the client device. This architecture supports devices connected via Ethernet or

other types of persistent internet connections as long as no security "firewalls" or NAT

(network address translation) gateway existed between the device and the server machine

running RDA. This implementation . also required that a software component actively poll

for any incoming HTTP communications. This limited the type and variety of devices that

could use RDA.

[0005] The invention, remote management client software, to support a wider category of

devices implements a "pull" architecture. Pull architecture client software no longer polls

for incoming HTTP communication, but instead uses an intelligent local scheduler to

periodically query the remote management server for available updates. The update

packages may contain data files, applications, new operating system images, diagnostic programs, configuration settings and commands to execute on the client device. In this

way, the server is no longer dependent on contacting the client via an IP address that may

be translated or may be transient (the IP address may change over time). This also allows

the invention to support devices that do not have persistent connections, such as devices

that use dial-up or GRPS connectivity.

[0006] The invention retrieves updates in a context-sensitive way. The invention software is

able to choose when updates should only be made when the device is cradled. Once

installed or embedded on the device, the software periodically contacts the management

server or a known file server path to determine whether a new update is available for that

device. The updates may contain data files, applications, commands, configuration changes,

diagnostics programs, or even a complete new operating system image. [0007] A device using the invention installed determines when to check for new software updates based on a local configurable schedule, user-initiation, or server initiation. The

invention client software also integrates a combination of backup/restore functionality,

device lock/unlock functionality, and device update functionality to provide protection

against lost and stolen devices.

[0008] The invention client software capability of remotely replacing the operating system

can significantly extend the useful life of deployed devices. Devices that would normally

have to be recalled to fix bugs in the embedded software or to upgrade the operating system

may be upgraded remotely using the invention software client. BRIEF DESCRIPTION OF THE DRAWINGS [0009] Figure 1 is a block diagram of the prior art updater. [0010] Figure 2 is a block diagram of the updater of the invention. [0011] Figure 3 is a diagram of the scheduler component of the invention. [0012] Figure 4 is a diagram of the scheduler manager interface of the invention. [0013] Figure 5 is a diagram of the scheduler component interaction of the invention. [0014] Figure 6 is a diagram of the device protection portion of the invention.

[0015] Figure 7 is a flowchart of update on the software client.

[0016] Figure 8 is a chart of the object hierarchy for backup and restore on the software

client.

[0017] Figure 9 is an example of a backup on the software client.

[0018] Figure 10 is an example of a restore on the software client.

BEST MODE FOR CARRYING OUT THE INVENTION [0019] Figure 1 is a block diagram of a prior art updater. This Remote Device Updater (RDU) client software was based on a "push" architecture. To configure device configuration

settings or device update settings, the Remote Device Administrator (RDA) server software sent HTTP commands directly to the device. To accomplish this, RDU sent an initial discovery string to RDA via a HTTP post which indicated some initial information about the client software and the device (such as the processor type and operating system). From this initial discovery, RDA was also able to discover the LP address of the client device. This architecture supports devices connected via Ethernet or other types of persistent internet connections as long as no security "firewalls" or NAT (network address translation) gateway existed between the device and the server machine running RDA. This implementation also required that a software component actively poll for any incoming HTTP communications. Prior Remote Device Updater (RDU) client software utilized a monolithic agent module for

configuring device settings remotely.

[0020] Figure 2 is a block diagram of the updater of the invention. This gives a brief

overview of the invention. The invention, remote management client software, to support a

wider category of devices, includes modified architecture to implement a "pull"

architecture. Pull architecture means the client software no longer polls for incoming

HTTP communication, but instead uses an intelligent local scheduler to periodically query

the next generation remote management server for any available updates. The update

packages may contain data files, applications, new operating system images, diagnostic

programs, configuration settings and commands to execute on the client device. In this

way, the server is no longer dependent on contacting the client via an IP address that may

be translated or may be transient (the IP address may change over time). This also allows

the invention to support devices that do not have persistent connections, such as devices

that use dial-up or GRPS connectivity.

[0021] The invention software can retrieve updates in a context-sensitive way, based on the

current state of the device. In particular, the invention software can intelligently choose to

perform critical updates (such as a complete operating system replacement) or very large

updates only when the device is cradled. Once the invention client software is either

installed (the software files are installed on a shipping device) or embedded (the software

files are embedded in the operating system of the device before it is shipped) on the device,

the software periodically contacts the management server or a known file server path to

determine whether a new update is available for that device. The updates may contain data

files, applications, commands, configuration changes, diagnostics programs, or even a complete new operating system image.

[0022] A device using the invention so installed determines when to check for new software

updates based on (1) a local configurable schedule, (2) user-initiation, or (3) server

initiation. User-initiation is performed by a software application on the local device that

allows the user to cause the invention to check for an update immediately when the user

pushes the "Get Update Now" button. Initiation by an administrator is only supported on

devices that have integrated phones capable of receiving a Short Message Service (SMS)

message. In such a case, the management server has the ability to send a private (custom)

SMS message to the device. The invention client software will capture the SMS message

and upon receipt, check for any available updates in its normal manner at that time.

[0023] Figure 3 is a diagram of the scheduler component of the invention. The invention

client software initiates updates based on a set of local schedules that may each contain a set

of triggers and dependencies. The local scheduler software consists of three components:

the Scheduler COM object, the Scheduler User Interface, and the Scheduler Manager. As

shown in Figure 3 Scheduler Component consists of three parts: Scheduler COM,

Scheduler UI and Scheduler Manager.

[0024] In order to better understand the invention, in particular, Figures 3 and 4, the

following definitions should be kept in mind. A task is a process (such as the update engine

or any other application) that is launched when any of its list of triggers occurs. A task is

an object that has properties such as: Description, Application Name, Working Directory

(location of the application), LastRunTime, NextRunTime, Parameters (command-line

parameters of a task), ID, MaxRunTime and a list of triggers. A trigger is created,

modified and deleted through its task. A trigger is an event, which causes the task to be launched. There are three basic types of triggers: timer, reboot, and connection triggers.

Accessing and configuring tasks and triggers is done via public interfaces in the Schedule

COM Object.

[0025] Figure 4 is a diagram of the scheduler manager interface of the invention. The

Scheduler COM object implements the detailed business rules and logic for task scheduling.

The registry storage serves as the persistent storage for the COM object. The Scheduler

COM object exposes the following interfaces, such as IbsqTaskScheduler, IbsqTaskList,

IbsqTask, IbsqTaskTriggerList and IbsqTaskTrigger, which are consumed by Scheduler

User Interface, Scheduler Manager and other clients.

[0026] The Scheduler User Interface provides a user interface to add, modify, view and

delete a task. The user can enable or disable a scheduled task and can also view history of

the scheduled task. The interface allows the user to schedule a task through a number of

settings and impose conditions on launching a scheduled task.

[0027] The Scheduler Manager is a background process that is responsible for managing

tasks. It schedules the tasks each time it receives a task change event. The scheduled task

sends back a run task event, with its task ID and trigger ID, to the Scheduler Manager

when the scheduled run time is due or when the scheduled event occurs. The scheduled

task has the ability to wake up the device if the device is in suspended mode. The

Scheduler Manager will then actually launch the identified task, based on the task ID and

trigger ID. The pre-launch conditions, such as, free memory space, battery level, will be

checked. The outcome of the launched task will also be logged.

[0028] Whenever the task schedule information has changed, the scheduler UI will send a

message to the scheduler manager. Upon receiving this message, it will read the updated task schedule information and reschedule all the valid tasks. A valid task means that the

task is enabled and the schedule period is within the current device time. The scheduler

manager schedules the task, which is responsible for waking up the device if the device is

suspended when a time based trigger event occurs.

[0029] When a scheduled task is due, either because of the time is reached, or because of

the event occurs, the scheduler manager will launch the task based on the task ID and

trigger ID. Before launching the task, the scheduler manager will check the pre-launching

conditions, such as battery condition, free memory condition and maximum number of

allowable runs. If any of these conditions are not met, the task will not be launched. The

reason will be logged.

[0030] The scheduler manager creates a separate thread for each launched task. The thread

monitors the task based on the maximum number of run time. If the process proceeds

longer than the allowable run time, the process is terminated. The outcome of the process is updated.

[0031] The scheduler manager is responsible for waking up the device (even if the device is

currently suspended) when a time-based trigger event occurs. The triggers used have the

following properties (retrievable via get and set property methods):

Date/Time - A specific date and time.

Recurrence - If recurring tasks are desired, this is set to hourly, daily, weekly,

monthly. The recurrence corresponds to the date time property. The date/time property

must be set in order to have a recurrence. When a date is selected this is the first instance

of the recurring schedule that occurs. The trigger is reset after each time is reached and processed. Boot Level - The boot level is used if you would like the task to be triggered after a

reboot occurs. The options are: none, next boot, and all boots.

Start Date - The start date specified the next trigger date.

Connection detection - This trigger waits for a connection, then launches the task.

Other dependencies - Disk space, battery power, AC power.

Disk space - This trigger checks that a certain amount of disk space is available.

Battery power - This trigger waits until the device is at a high-enough battery level.

AC Power - This trigger waits until the device is operating on AC power rather than

internal batter power.

Cradle - This trigger waits until the device is cradled.

[0032] Figure 5 is a diagram of the scheduler component interaction of the invention. A

typical task schedule process is depicted in the following steps. The first step is to set up

task scheduling. The scheduler UI provides a number of user-friendly screens allowing the

end user to enter task scheduling information. The end user can also view a list of existing

tasks and choose to modify or delete any of these tasks. If required, the administrator can

also remotely setup a schedule via scripting. In this case, the administrator has the option

to hide a scheduled task from the end user.

[0033] Scheduler Manager is a background program that is always running. To minimize

CPU consumption, it is designed to be event-driven, instead of using polling mechanism.

Each time there is a change made to the task scheduling information by the Scheduler UI or

by a script, the second step is a change event message sent out to inform the Scheduler

Manager.

[0034] Upon receiving a task change event message, as a third step, the Scheduler Manager will check the scheduled data using the Scheduler COM Object and, if required, will

reschedule the task.

[0035] The fourth step is based on information at the task and task trigger levels, the

scheduler manager will schedule a task using a variety of system resource APIs, such as the

Notify component for setting trigger times. When scheduling a task, the task ID and

trigger ID are also attached. When complete, the scheduler manager enters the idle mode

to avoid consuming CPU processing power.

[0036] The fifth step is that when a scheduled event occurs or a scheduled time becomes

due, the system will fire back a notification to the scheduler manager. The scheduler

manager will wake from idle mode and resume its active mode. It will parse the

notification for the task and trigger IDs and launch the appropriate task.

[0037] As a sixth step before launching a task, the scheduler manager checks a number of

pre-launch conditions, such as AC power status, battery level, free memory, internet

connection quality and maximum number of allowable runs.

[0038] For running any mission critical process on the device, the battery and memory

parameters are primary concerns. As the seventh step in portable devices, the scheduler

manager ensures that the pre-launch conditions are met, no matter what time of day the task

is to be launched. As soon as all pre-launch conditions are met, the scheduler manager will

launch a task. The scheduler manager can also monitor the progress of a launched task.

For example, the scheduler manager will terminate a launched task if the maximum

allowable run time is exceeded.

[0039] The final eighth step is to log the status of each scheduler manager process to the

Scheduler COM Object and an end user can view this information through the Scheduler UI. In some cases, the status and history information is also used to calculate the next run

time.

[0040] A device can be configured to retrieve critical updates only when cradled. To

achieve this, a schedule is created on the device (at some (configurable) recurring time

interval) to make use of either (1) a cradling event or (2) a combination of the AC Power

and Connection Detection triggers. The inventions client software sends information about

its current Power/Connection state to the device server which will in turn intelligently

choose which updates to make available to the device at which times. These schedules may

be configured to occur at low traffic times, such as during the night, to help keep out-of-

pocket expenses as low as possible for users. When downloading a large update to the device, the administrator may configure the software to impose a restriction on the

maximum allowable time duration for the download. This also helps control costs and

network utilization for each download.

[0041] Figure 6 is a diagram of the device protection portion of the invention. The

invention client software integrates a combination of backup/restore functionality, device

lock/unlock functionality, and device update functionality to provide protection against lost

and stolen devices. When the client software scheduler checks with the server for updates,

if the device is reported lost or stolen, a special update package will be assigned as the next

update for this device to retrieve. Devices that support receiving SMS (Short Message

Service) messages may also be sent a special SMS message from the server immediately

after being notified of the lost device, that will cause the inventions software to request its

update immediately, rather than waiting for the next scheduled update period. The special

lost/stolen device package may contain instructions for the device to perform one or more of the following steps: (1) perform an incremental backup (only files that have changed

since the last scheduled backup will be backed up at this time), (2) delete user created files

and settings, (3) lock the device, and (4) restore the users personal files and settings onto a

replacement device. Once a device has received a Lock update message or package, the

device's user interface is captured by the software's LockWinCE executable. This

executable makes use of the WM_DESTROY and DLL_PROCESS_DETACH Windows

messages to trap all user attempts to gain access to the device. By trapping the

WM_DESTROY Windows message, the LockWinCE executable blocks any user attempts

to terminate the process. More sophisticated attempts to end the process from a desktop

computer using, for example, Platform Builder's Remote Tools or Kernel Debugger or the

embedded Visual C+ + Toolkit's Application Debugger, are also blocked by trapping the

DLL_PROCESS_DETACH Windows message. For clients that are embedded in the

device's OS, a lock flag is marked directly in the device's flash memory, which allows the

locked state to persist through soft and hard resets as well as through a total battery drain- out.

[0042] The invention client software utilizes separate configuration objects that can either

be installed on the device or downloaded on demand. Thus, configuration objects may be

written after the device is deployed and downloaded to configure devices remotely.

[0043] Configuration objects are a set of COM objects with scriptable COM interfaces

designed to give programmatic access to user settings, third party software settings, and

invention object settings. Most of these settings are located in the device registry, and

Configuration objects have READ/WRTTE access to these settings. Configuration objects

can be included in the device image or installed in a per-update basis to minimize the client footprint. Modification of client configurations can be done through a script (VBscript or

Jscript in v4.0) that instantiates the configuration object and retrieves or sets the values

through the properties available to each object. If the configuration object is not already installed on the device, it can be included in the update package along with the script to

run.

[0044] Figure 7 is a flowchart of update on the software client. The following Example 1 is

a list of supported Configuration objects shown in a working environment:

Example 1

Network: Network settings for the active network connection.

Backup/Restore: Settings for configuring the backup and restore feature.

Device Lock: Actions to perform in the event a device is reported lost/stolen or returned.

User: User specific configuration settings, such as keyboard speed or device name.

Update: Settings for configuring the update feature.

Server: Settings for specifying the designated management server and settings related to how the client communicates with the management server.

OS/System: Read-only settings that describe the device operating system and hardware.

Browser: Local Internet Explorer settings, such as Homepage, and Proxy settings.

OEM: Generic strings and numbers for OEM use to write values to the registry.

Task List: Return a list of running applications, and start or stop applications.

Software Inventory: Returns a list of locally installed applications.

PockPC: Configuration settings applying specifically to the PocketPC 2000 and 2002 class of devices.

Phone: Settings for configuring phone specific features.

ICA/RDP: Remote device protocol (RDP) and ICA connection settings.

RAS: Settings required to create a remote RAS connections on the device.

An example of a script file that calls the network configuration object (netcon.dll) and disables dhcp and assigns a static IP address of ' 1.1.1.1' is as follows: Dim netcon set netcon = WScript.CreateObject("NetworkConfιg.NetConfig") netcon.dhcpenabled = 0 netcon.ipaddress = ' 1.1.1.1'

[0045] A multi-pass update will involve rebooting the device in-between update actions.

When an update package requires a reboot before the update can continue the person

designing the update (typically the OEM or administrator) can insert a reboot action that

will perform a warm reboot on the device at the desired time during the update process.

Before the reboot action is executed the Package Engine will save the state of the update.

Part of the process of saving state is setting the update process to run again after the reboot

has occurred and indicating where the update should continue. Once the device has

executed the reboot action the device will load the update process and based on the save

state information began processing the update at the next action following the reboot action

that has just occurred.

[0046] Example 2 is an example scenario.

Example 2

1. Administrator wants to copy a new driver to a device, add some information to the registry on the device, copy an executable that uses the new device driver, reboot the device so the driver will load, and run the executable on the device that takes advantage of the new driver.

2. The administrator would create an update such as the following: a. CopyFile action (copies the new device driver file) b. RegistryAddValue action (adds the driver's new registry key and value) c. CopyFile action (copies the new executable that uses the device driver) d. Reboot action (performs a warm reboot that saves the update state before executing the action). e. Execute action (executes the new executable from step c)

[0047] During any update (normal or multi-pass) it is possible to do the following update

actions via a package. Table 1 is a listing of the update actions plus a description of what each action can accomplish.

[0048]

Table 1

Copy File a. Copies a file to the device i. Setting file attribute ii. Overwriting existing file if desired iii. Checking for available storage of the file b. APIs & Misc details i. Win32 CreateFile ii. Win32 GetFileAttribute iii. Win32 SetFileAttribute iv. Win32 DeleteFile v. Win32 FindFirstFile vi. Win32 GetStorelnformation (CE only) vii. Win32 GetDiskFreeSpaceEx (Win2K, WinXP only) viii. Win32 GetLastError ix. Win32 FormatMessage x. Win32 CloseHandle xi. Win32 WriteFile xii. Win32 ReadFile

Delete File a. Deletes a file from the device i. Deletes file regardless of file status (if mandatory delete flag is set) b. APIs and Misc details i. Win32 DeleteFile ii. Win32 CreateFile iii. Win32 FindFirstFile iv. Win32 CloseHandle Execute File a. Executes a file on the device i. Allows you to execute a file with or without command line parameters ii. Allows you to wait for the executable to finish before processing the next action. b. APIs and Misc details i. Win32 CloseHandle ii. Win32 CreateProcess OS Update a. Allows a device with upgrade an operating system. b. Makes sure the downloaded file will fit on the device. c. APIs and Misc details i. Win32 DeleteFile ii. Win32 KernelloControl iii. Win32 CreateFile iv. Win32 CloseHandle v. Win32 WriteFile vi. Win32 ReadFile Reboot a. Allows a device to be rebooted i. Warm boot ii. Cold boot b. You can specify the amount of time before the reboot is to occur c. You can specify if the device user should be prompted before the reboot occurs d. APIs and Misc details i. Win32 KernelloControl Add Registry Key a. Adds a registry key to the device's registry hive b. APIs and Misc details i. Win32 RegCreateKeyEx ii. Win32 RegCloseKey Add Registry Value a. Adds a registry key and value pair to the device's registry hive b. APIs and Misc details i. Win32 RegCreateKeyEx ii. Win32 RegSetValueEx iii. Win32 RegOpenKeyEx iv. Win32 RegCloseKey Delete Registry Key a. Gives the ability to delete a registry key from the device's registry hive i. Allows for deleting all the key's sub keys or just the key's values b. APIs and Misc details i. Win32 RegCreateKeyEx ii. Win32 RegOpenKeyEx iii. Win32 RegEnumKeyEx iv. Win32 RegDeleteKey v. Win32 RegCloseKey Export Registry Key a. Exports a specific registry key to a file in REGEDIT4 format i. Allows for exporting all the sub keys or just the key and it's values. b. APIs and Misc details i. Win32 RegCreateKeyEx ii. Win32 RegOpenKeyEx iii. Win32 RegEnumKeyEx iv. Win32 CreateFile v. Win32 CloseHandle vi. Win32 DeleteFile vii. Win32 WriteFile viϋ. Win32 ReadFile ix. Win32 RegCloseKey

[0049] Figure 8 is a chart of the object hierarchy for backup and restore on the software

client. The backup is performed by calling into the backup objects. The backup object

hierarchy and exposed interfaces are described in Figure 8.

[0050] Figure 9 is an example of a backup on the software client. The flow of the backup

process is shown in Figure 9 as follows:

[0051] Call the IBackup function Create. Create takes in information about where the

backup needs to go weather it be to a local location on the device, such as a storage card,

or to the Houston server, and any other information that the backup package will need to

get to the final backup destination. UserName, password, proxy info. The Create method

takes in the data and initializes the backup package (the backup package is a zip archive), it

also sets up any internal variables. It then creates a pointer to a IBackupPackage object.

[0052] The following the call functions in IbackupPackage are shown in Figure 9. These

calls are specific to what is desired in the backup package. BackupDirectory adds the files

in the specified directory to the backup package. Can choose to recursively add the files in

all sub directories or just add the files in the specific directory. Uses API's FindFirstFile,

FindNextFile, and BackupFile to add a specific file to the backup package.

[0053] BackupRegistry calls the coredll's function CopyRegFile which saves the entire

registry to a specified file, add this file to the backup package.

[0054] BackupDatabase adds a specific, or all found, native CE database to the backup

package. BackupDatabase uses API's to find and open databases, gets all data from the databases and converts them into binary files that can be added to the backup package. The

API's used by BackupDatabase are CeFindFirstDatabaseEx, CeFindNextDatabaseEx,

CeOidGetlnfo, CeOpenDatabaseEx, CreateFile, WriteFile, CeReadRecordProps, and

CloseHandle.

[0055] BackupObject calls into any custom backup objects that are registered with backup.

The custom objects are simple COM objects that support a backup and restore method that

return files. These files then get added to the backup package.

[0056] BackupAll: Calls into all of the above functions to backup everything possible on the

device. Calls IBackupPackage Close. Closes up the backup package and sends the backup

package to the location given in the create method. The package is sent via the idmutill.dll.

[0057] Figure 10 is an example of a restore on the software client. The flow of restore

process is shown and described as follows. The first step is to call the IBackup function

Open. Open takes in information about where the restore package is located. The restore

package is a zip archive that was created from the backup process. If the restore package is

coming from a remote location the package is first transferred down to the client via the

idmutil.dll. The package is then opened, member variables are set, and an instance of the

IRestorePackage is created.

[0058] The call functions in IRestorePackage. These calls are specific to what is desired

to restore from the package. RestoreDirectory restores a specific directory from the restore

package. It is optional to specify whether or not to restore the sub folders in the directory

or not. RestoreFile restores a specific file from the package. RestoreRegistry replaces the

existing registry with that in the restore package. Reboots the device so that the new

registry will be in place. RestoreRegistry calls Coredll and RestoreRegFile. RestoreDatabase grabs the file associated with the specified database and converts it back to

a native database. RestoreObject calls into custom objects restore function with the

associated file in the restore package. RestoreAU restores all files in the restore package

calling the above functions for each type of file. The files are differentiated by their file

extensions. Finally, the Call IRestorePackage Close, closes the restore package and deletes

it from the device.

[0059] The present invention has been particularly shown and described with respect to

certain preferred embodiments and features thereof. However, it should be readily

apparent to those of ordinary skill in the art that various changes and modifications in form

and detail may be made without departing from the spirit and scope of the inventions as set

forth in the appended claims, in which reference to an element in the singular is not

intended to mean "one and only one" unless explicitly so stated, but rather "one or more".

The inventions illustratively disclosed herein may be practiced without any element which

is not specifically disclosed herein.

Claims

CLAIMSWhat is claimed is:

1. A system for use in a cradleable portable device having an operating system

that includes a registry comprising:

an updater for delivering new software and data to said device, and

a scheduler for determining when such updater is activated.

2. A system as in claim 1, wherein said scheduler is activated upon a locally

determined time schedule.

3. A system as in claim 1, wherein said scheduler will not activate the updater

unless the device is cradled if the update exceeds a predetermined size.

4. A system as in claim 1, wherein said scheduler will deactivate said device

upon a command for securing said device.

5. A system as in claim 1, wherein said updater is capable of altering and

replacing the operating system of said device while said device is operating.

6. A system as in claim 5, wherein said updater is capable of altering and

updating the registry of said operating system and the of said device.

7. A system as in claim 1 , wherein said updater copies a file to said device.

8. A system as in claim 7, wherein said updater copies a file to said device and

sets file attribute.

9. A system as in claim 8, wherein said updater copies a file to said device and

sets file attribute overwriting existing file if desired.

10. A system as in claim 8, wherein said updater copies a file to said device and

checks for available storage of the file.

11. A system as in claim 1, wherein said updater deletes a file from said device.

12. A system as in claim 11 , wherein said updater deletes a file from said device

regardless of file status when if mandatory delete flag is set.

13. A system as in claim 1, wherein said updater executes a file on said device.

14. A system as in claim 13, wherein said updater executes a file on said device

and executes a file with command line parameters.

15. A system as in claim 13, wherein said updater executes a file on said device

and executes a file without command line parameters.

16. A system as in claim 13, wherein said updater executes a file on said device

and waits for the executable to finish before processing the next action.

17. A system as in claim 1 , wherein said updater reboots said device.

18. A system as in claim 17, wherein said updater reboots said device with a

warm boot.

19. A system as in claim 17, wherein said updater reboots said device with a

cold boot.

20. A system as in claim 17, wherein said updater reboots said device and allows

specification of the amount of time before the reboot is to occur.

21. A system as in claim 17, wherein said updater reboots said device and allows

specification to prompt the device user before the reboot occurs.