CN1954627B - Modular data assembly for wireless communication device - Google Patents

Abstract

Systems and methods for dynamically installing modular software applications (140) and hardware drivers (130) are provided. The wireless communication device (20) sends a request to an update module server (60) that identifies the requesting new application or software module (140, 130). The update module server (60) responds with the instruction set for installing the software module and the software module itself. The handset (20) installs the software module upon receipt of the response and, if necessary, deletes the application or module in persistent storage (240) on the handset. Finally, the handset (20) may be reconfigured or restarted to complete the installation and configuration.

Description

Modular data components for wireless communication devices

technical field

The present invention relates generally to the field of wireless communications, and more particularly to interchangeable software applications, hardware drivers, communications interfaces, and operating system components in wireless communications devices.

Background technique

Once used (ie, sold to consumers), traditional wireless communication devices typically become isolated computing platforms. In order to update the operating system or any required software applications (such as a phone book), consumers typically need to bring a wireless communication device (also referred to herein as a "wireless device," "handheld," and "mobile device") to the service stand.

In addition, if a consumer wants to replace a hardware component of the wireless communication device, the wireless communication device must also be taken to a service station. Often, hardware replacement is also very expensive if the wireless device is not damaged and is under warranty. Even so, when a wireless device has a hardware component replaced during the warranty period, the new component is only a usable version of the component that was replaced. Thus, when a consumer purchases a wireless communication device, the consumer is locked into the physical configuration of the wireless communication device for the life of the wireless communication device.

Another disadvantage of conventional wireless communication devices is that new peripherals, such as digital cameras, are limited to specific peripherals provided by the manufacturer of the handheld device. Accordingly, consumers' options for upgrading the peripherals of the wireless communication device are severely limited. Therefore, there is a need for systems and methods that can overcome the above-mentioned important problems in conventional systems.

Contents of the invention

Traditional wireless communication devices are isolated computing platforms. Once the wireless communication device is in use, updating the software of the wireless communication device requires taking the handset to a service station where the software package can be updated and the handset reconfigured. This is especially true when it comes to making updates to the operating system or required applications such as the address book. Furthermore, the suite of software used on handheld devices is static, inflexible, and does not allow the user to customize various applications to suit his or her needs.

Users of wireless communication devices must purchase new devices in order to reap the benefits of technological advancements embodied in physical devices. If a new model with an improved display is released by the manufacturer, the user cannot upgrade the handheld. Additionally, if a hardware component fails or becomes damaged, the entire handheld needs to be replaced, or in some cases the handheld can be returned to the manufacturer for refurbishment. Unfortunately, this refurb does not allow for upgraded, newer components. Manufacturers must substitute available versions of the same component for the same component.

A first embodiment provides a system and method for dynamically installing modular software applications and operating system components. When commanding a handset to install a new software module, the handset sends a request to an update module server identifying a new application or software module to install. The update module server responds with a set of instructions for installing the software module and the software module itself. The handheld device installs the software module upon receipt of the response and, if necessary, deletes the application or module in persistent storage on the handheld device. Finally, the handheld can be reconfigured or rebooted to complete the installation and configuration.

A second embodiment provides systems and methods for interchangeable modular hardware components on a wireless communication device. When components of the handheld device become obsolete or new, improved elements exist, the new components can be exchanged for the old components. When the handheld is powered on after a hardware component has been replaced, the handheld will recognize the presence of the new component. After the handheld device recognizes a new component, it will interrogate the component to obtain information about the characteristics of the component. Once the handset has this information, it queries the update server over the wireless communication network for an optimized device driver that will allow the handset to take advantage of the improved functionality of the new component. Furthermore, the handheld device may query the update server for new software applications, which may also develop improved functionality of the new components. The update server responds with a set of instructions for installing the device driver and the device driver itself. Upon receipt of the response, the handheld device installs the device driver and reconfigures or reboots to complete the installation and configuration.

Another embodiment provides a method of dynamically updating a communication interface on a wireless communication device to facilitate communication with external devices. After detecting the connection of the external device through a direct physical link, a direct wireless link or a remote wireless link, the wireless communication device obtains brief information related to the external device. If the wireless communication device does not have a communication interface for the external device, the wireless communication device sends a part of the profile of the external device to a remote interface server and requests an appropriate interface. Upon receipt of the interface, the wireless communication device installs the interface and proceeds to establish communication with the external device.

Description of drawings

Details regarding the construction and operation of the present invention can be found, in part, by studying the drawings described below, in which like numerals represent like parts.

FIG. 1 is a high-level block diagram illustrating an exemplary wireless communication network;

2 is a block diagram illustrating an exemplary representation of data in a persistent storage area on a wireless communication device;

3A is a block diagram illustrating components of a data storage area for a modular software interface component;

3B is a block diagram illustrating components of a data storage area for a modular hardware detector component;

3C is a block diagram illustrating components of a data storage area for a modular external device detector component;

Figure 3D is a block diagram illustrating an exemplary operational code library and corresponding runtime instruction set;

FIG. 3E is a block diagram illustrating an exemplary runtime instruction set;

4 is a flowchart illustrating an exemplary process for user-initiated software module download;

5 is a flowchart illustrating an exemplary process for activating a resident software module on a wireless communication device;

6 is a flowchart illustrating an exemplary process for network-initiated software module download;

7 is a flowchart illustrating an exemplary process for installing a software module on a wireless communication device;

8 is a flow diagram illustrating an exemplary process for disabling a software module on a wireless communication device;

9 is a flow diagram illustrating an exemplary process of paying for use of a software module on a wireless communication device;

Figure 10 is a block diagram illustrating an exemplary wireless communication device that may be used with various embodiments described herein;

11 is a block diagram illustrating an exemplary computer system that may be used with various embodiments described herein;

12 is a block diagram illustrating an exemplary wireless communication device and modular hardware components;

13 is a flow diagram illustrating an example process for obtaining brief information from new hardware components on a wireless communication device;

14 is a flowchart of an exemplary process for requesting a device driver for a new hardware component from a remote server;

15 is a flowchart illustrating an exemplary process of installing a device driver for a new hardware component on a wireless communication device;

16 is a flow diagram illustrating an example process for configuring a new hardware component on a wireless communication device;

17A is a block diagram illustrating an exemplary direct physical connection between a wireless communication device and an external device;

17B is a block diagram illustrating an exemplary direct wireless connection between a wireless communication device and an external device;

17C is a block diagram illustrating an exemplary remote wireless connection between a wireless communication device and an external device;

18 is a flowchart illustrating an exemplary process for obtaining brief information from an external device;

19 is a flowchart illustrating an exemplary process for requesting interface software from a remote server;

20 is a flow diagram illustrating an exemplary process for installing interface software on a wireless communication device; and

21 is a flow diagram illustrating an example process for initializing an external device.

Detailed ways

Disclosed herein is a system and method for dynamically updating software modules and software applications, and device drivers on a wireless communication device over an air link. For example, the methods and systems disclosed herein allow wireless communication devices to request new software modules or driver modules from an update server and receive these new modules in wireless communication data packets. Upon receipt of the data packet, the wireless device installs the requested modules and, if necessary, deletes other modules to make room for permanent storage of new modules. The wireless device can also be reconfigured for use with the new module, and the device can be restarted (rebooted), if desired.

Another embodiment disclosed herein provides a wireless communication device and method for dynamically identifying and interfacing with an external device. For example, one method disclosed herein allows a wireless device to recognize the presence of an external device through a wired or wireless communication link. Once the wireless communication device has identified the external device, it queries the external device for brief profile information about the device. The wireless communication device then queries the server over the wireless communication network and receives a response containing an interface to enable communication between the devices.

After reading these descriptions it will become apparent to a person skilled in the art how to practice the invention in various alternative embodiments and alternative applications. However, while various embodiments of the invention will be described herein, it is to be understood that these embodiments are presented by way of example only, and not limitation. Accordingly, this detailed description of various alternative embodiments should not be construed to limit the scope or breadth of the invention, which is defined by the appended claims.

FIG. 1 is a high-level block diagram illustrating an exemplary wireless communication network 10 . In the illustrated embodiment, wireless communication network 10 includes a plurality of wireless communication devices 20 and 30 that are communicatively coupled to network 50 through a plurality of base stations 40 and 42 . Additional wireless communication devices and base stations may also be used to the wireless communication network 10 as part of it. Wireless communication network 10 also includes update module server 60 coupled to data store 70 . Wireless communication devices 20 and 30 are communicatively coupled to update module server 60 through base stations 40 and 42 and network 50 .

Wireless communication device 20 may be any device capable of communicating within wireless communication network 10 and executing software modules and/or having alternative modular hardware components. The wireless communication device 20 preferably also has a permanent storage area. For example, wireless communication device 20 may be a cellular telephone, personal digital assistant (PDA), laptop computer, watch, or any other device configured for wireless communication. A wireless communication device may also be referred to herein as a "handset," a "mobile phone," or a "mobile device."

In the illustrated embodiment, the connection between the external device 22 and the handheld device 20 is a direct physical connection 24 . The external device may also be coupled to the handheld device via a wireless link, such as a direct wireless link 34 or a remote wireless link 36 between the external device 32 and the handheld device 30 . In one embodiment, the direct physical connection 24 between the handheld device 20 and the external device 22 may be a hardwired physical connection, such as a serial cable or a wired network connection. As an option, the direct wireless connection 34 may use LAN protocol, Bluetooth or infrared. External device 32 may also be connected to handheld device 30 via a long-range wireless connection 36 linking wireless communication devices via a base station (eg, base station 42). Additionally, the external device 32 may also be connected to the handheld device 30 via a remote wireless connection 36 linking wireless communication devices via a network, such as the Internet or network 50 .

Base station 40 is configured to communicate over the air with a plurality of wireless communication devices, and base station 40 includes a transceiver (not shown) for converting over-the-air communications to wired communications for transmission over network 50 . Network 50 is preferably a private network operated by a wireless carrier that provides the infrastructure for handoff between base stations (eg, base stations 40 and 42). In addition, network 50 preferably provides communication links between various applications, services, and other computer-based servers such as update module server 60 .

Network 50 can also be used as a gateway to other networks (not shown), such as Integrated Services Digital Network ("ISDN"), Public Switched Telephone Network ("PSTN"), Public Land Mobile Telephone Network ("PLMN"), Packet Switched Public Data Network ("PSPDN") and the Internet, to name a few networks.

The update module server 60 can be implemented as a single computer or multiple servers, and is logically configured to provide dynamic instruction sets and software and hardware modules for mobile devices, and execute dynamic instruction sets received from mobile devices. In the illustrated embodiment, the update module server 60 is coupled to a data store 70, which preferably houses a plurality of executable interfaces, a set of server operation codes, handset operation codes, and corresponding Executable instructions. Features of a general-purpose computer that can implement the update module server 60 will be described later with reference to FIG. 11 . One function of the update module server 60 is to receive and respond to requests received from handhelds 20, 30 to provide executable software modules, device drivers for swapped handheld hardware, to said handhelds. Programs or executable interfaces for communicating with external devices.

FIG. 2 is a block diagram illustrating an exemplary representation of data in persistent storage 240 on wireless communication device 20 . The general features of wireless communication devices 20 and 30 that allow them to function are described later with reference to FIG. 10 . In the illustrated embodiment, operating system 100 is resident in persistent storage 240 . Operating system 100 preferably includes basic executable programs or programs that allow the wireless communication device to function. In addition to operating system 100 , application data 110 and user interface 120 also reside in persistent storage 240 . Application data 110 preferably includes user information, and application information that the application needs to function or that the application uses to provide its services.

The user interface 120 may include an executable user interface application and user interface data used by the application. In alternative embodiments, the user interface application portion may be part of the operating system, and the user interface 120 may include auxiliary user data, custom data, or other data usable by the user interface application or the user. Persistent storage 240 also includes one or more device drivers, such as device driver 130, device driver 132, through device driver n. These device drivers are preferably those that facilitate communication between the handset and another device, or between the core handset and an requisite device such as a display, keyboard, speaker, microphone, or headset, to name a few. Executable application.

As part of the persistent storage area 240, a series of software applications or modules are additionally shown, such as applications 140, 142, 144, 146...n. As shown, a number of applications may reside in a portion of persistent storage 240 . The only limit to the number of applications that can be stored in persistent storage 240 is the physical limitations of storage 240 .

FIG. 3A is a block diagram illustrating elements of data 240 of an exemplary wireless communication device 20 . In the illustrated embodiment, data 240 has multiple applications 242 including modular software interface 200 , software license manager 205 , and runtime engine 230 . Other data elements 244 (which may be included in application data 110 as shown in FIG. 2 ) include server operation code (opcode) library 210 , handset operation code library 220 , and runtime instructions 260 .

The modular software interface 200 is preferably configured to receive user requests to install new software modules and applications. Additionally, the modular software interface 200 is preferably configured to receive network-initiated software module downloads and software application downloads. Modular software interface 200 may include a user interface module adapted to accept instructions from a user for user initiated downloading. Additionally, the modular software interface 200 may include a communications module adapted to receive communications for network-initiated downloads from a network server.

In one embodiment, the modular software interface 200 receives instructions from a user to download a particular software module. The modular software interface 200 is preferably configured to communicate with the runtime engine 230 to generate requests for software modules to be downloaded from the web server. In an alternative embodiment, the modular software interface 200 receives instructions from a web server. The modular software interface 200 is preferably configured to parse and interpret the instructions to determine what software module the web server is requesting the handset to download and install. After confirming the request from the network, the modular software interface 200 communicates with the runtime engine 230 to implement the download.

Additionally, modular software interface 200 may be configured to determine the available space in persistent storage 240 where software modules are to be installed. For example, the modular software interface 200 determines the amount of disk space (or other persistent storage space) available on the handheld device upon receiving a request to install a new software module. In one embodiment, to determine available storage space, the modular software interface 200 may query the handheld device's operating system 100 as previously discussed with reference to FIG. 2 . If sufficient space is available, the modular software interface 200 can communicate with the runtime engine 230 as previously described.

If there is not enough persistent storage space to install the requested software module, modular software interface 200 queries the user or network 50 (depending on where the request came from) to identify software modules or other data in persistent storage that may be deleted. Alternatively, modular software interface 200 may determine what data may be deleted, for example, by querying the operating system or identifying an earlier version of the requested software module.

Furthermore, modular software interface 200 is preferably configured to instruct operating system 100 to delete identified software modules or other data in persistent storage area 240 to make sufficient free space for new software modules. If there is no persistent storage space available, and sufficient persistent storage space cannot be obtained by deleting data or software modules already occupying space in the persistent storage area, then the modular software interface 200 can notify the user or the network that there is no space available to Install the requested software module.

With continued reference to FIG. 3A , the handset operation code library 220 preferably includes an operation code universe representing each function or executable code segment that the update module server (shown in FIG. 1 ) 60 commands the handset to perform an operation. Advantageously, the handheld device operating code library 220 includes opcodes as placeholders for actual executable machine code functions or code segments. Accordingly, the handheld operation code library 220 preferably contains a listing of all available operation codes for each function executable by the handheld device 20 , 30 .

Similarly, the server operation code repository 210 preferably includes a universe of operation code representing each server side function or executable code segment. Advantageously, the server opcode library 210 may only contain opcodes for actual executable machine code functions or code segments that are not resident in the wireless communication device 20 . Thus, server opcode library 220 contains a listing of all opcodes for each available server function that can be executed by update module server 60 on behalf of handsets 20 and 30 . In a preferred embodiment, the number of server functions available can greatly exceed the number of handset functions available because the update module server 60 is not subject to the minimal resources typically found on mobile devices (e.g., cell phones and PDAs)

The runtime engine 230 is preferably configured to process dynamic instruction sets. One embodiment of a dynamic instruction set is an instruction set for installing software modules. Another embodiment of a dynamic instruction set is the instruction set of a device driver for installing new hardware components. Processing of dynamic instruction sets includes translating opcodes into executable instruction sets, and executing these instruction sets. For example, a set of handset operation codes may be received from update module server 60 along with a data payload. The operational code is then translated into executable instructions for the handheld device. The processing of the dynamic instruction set also includes compiling the opcodes and corresponding data payloads sent to the update module server 60 . The runtime engine 230 can preferably be started by the wireless communication device 20, 30 on an as-needed basis, so that the runtime engine 230 runs only when necessary, thereby consuming a minimal amount of system resources (e.g., memory) on the handheld device 20, 30 , CPU cycles, etc.).

Referring now to FIG. 12, a block diagram of FIG. 12 illustrates an exemplary wireless communication device 620 and modular hardware components. In the illustrated embodiment, the handheld device 620 includes a number of hardware modules including a screen 680 and a keyboard 682 . Additional hardware modules, which may include, for example, radio frequency chipsets, are also typically included in handheld devices such as handheld device 620 . A hardware module is a component of the handheld device that is capable of electrical communication within the handheld device 620 . Inert components, such as housings, that do not have communication capabilities are not considered hardware modules.

In the illustrated embodiment, the display screen 680 is interchangeable with a new display screen 690 . For example, display screen 680 may be limited to displaying monochrome, while display screen 690 may display color. Similarly, keyboard 682 is interchangeable with new keyboard 692 . For example, the new keyboard 692 is capable of illuminating the keys, while the keyboard 682 is not.

FIG. 3B is a block diagram illustrating elements of data 240 of another exemplary wireless communication device 20 . In the illustrated embodiment, data 240 has a plurality of applications 242 including modular hardware probe 202 and runtime engine 230 . Other data elements (which may be included in application data 110 as shown in FIG. 3A ) 244 include server operation code (opcode) library 210 , handset operation code library 220 , and runtime instructions 260 .

Modular hardware detector 202 is preferably configured to determine when a new hardware module has been swapped with a previous hardware module. In one embodiment, the modular hardware detector 202 detects the presence of new hardware modules after power-up. As an option, modular hardware detector 202 may operate during power-on mode to detect any new hardware that is "hot" swapped while handheld device 20 is powered on, or replaced during device 20 power-up. Modular hardware detector 202 may be implemented as a combination of electromechanical and software components to perform detection functions, and preferably communicates with runtime engine 230 to notify the runtime engine of newly detected hardware modules.

Additionally, modular hardware probe 202 may be configured to determine the available space in persistent storage 240 for installing new device drivers. For example, upon detecting a new hardware module, the modular hardware detector 202 determines the amount of storage space used by the current device driver (e.g., device driver N shown in FIG. 2 ) and the amount of storage space required by the new device driver. amount of storage space. In one embodiment, modular hardware probe 200 may query operating system 100 to determine the amount of storage space currently used by device drivers. Additionally, to determine the amount of storage space required for a new device driver, modular hardware probe 202 may, via runtime engine 230, query update server 60 shown in FIG. 1 for this information.

If the current device driver and the new device driver are the same size, or if the new device driver requires less storage space than the current device driver, the new device driver can be installed in the same location in permanent storage as the current device driver . If the storage space required by the new device driver is larger than the current device driver, then the modular hardware detector 202 preferably can be in another part of the persistent storage area 240 (newly allocated by the modular hardware detector 200 for the device driver). storage) to install new device drivers. As an option, modular hardware detector 202 may also query the user to identify data in persistent storage that may be deleted to make room for new device drivers.

Modular hardware detector 202 is preferably configured to instruct operating system 100 to delete the current device driver after a new device driver has been successfully installed. Preferably, during installation of a new device driver, the current device driver is backed up in permanent or volatile storage.

FIG. 17A shows a block diagram illustrating an exemplary direct physical connection 84 between a wireless communication device 80 and an external device 82 . A direct physical connection 84 can be made through a standard or proprietary cable connecting the external device 82 to the handset 80 . As an option, physical connection 84 may be achieved by coupling handheld device 80 to an external device in a manner that does not employ an actual cable coupling, so that the resulting coupled device is an integral unit.

FIG. 17B is a block diagram illustrating an exemplary direct wireless connection 85 between a wireless communication device 86 and an external device 88 . The direct wireless connection 85 can be accomplished through various wireless links, such as Bluetooth, infrared, or the 802.11 and 802.15 families of wireless communications.

FIG. 17C is a block diagram illustrating an exemplary remote wireless connection between the wireless communication device 90 and the external device 98 . The long-range wireless connection may include a link 96 between the external device 98 and the base station 94 , and a link between the handset 90 and the base station 94 . Interstitial networks and base stations (not shown) may also be included. The remote wireless connection may be established using conventional wireless communication protocols or long-range wireless network protocols such as the 802.11 and 802.15 families of wireless communications.

FIG. 3C is a block diagram illustrating the composition of data 240 of an exemplary wireless communication device 20 , 30 . In the illustrated embodiment, data 240 has a plurality of applications 242 , and applications 242 include external device detector 204 and runtime engine 230 . Other data elements 244 that may be included in application data 110 as shown in FIG. 2 include server operation code (opcode) library 210 , handset operation code library 220 , and runtime instructions 260 .

The external device detector 204 is preferably configured to determine when an external device is physically connected to the handheld device 20, 30, or when an external device is attempting to connect to the handheld device 20, 30 via a wireless link. Additionally, the external device detector 204 is preferably capable of detecting a pilot signal or other broadcast wireless signal to determine if an external device is in the vicinity of the handheld so that a connection can be made. The external device detector 204 may be implemented as a combination of electromechanical and software components for implementing the detection functionality.

Although Figures 3A, 3B, and 3C illustrate separate embodiments of the modular software interface 200, the modular hardware detector 202, and the external device detector 204, it should be understood that the interface 200, the hardware detector 202, and the external device The detectors 204 may be resident in the persistent storage area 240 of the communication device 20 in any combination.

FIG. 3D is a block diagram illustrating an exemplary operational code library and corresponding runtime instruction set 260 . The handheld device operating code library 220 and runtime instruction set 260 are preferably located in the data storage area 240 of the handheld device 20 , 30 . In one embodiment, executable instructions in runtime instruction set 260 correspond to operation codes contained in handset operation code library 220 in a one-to-one relationship. Alternatively, a single opcode in the handset opcode library 220 may correspond to a sequence of multiple executable instructions in the run-time instruction set 260 .

FIG. 3E is a block diagram illustrating an exemplary run-time instruction set 260 . In the illustrated embodiment, run-time instruction set 260 may contain any number of executable instructions, instruction 1 through instruction n. Optionally, there are a large number of functions in the runtime instruction set 260, however these functions consume very few resources of the handset 20, 30 (eg persistent memory).

4 is a flowchart illustrating an exemplary process for a user to initiate a download of a software module. Initially, at step 300, a handheld device receives an application request from a user. The request can be received, for example, via a modular software interface 200 . Next, at step 302, the runtime engine is started. Once running, the runtime engine compiles a set of server operation codes according to the required actions, as shown in step 304 . In this case, the set of server operation codes to be compiled is preferably used to download the requested software application or module. The set of server operation codes may be obtained from a background process running on the wireless device. Alternatively, the set of server operation codes may be obtained from a process running on the wireless device at the direction of the user. The compiled set of server operation codes preferably causes the server to respond to requested software modules as previously described.

For example, the wireless device receives instructions from the user to download an extension module for the phonebook application so that a total of 500 contacts can be maintained instead of the previous 100 contacts. The user provides the name or identifier of the new software module to be downloaded. Then, a set of server opcodes is compiled that instructs the modular soft server to provide the appropriate software modules to the handset so that the handset increases the total number of contacts. In this case, the result is a set of server operation codes generated by the runtime engine, as shown in step 304 .

Once the server operation code set is generated, the runtime engine includes name or identifier information in a data payload sent with the server operation code set. For example, the runtime engine may fetch application module data or software module data from persistent or volatile memory, or execute instructions for returning required data, eg, through the modular software interface 200 . Once the data is obtained, the runtime engine 230 next inserts the data into the server operation code set, as shown in step 306 . A simple way to do this is to add the data payload as a single packet to the set of server operation codes.

Once the data payload is merged with the server operation code set, the runtime engine sends the server operation code set with the corresponding data payload to the server, as shown in step 308 . The runtime engine may stop after sending the set of server operation codes with the data payload to free up resources on the wireless device, as shown in step 310 .

5 is a flow diagram illustrating an example process for activating a resident software module on a wireless communication device. The process shown in Figure 5 may be implemented by using a set of operation codes or by using some other means of wireless data communication. Initially, at step 320, the handset requests a license from a network license server. The software license manager 205 shown in Figure 3A preferably initiates this step. The network license server may be the same server as the update module server 60 or may be a separate server from the update module server 60 . Once the handheld device 20 , 30 has sent the request, it then receives a payment request from the network licensing server, as shown in step 322 . As shown in step 324, in response the handset provides payment details to the network licensing server.

In one embodiment, the handheld device can be configured to automatically provide payment details. As an option, the handheld device may be configured to request this information from the user to ensure that the user is willing to pay for the requested license. After the handset has sent the payment details, at step 326, the license server receives acknowledgment of receipt of the payment details. In one embodiment, this confirmation may serve as confirmation that the payment has been processed.

Once the handset has received the acknowledgment, it next receives a license or activation key from the license server at step 328 . The activation key is preferably configured to allow use of the application on the handheld device. As shown in step 330, once the activation key is received, the application can be activated.

6 is a flow diagram illustrating an exemplary process for network-initiating a software module download. Initially, at step 336, the wireless device receives a handset operation code set. The set of handset operation codes may be received over an air communication link, such as a link with a wireless communication network. The opcode is preferably optimized to minimize the amount of data sent over the air. Additionally, data payloads may be included in the set of opcodes received by the handset. In the illustrated embodiment, the handset operation code set is received from the network update module server 60 .

In step 338, the wireless device starts its runtime engine to process the handset opcode set. As an option, the handset may first authenticate the web server that sent the handset opcode set. As indicated at step 340 , the runtime engine parses the handset opcode set and then at step 342 extracts the data payload. If no data payload is present, this step is skipped, however, the network update module server 60 may include an executable software application in the initial transmission. Alternatively, the handset operation code set may instruct the handset to request the software module from the server. If there is a data payload, the resulting data is stored in an available portion of volatile memory for later use.

Next, at step 344, the runtime engine obtains executable instructions corresponding to the opcodes in the handset opcode set. These instructions may be obtained from a remote run-time instruction set stored in persistent storage in the handheld's data storage area.

Once the executable instructions corresponding to the opcodes in the handset opcode set are obtained, the runtime engine executes these instructions, as shown in step 346 . Any necessary data to be manipulated (or installed) may be obtained from the volatile memory storing the data payload upon execution of the above instructions. Alternatively or additionally, any necessary data to be manipulated may be obtained as a result of executing the instructions.

For example, the data payload may contain a software application that the network requests the handset to install. Furthermore, the one or more operation codes in the handset operation code set preferably correspond to one or more executable instructions for storing the data payload in the handset's persistent storage. In this embodiment, once the data payload containing the software modules is stored in persistent storage, the handheld device can then allow the user to use the application, or alternatively, use the application through a remote network command. As an option, the data payload may replace persistent memory housing obsolete software applications, modules, or portions of programs that were chosen to be removed to make room for new software modules. Accordingly, the handset operation code set and data payload are run on the wireless device to install new software modules for the handset. Additional opcodes and instructions may also be employed to configure new modules or applications after they are installed, if desired.

Once the above set of instructions are all executed, the runtime engine stops and the application program is executed, as shown in step 348 . A specific illustrative embodiment will explain how to initiate a download using the network. If the handset is in a lost or stolen vehicle, the handset can be contacted over the network and ordered to download the GPS module (assuming the handset has GPS capable hardware). Once downloaded and installed, the GPS module can report location information to the network, which in turn provides the location information to the vehicle's owner or authority for easy tracking of the vehicle. Advantageously, all of this can be done without the knowledge of those adjacent to the handheld device.

7 is a flow diagram illustrating an example process for installing a software module on a wireless communication device. Initially, at step 350, the wireless device receives a handset operation code set. The set of handset operation codes may be received over an air communication link, such as a link with a wireless communication network. The opcode is preferably optimized to minimize the amount of data sent over the air. Additionally, data payloads may be included in the set of opcodes received by the handset. In the illustrated embodiment, the handset operation code set is received from a network software module server.

At step 352, the wireless device starts its runtime engine to process the handset opcode set. As an option, the handset may first authenticate the web server that sent the handset opcode set. As indicated at step 354 , the runtime engine parses the handset opcode set and then at step 356 extracts the data payload. If no data payload is present, this step is skipped, however, the network software module server may include an executable software application in the initial transmission. As an option, the handset operating code set may instruct the handset to request software modules from the aforementioned servers. If there is a data payload, the resulting data is stored in an available portion of volatile memory for later use.

Next, at step 358, the runtime engine obtains executable instructions corresponding to the opcodes in the handset opcode set. These instructions may be obtained from a remote run-time instruction set stored in persistent storage in the handheld's data storage area. Once the runtime engine obtains the executable instructions corresponding to the opcodes in the handset opcode set, it executes these instructions, as shown in step 360 . Upon execution of the instructions, any necessary data to be manipulated (or installed) may be obtained from volatile memory storing the data payload. Alternatively or additionally, any necessary data to be manipulated may be a result of executing the instructions. Once the set of instructions has been fully executed, the runtime engine stops at step 362 and the application is made available, as shown at step 364 .

8 is a flow diagram illustrating an example process for terminating a software module on a wireless communication device. Initially, at step 370, the handset receives a termination notification. The termination notification may be received over a wireless communication network and may originate from a license server communicatively coupled to the handheld device over the network. In one embodiment, the termination notice may be tied to the trial period of the software module, or to the annual license fee for the module.

Once the handset receives the termination notice, it determines at step 372 whether it is instructed to automatically renew the license or pay the initial fee for the module. If the handset determines that it is not authorized or is instructed to automatically renew or pay, then at step 374 the handset notifies the user of the termination notification of the software module.

Notification may be by displaying a message on the display of the handheld device, or by generating a text message to be stored in memory of the handheld device for later viewing. Notifications can also be visual, such as a message on a display or a flashing light, or can be audible, such as a pre-recorded message or sound. As an option, a flashing light or sound (or vibration of the handheld device) may indicate that a message is available to the user, and the message may provide details of the termination notification. In addition, the handset can also send a message to the network (or the network can initiate the process) to save a pre-recorded voice message in the user's voicemail for the termination notification. Various other notification methods can be used, which will be understood by those skilled in the art.

Once the user has been notified of the termination notification, the handset receives the user's indication at step 376 . In step 378, the handset checks this indication to determine if the license should be renewed (or if the original fee was paid). If the instruction from the user is not to update (or not pay for), then at step 380 the handset deactivates the aforementioned software modules. In one embodiment, the handset may wait until the end of the pre-invalidation permission period or evaluation period. Additionally, if it is determined at step 378 that no indication has been received from the user, then the absence of an indication may be interpreted as a negative response and at step 380 the aforementioned software module is deactivated.

At step 378, if the handheld determines that the user's instruction is to update or pay, then the handheld sends an update command to the network or license server, as shown at step 382. Additionally, if at step 372 the handheld device determines that it is authorized to automatically make an update or payment, then at step 382 the handheld device will also send the appropriate command. (eg, the license server) validates payment by credit card debit or by adding a line item to the customer's bill for handheld device services at the end of receipt of the update instruction.

As shown in step 384, in response to payment or an instruction to perform an update, the handheld device may receive a license or key to instruct the software to continue running or to allow additional functionality. At step 386, the application is activated with a license or key so that the user can thereafter use the software module or application for a new license period.

9 is a flow diagram illustrating an exemplary process of paying for use of a software module on a wireless communication device. Initially, at step 390, the application may collect usage data for the application itself or other applications on the handheld device. These data may preferably be stored in a persistent memory of the handheld device. Next, at step 392 the runtime engine is started. Once running, the runtime engine can compile the server operation code set, as shown in step 394 . In step 396, the compiled set of server operation codes preferably causes the server to process the usage data contained in the corresponding data payload, wherein the usage data is inserted into (or added to) the set of operation codes .

Once the data payload is merged with the server operation code set, the runtime engine sends the server operation code set with the corresponding data payload to the server, as shown in step 398 . After the server opcode set and data payload are sent, the handset preferably receives billing details from the server, as shown in step 399 . The billing details preferably relate to usage data with the server operation code set set. Finally, the runtime engine is terminated to free resources on the wireless device.

13 is a flowchart illustrating an example process for obtaining brief information from new hardware components. Initially, at step 700 the handset is powered on. Preferably, the handheld device checks its various hardware components after power-up, eg, by communicating with each component to determine its status. Alternatively, if the handset is already running, the handset can initiate the same inspection process either actively (e.g., due to a predetermined event) or through external command (e.g., received from the network or the user) to determine the various hardware The state of the component.

Next, at step 702, the handheld device detects new hardware components. The new component need not be a component that will have a new function, but can be a replacement for the previous hardware module, such as a new display. After the handheld device detects a new hardware component, it determines the type of component at step 704, eg, screen, keyboard, wireless chipset, or similar device. The handset then interrogates the new component at step 706 for information related to the new component. At step 708, the handset receives the new component's information and preferably stores it in permanent or volatile memory. In one embodiment, the information of the new hardware module includes an identifier used to uniquely identify the new hardware module.

14 is a flowchart of an example process for requesting a device driver for a new hardware component from a remote server. Initially, at step 720 the runtime engine is started. Once running, the runtime engine can compile the server operation code set, as shown in step 722 . The set of server operation codes may be obtained from a background process running on the wireless device 20,30. Alternatively, the set of server operation codes may be obtained from a process running on the wireless device at the direction of the user. The compiled set of server operation codes preferably causes the server to reply with an executable device driver to allow the handset to communicate with the new hardware module and take full advantage of the functionality of the new hardware module.

For example, the wireless device detects that a new hardware module has been installed. Inquire about new hardware modules and get brief overview information. A server opcode set is compiled to instruct the server to provide the handheld with an executable device driver for the new hardware module so that the handheld can communicate with the new hardware module. In this case, the result is a set of server operation codes generated by the runtime engine, as shown in step 722 .

Once the server opcode set is generated, the runtime engine includes information about the new hardware module in the data payload corresponding to the server opcode set. For example, the runtime engine may fetch hardware module information from persistent or volatile memory, or execute instructions for returning required data. Once the data is obtained, the runtime engine next inserts the new hardware module information into the server opcode set, as shown in step 724 . A simple way to do this is to add the data payload as a single packet to the set of server operation codes.

Once the data payload is merged with the server operation code set, the runtime engine sends the server operation code set with the corresponding data payload to the server, as shown in step 726 . The runtime engine may stop after sending the server opcode set and data payload to free up resources on the wireless device, as shown in step 728 .

15 is a flowchart illustrating an exemplary process of installing a device driver for a new hardware component on a wireless communication device. Initially, at step 730, the wireless device receives a handset operation code set. The handset operation code set may be received over an air communication link, for example via a link with a wireless communication network. The opcode is preferably optimized to minimize the amount of data sent over the air. Additionally, data payloads may be included in the set of opcodes received by the handset.

At step 732, the wireless device starts its runtime engine to process the handset opcode set. As indicated at step 734 , the runtime engine parses the handset opcode set and then at step 736 extracts the data payload. The data payload is preferably stored in an available portion of volatile memory for later use. Next, as shown in step 738, the runtime engine obtains executable instructions corresponding to the opcodes in the handheld device opcode set. These instructions may be obtained from remote runtime instructions stored in persistent storage in the handheld's data storage area.

Once the executable instructions corresponding to the opcodes in the handset opcode set are obtained, the runtime engine executes these instructions, as shown in step 740 . Any necessary data to be manipulated upon execution of an instruction may be obtained from volatile memory storing the data payload. Alternatively or additionally, any necessary data to be manipulated may be a result of executing the instructions. Preferably, execution of the instruction set causes device drivers for new hardware modules to be installed on the handheld device.

For example, the data payload contains the device drivers that the handset needs to communicate with the new hardware module. Furthermore, the one or more operation codes in the handset operation code set preferably correspond to one or more executable instructions for storing the data payload in the handset's persistent storage. In this embodiment, once the data payload containing the device driver is stored in persistent storage, the handheld device can thereafter communicate with the new hardware module using the device driver (configured to take advantage of the functionality of the new hardware module).

As an option, the data payload may replace a portion of persistent storage containing obsolete device drivers for the replaced hardware component. Thus, the handset opcode set and data payload are run on the wireless device to install new device drivers for new hardware modules. After the new device driver is installed, additional opcodes and instructions may also be employed to configure the new device driver or other aspects of the handheld.

As shown in step 742, the runtime engine may stop once the instruction set has been fully executed. Advantageously, the runtime engine can be started and stopped so that it runs only when necessary. This saves system resources on the wireless device, such as volatile storage space, CPU cycles, and battery life can be saved. As shown in step 746, once the device driver for the new hardware module is installed and configured for use, the handheld device can begin using the new hardware module during normal operation.

16 illustrates a flow diagram of an example process for configuring new hardware components on a wireless communication device. Initially, at step 750, the handset sends a setup request to the new hardware module using the new device driver. Next, at step 752, the handset receives a response from the new hardware module. In one embodiment, the response may contain more comprehensive profile information about the hardware modules, which may be interpreted by the device driver to fine-tune the operation of the device. For example, the response may provide the device driver with additional information about the hardware component or its communication capabilities (such as the hardware component's interface version), or other information that makes communication between the device driver and the new hardware module more efficient.

Alternatively, as determined in step 754, the response may indicate that an attempted communication with the new hardware module failed. If the setup request receives a response indicating setup failure, the handset returns to step 750 and sends another setup request. In one embodiment, the handset may loop through a predetermined number (eg, N) of setup requests until a properly formatted request is provided for the new hardware component. For example, various setup requests may correspond to different versions of interfaces or different communication modes for a device driver.

There may also be synchronization issues with the repeated processing of device drivers and new hardware modules. Thus, receiving a successful response to a special build request can advantageously provide the device driver with important information: the version of firmware installed on the new hardware module, the capacity of the new hardware module, and other information related to the new hardware module. The result determined in step 754 is that a successful response from the new hardware module has been received, and the handheld device can continue to use the new hardware module during normal operation, as shown in step 756 . If no success response is received after N setup requests, the old device driver can be restored. Advantageously, backward compatible devices can operate with older device drivers, even though new or improved functionality may not be available in the older device drivers.

Figure 18 shows a flowchart illustrating an exemplary process for obtaining brief information from an external device for another embodiment of the present invention. Initially, at step 800 the handset detects a connection from an external device. Connections can be detected over wired or wireless links. As shown in step 802, after the handheld device detects the connection, it determines whether the connection is initiated by the user. For example, a user may press a series of keys or issue a verbal command to command a handheld connected to a new device. In one embodiment, brief device information is provided directly to the handset by the user if the connection is initiated by the user. In such an embodiment, the handset then stores the brief device information at step 804 .

Alternatively, if the detection was not initiated by the user, the handset then formulates a query for the external device, as shown in step 806 . The query may advantageously conform to a standard protocol, or may be a proprietary protocol. Once the query is formulated, the handset sends the query at step 808 to the external device. At step 810, the handset determines whether a valid response has been received from the external device. If there is no response or the response is invalid, the handset returns to step 806 to reformulate the query and continue to query the external device. Advantageously, the handheld device can cycle through various known challenge formats and protocols until a valid response is received. Upon receipt of a valid response, preferably including brief profile information about the external device, the handset stores the brief profile information, as shown in step 304 .

19 is a flowchart illustrating an exemplary process for requesting interface software from a remote server. Initially, at step 820 the runtime engine is started. Once running, the runtime engine can compile the set of server operation codes, as shown in step 822 . The set of server operation codes may be obtained from a background process running on the wireless device. Alternatively, the set of server operation codes may be obtained from a process running on the wireless device at the direction of the user. The compiled set of server operation codes preferably causes the server to reply with an executable interface for the particular external device connected to the handheld.

For example, a wireless device detects a connection from an external device. Ask about external devices and get concise overview information. A set of server opcodes is compiled for instructing the server to provide the handheld device with an executable interface for the external device so that the handheld device communicates with the external device. In this case, the result is a set of server operation codes generated by the runtime engine, as shown in step 822 .

Once the server operation code set is generated, the runtime engine includes information for the external device in the data payload corresponding to the server operation code set. For example, the runtime engine may fetch compact profile data from persistent or volatile memory, or execute instructions for returning the required data. Once the data is obtained, the runtime engine next inserts the data into the server operation code set, as shown in step 824 . A simple way to do this is to add the data payload as a single packet to the set of server operation codes.

Once the data payload is merged with the server operation code set, the runtime engine sends the server operation code set with the corresponding data payload to the server, as shown in step 826 . After sending the server opcode set and data payload, the runtime engine can be stopped to release resources on the wireless device, as shown in step 828.

20 is a flow diagram illustrating an example process for installing interface software on a wireless communication device. Initially, at step 830, the wireless device receives a handset operation code set. The hand-held device operation code set may be received over an air communication link, such as a link with a wireless communication network. The opcode is preferably optimized to minimize the amount of data sent over the air. Additionally, data payloads may be included in the set of opcodes received by the handset.

At step 832, the wireless device starts its runtime engine to process the handset opcode set. As indicated at step 834 , the runtime engine parses the handset opcode set and then at step 836 extracts the data payload. If no data payload is present, this step can be skipped, and if present, the resulting data is stored in an available portion of the volatile memory for later use. Next, as shown in step 838, the runtime engine obtains executable instructions corresponding to the operation codes in the handset operation code set. These instructions may be obtained from a remote runtime instruction set stored in persistent storage in the data storage area of the handset.

Once the executable instructions corresponding to the opcodes in the handset opcode set are obtained, the runtime engine executes these instructions, as shown in step 840 . As instructions are executed, any necessary data to be manipulated is available from volatile memory which stores the data payload. Alternatively or additionally, any necessary data to be manipulated may be a result of executing the instructions.

For example, the data payload may contain the interface that the handheld needs to use to communicate with external devices. Furthermore, the one or more operation codes in the handset operation code set preferably correspond to one or more executable instructions for storing the data payload in the handset's persistent storage. In this embodiment, once the data payload containing the interface is stored in persistent storage, the handheld device can then communicate with the device using the executable interface. As an option, the data payload may replace a portion of persistent storage that contains an obsolete interface for a particular external device. Thus, the handset opcode set and data payload run on the wireless device to install the new interface for the external device. Additional opcodes and instructions can also be used to configure the new interface once it is installed, if desired.

As shown in step 842, the runtime engine may stop once the instruction set has been fully executed. Advantageously, the runtime engine can be started and stopped so that it runs only when necessary. This saves system resources on the wireless device, such as saving volatile memory space and CPU cycles. Once the interface for the external device is installed and configured for use, the handset can begin communicating with the external device, as shown in step 846 .

21 is a flow diagram illustrating an example process for initializing an external device. Initially, at step 850, the handset utilizes the new interface to send a setup request to the external device. Next, at step 852, the handset receives a response from the external device. In one embodiment, the response may contain more comprehensive profile information about the external device. For example, the response may provide the handset with additional information related to the communication interface, such as the version of the interface, or other information to make communication between the devices more efficient.

Alternatively, as a result of the determination in step 854, the response indicates that initialization of the external device has failed. If the setup request receives a response indicating setup failure, the handset returns to step 850 and sends another setup request. In one embodiment, the handset may loop through the various setup requests until a properly formatted request is provided to the external device. For example, various build requests may correspond to different versions of the interface. Thus, receiving a successful response to a particular setup request may advantageously provide the handset with important information about the version of firmware installed on the external device, the capabilities of the external device, and other information about the external device. Once a successful response is received from the external device, as shown in step 854, the handset may exchange information with the external device, as shown in step 856.

Figure 10 is a block diagram illustrating an exemplary wireless communication device 450 that may be used with various embodiments described herein. For example, wireless communication device 450 may be used with a handheld device or PDA network device, or may be used as part of a sensor node in a wireless mesh network. However, it will be apparent to those skilled in the art that other wireless communication devices and/or configurations may be used.

In the illustrated embodiment, the wireless communication device 450 includes an antenna 452, a multiplexer 454, a low noise amplifier (LNA) 456, a power amplifier (PA) 458, a modulation circuit 460, a baseband processor 462, a speaker 464, Microphone 466 , central processing unit (CPU) 468 , data storage 470 and hardware interface 472 . In wireless communication device 450 , radio frequency (RF) signals are transmitted and received by antenna 452 . Multiplexer 454 acts as a switch for coupling antenna 452 between transmit and receive signal paths. In the receive path, the received RF signal is coupled from multiplexer 454 to LNA 456. LNA 456 amplifies the received RF signal and couples the amplified signal to the demodulation section of modulation circuit 460.

Typically, modulation circuit 460 will combine a demodulator and modulator in one integrated circuit (IC). The demodulator and modulator can also be discrete components. The demodulator removes the RF carrier signal, leaving the baseband receive signal, which is sent from the output of the demodulator to the baseband processor 462 .

If the baseband received audio signal contains audio information, the baseband processor 462 decodes and converts the signal to an analog signal. The signal is then amplified and sent to speaker 464 . The baseband processor 462 also receives analog audio signals from a microphone 466 . The baseband processor 462 converts these analog audio signals into digital signals and encodes them. The baseband processor 462 also encodes the digital signal for transmission and generates a baseband transmit audio signal that is routed to the modulator portion of the modulation circuit 460 . The modulator mixes the baseband transmit audio signal with the RF carrier signal to generate an RF transmit signal that is routed to power amplifier 458 . Power amplifier 458 amplifies the RF transmit signal and routes it to multiplexer 454 where the signal is switched from antenna 452 to the antenna section for transmission.

Baseband processor 462 is also communicatively coupled with central processing unit 468 . Central processing unit 468 accesses data storage area 470 . Central processing unit 468 is preferably configured to execute instructions (ie, computer programs or software) that can be stored in data storage area 470 . Computer programs may be received from baseband processor 462 and stored in data storage area 470, or executed upon receipt. Such a computer program, when executed, enables the wireless communication device 450 to perform various functions of the present invention as described above.

In this specification, the term “computer-readable medium” refers to any medium used to provide executable instructions to wireless communication device 450 for execution by central processing unit 468 . Examples of these media include data storage area 470 , microphone 466 (via baseband processor 462 ), antenna 452 (also via baseband processor 462 ), and hardware interface 472 . These computer-readable media are means for providing executable codes, programming instructions, and software to wireless communication device 450 . The executable code, programming instructions, and software, when executed by the central processing unit 468, preferably cause the central processing unit 468 to implement the inventive features and functions previously described herein.

The central processing unit is also preferably configured to receive a notification from the hardware interface 472 when the hardware interface 472 detects a new device. The hardware interface 472 may be a combination of electromechanical detectors and control software and is capable of communicating with the CPU 468 and interacting with new devices.

FIG. 11 is a block diagram illustrating an exemplary computer system 550 that may be used with various embodiments described herein. For example, computer system 550 may be used with a remote server configured to process server operation code sets, and generate and transmit handset operation code sets. However, it will be apparent to those skilled in the art that other computer systems and/or architectures may be used.

Computer system 550 preferably includes one or more processors, such as processor 552 . Additional processors may be provided, such as a secondary processor for managing input/output, a secondary processor for performing floating-point mathematical operations, a special-purpose microprocessor with an architecture suitable for fast execution of signal processing algorithms (such as digital signal processor), a slave processor (such as a back-end processor) subordinate to a main processing system, an additional microprocessor or controller for a dual-processor system or a multi-processor system, or a co-processor. Such a secondary processor may be a separate processor, or may be integrated with processor 552 .

The processor 552 is preferably connected to a communication bus 554 . Communication bus 554 may include data channels that facilitate the transfer of information between memory elements and other peripheral elements of computer system 550 . Communication bus 554 may further provide a set of signals for communicating with processor 552, where communication bus 554 includes a data bus, an address bus, and a control bus (not shown). Communication bus 554 may comprise any standard or non-standard bus structure, such as a bus structure compliant with Industry Standard Architecture (ISA), Extended Industry Standard Architecture (EISA), Micro Channel Architecture (MCA), Peripheral Component Interconnect (PCI) Local buses, or standards published by the Institute of Electrical and Electronics Engineers (IEEE), which include IEEE 488 General Purpose Interface Bus (GPIB), IEEE 696/S-100, and others.

The computer system 550 preferably includes a main memory 556 and may also include a secondary memory 558 . Main memory 556 stores instructions and data for programs executing on processor 552 . Main memory 556 is typically a semiconductor-based memory, such as dynamic random access memory (DRAM) and/or static random access memory (SRAM). Other semiconductor-based memory types include, for example, synchronous dynamic random access memory (SDRAM), memory bus dynamic random access memory (RDRAM), ferroelectric random access memory (FRAM), etc., which also includes read only memory (ROM).

Secondary storage 558 optionally includes a hard disk drive 560 and/or a removable storage drive 562 such as a floppy disk drive, tape drive, compact disk (CD) drive, digital video disk (DVD) drive, or the like. Removable storage drive 562 reads and writes to removable storage medium 564 in a known manner. The removable storage medium 564 can be, for example, a floppy disk, magnetic tape, CD, DVD, and the like.

The removable storage medium 564 is preferably a computer-readable medium having computer-executable code (ie, software) and/or data stored thereon. Computer software or data stored on removable storage medium 564 is read into computer system 550 as electrical communication signal 578 .

In alternative embodiments, secondary storage 558 may include other similar means for allowing computer programs and other data or instructions to be loaded into computer system 550 . Such means may include, for example, an external storage medium 572 and an interface 570 . Examples of external storage media 572 may include an external hard drive, an external optical drive, or an external magneto-optical drive.

Other embodiments of secondary memory 558 may include semiconductor-based memory such as programmable read-only memory (PROM), erasable programmable read-only memory (EEPROM), or flash memory (block-oriented memory similar to EEPROM). Other embodiments of secondary storage 558 include any other removable storage unit 572 and an interface 570 that allows software and data to be transferred from removable storage unit 572 to computer system 550 .

Computer system 550 may also include a communication interface 574 . Communication interface 574 allows software and data to be transferred between computer system 550 and external devices (eg, printers), networks or information sources. For example, computer software or executable code may be transferred from a web server to computer system 550 through communication interface 574 . Examples of communication interface 574 include a modem, network interface card (NIC), communication port, PCMCIA slot and card, infrared interface, and IEEE 1394 fire-wire, just to name a few.

The communication interface 574 preferably implements industry promulgated protocol standards such as Ethernet IEEE 802 standard, Fiber Channel, Digital Subscriber Line (DSL), Asymmetric Digital Subscriber Line (ADSL), Frame Relay, Asynchronous Transfer Mode (ATM), Integrated Digital Services Network (ISDN), Personal Communications Services (PCS), Transmission Control Protocol/Internet Protocol (TCP/IP), Serial Line Interface Protocol/Point-to-Point Protocol (SLIP/PPP), etc., but communication interface 574 can also implement custom or Non-standard interface protocol.

Software and data transmitted over communication interface 574 is typically in the form of electrical communication signals 578 . Signal 578 is preferably provided to communication interface 574 via communication channel 576 . Communication channel 576 carries signal 578 and can be implemented using a variety of communication means including wire or cable, optical fiber, conventional telephone line, cellular phone link, radio frequency (RF) link, or infrared link, just to name a few. kind.

Computer-executable code (ie, computer programs or software) is stored in main memory 556 and secondary memory 558 . Computer programs may also be received through communication interface 574 and may also be stored in main memory 556 and/or secondary memory 558 . Such a computer program, when executed, enables the computer system 550 to perform the various functions of the invention as previously described.

In this specification, the term “computer-readable medium” refers to any medium used to provide computer-executable code (eg, software and computer programs) to the computer system 550 . Examples of such media include main memory 556, secondary storage 558 (including hard drive 560, removable storage media 564, and external storage media 572), and any peripheral devices communicatively coupled to communication interface 574 (including network information servers or other Internet equipment). These computer-readable media are means for providing executable code, programming instructions and software to the computer system 550 .

In an embodiment implemented in software, the software may be stored on a computer readable medium and loaded into computer system 550 via removable memory drive 562 , interface 570 or communication interface 574 . In such an embodiment, the software is loaded into computer system 550 in the form of electrical communication signal 578 . The software, when executed by the processor 552, preferably causes the processor 552 to implement the inventive features and functions previously described herein.

Various embodiments may also be implemented primarily in hardware, such as an Application Specific Integrated Circuit (ASIC) or a Field Programmable Gate Array (FPGA). The implementation of a hardware state machine capable of implementing the functionality described herein will be apparent to those skilled in the art. Various embodiments may also be implemented using a combination of hardware and software.

While the specific modular software components for a wireless communication device shown and described in detail herein are fully capable of accomplishing the above objects of the present invention, it should be understood that the specification and drawings presented herein represent presently preferred embodiments of the present invention. schemes, and thus represent broadly contemplated subject matter of the present invention. It is further to be understood that the scope of the present invention fully encompasses other embodiments which would be obvious to those skilled in the art, and therefore the scope of the present invention is limited only by the appended claims.

Claims (6)

1. A method of dynamically installing a data component (240) on a wireless communication device (20, 30) in use, comprising: receiving a request to install the data component, the request including a unique identifier of the requested data component; launching a runtime engine (230) to compile a set of opcodes to be sent to the remote server, the set of opcodes having a data payload including the unique identifier; sending said set of operation codes to said remote server (60) via a wireless communication network (50); and receiving a response from said remote server (60) via a wireless communication network (50), wherein said response contains said data component (240) of the request, Wherein, the data components are executable device drivers and installation instructions for new hardware components, and the method further includes the following steps: A modular hardware detector (202) of the wireless communication device in the wireless Detect the presence of new hardware components in the wireless communication device, the new hardware components are used to replace the In place of a previous hardware component having a previous device hardware drivers; and The modular hardware detector (202) interrogates the new hardware component to obtaining profile information of said new hardware component; Wherein said unique identifier comprises at least a portion of said profile information. 2. The method of claim 1, wherein the step of receiving a response from the remote server further comprises: receiving said set of instructions with a corresponding data payload; extracting the data payload, wherein the data payload includes the requested data components; obtaining an executable set of instructions corresponding to said set of instructions from a handheld device operating code library (220) of said wireless communication device (20, 30) used; and Executing the executable set of instructions. 3. The method of claim 2, wherein said step of executing an executable instruction set is implemented within said runtime engine (230) running on said wireless communication device (20, 30) of said use . 4. The method of claim 2, further comprising the steps of: install said executable device driver; and The new hardware component is configured. 5. The method of claim 2, wherein the instruction set has a series of operation codes, the method further comprising: converting said series of operation codes into an executable instruction set comprising said installation instructions; and The executable instruction set is extracted to install the executable device driver with the runtime engine running on the wireless communication device. 6. The method of claim 2, further comprising: determining that the size of the previous device driver is greater than the size of the executable device driver; copying said previous device driver onto volatile memory; deleting said previous device driver from said persistent storage; and The executable device driver for the new hardware component is stored in at least a portion of the persistent memory previously occupied by the previous device driver.

Images