CA2267549A1 - Loading and unloading of application components - Google Patents
Loading and unloading of application components Download PDFInfo
- Publication number
- CA2267549A1 CA2267549A1 CA002267549A CA2267549A CA2267549A1 CA 2267549 A1 CA2267549 A1 CA 2267549A1 CA 002267549 A CA002267549 A CA 002267549A CA 2267549 A CA2267549 A CA 2267549A CA 2267549 A1 CA2267549 A1 CA 2267549A1
- Authority
- CA
- Canada
- Prior art keywords
- software
- memory
- application
- computer
- computing device
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
- G06F9/44594—Unloading
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/22—Processing or transfer of terminal data, e.g. status or physical capabilities
- H04W8/24—Transfer of terminal data
- H04W8/245—Transfer of terminal data from a network towards a terminal
Abstract
In order to meet customer requirements for new or upgraded services for embedded, wireless devices, such as cellular telephones, an effective mechanism to identify what new applications can be downloaded from a server to the device is required. In the invention, applications packaged as application components include information specifying the memory use in "flash-type" memory or ROM and RAM and pre-requisite software required to download and run the application. If the device does not have adequate memory available to download the application and any additional pre-requisite software not already on the device, a decision can be made, either by the user or through a predetermined default mechanism, to unload other applications until the requisite memory has been made available.
Description
LOADING AND UNLOADING OF APPLICATION COMPONENTS
Field of the Invention This application is directed to a lightweight and reusable software component architecture ideally suited for building resource-constrained embedded products, such as products which will be connected to back-end server systems using a wireless or other relatively low-speed network.
However, the invention is not limited to use in resource - constrained environments.
Background of the Invention The field of embedded, wireless products, particularly in the communications arena, emphasize device size/portability and cost. Thus, devices such as cellular telephones, pagers and automotive navigational systems are designed to be built with the least number and lowest cost of hardware components. This means that the smallest memory footprint and slowest processor possible to meet the performance requirements of the device are often used.
An embedded, wireless communications device is usually a member of a family of similar devices, addressing different points on price performance curves. This technology is rapidly evolving into an industry offering multiple functions in a single device. A good example is the recent introduction of "Personal Communication Services" (PCS). Through the use of the increased bandwidth in digital transmission, PCS wireless handsets or cellular telephones provide additional services not found on traditional analog cellular telephones, such as security, call display, voice mail and calendaring. Other personal wireless communications devices currently offer email/messaging and Internet access. The technology is converging, and soon, all these services and more can be made available for a single hardware platform.
However, due to constraints on memory capacity common to embedded devices, a selection of applications providing different services and/or service levels will have to be made available for such devices. Also, not every customer will want (or want to pay for) the same service set as others - the services required by a journalist may not be the same as those required by a lawyer or plumber. This degree of personalization adds complexity to the provision of applications and services in the new technology of personal wireless communication devices.
The manufacturer would ideally like to eliminate hardware/software interdependencies in order to separate the software and hardware selection processes so that a single hardware offering can be used to offer a range of software services on a vertical pricing structure.
However, to do this, a number of hurdles must be overcome. These include application creation, application deployment and product maintenance.
First, because the technology and customer requirements are evolving so rapidly, application creation must be easy and fast. Second, installing and removing applications onto the target device must be done in the field, often over a connection to the server that is slow and expensive. Finally, software maintenance must be done without returning the product to the factory or service centre, ideally in the field, either by the user or as a background task.
In addition, the software supplier does not want to maintain separate databases containing downloadable applications for each model of device or version of software currently on the market.
Summary of the Invention It was the desire to address issues such as resource constraint and remote downloading of new applications that resulted in the present invention.
Although the invention is ideally suited for these types of environments, it will be obvious to the person skilled in the art that the use of the invention is not limited to such environments. It is an obj ect of the present invention to provide a framework with default implementations for developing and deploying applications over a wireless or a low speed network medium which permits the efficient loading, updating and operation particularly of resource constrained embedded devices.
It is also a object of the present invention to provide a means to differentiate customer requirements so that software can be stored economically in a single database or file system on a server, and distributed on demand.
According to these and other objects, the present invention provides a framework for upgrading software in a target computing device having non-volatile memory and volatile memory. The framework includes means for identifying non-volatile memory requirement, volatile memory requirement, and pre-requisite software requirements for downloading and running a desired application in the target computing device, and comparator means to determine whether the target currently has available the memory and pre-requisite software requirements prior to commencing a download of the desired application.
The invention also provides a method for downloading a desired software application from a server to a target computing device. One receiving a request for the desired software application, a set of the software component required to run the desired software application is obtained. This is subsetted to a list of the software components required to be downloaded to the target computing device. The memory requirements for the subset list is compared with the free memory available in the target computing device.
Where there is insufficient free memory, software can be unloaded from the target computing device.
The methods for performing the invention can be embodied in software encoded on computer media or m computer memory.
Brief Description of the Drawings Embodiments of the invention will now be described in detail in association with accompanying drawings, in which:
Figure 1 is schematic diagram showing the remote networking environment of a preferred embodiment of the present invention;
Figure 2 is a schematic diagram of the system layout of a target device according to the invention;
Figure 3 is a flow diagram of the steps in the server/device for deciding to download a particular application component and its prerequisites according to a preferred embodiment of the invention;
S Figure 4 is a flow diagram of application component loading and initialization, according to the invention; and Figure 5 is a flow diagram showing application component unloading, according to the preferred embodiment of the invention.
Detailed Description of the Preferred Embodiments Figure 1 schematically illustrates a networking environment in which multiple remote clients 2 are in sporadic communication, over a wireless transmission medium 4 (e.g., a radio bandwidth), with a local network 6. The network 6 connects a plurality of specialized servers 8, such as application servers, content servers, user data servers, billing systems, proxy servers and user administration, which provide these services directly or indirectly to the clients 2. The network 6 may also have a gateway 10 to an external network 12, such as the Internet.
The software architecture of the present invention is based on virtual machine ("VM") technologies which are implemented in interpreted programming language environments such as Smalltalk and JavaTM' . These technologies have been used in embedded systems experimentally for over a decade.
With increasing complexity and the changing requirements of connected embedded products, VM
technologies are now cost-effective and competitive.
As shown schematically in Figure 2, the system in a target device consists of several layers of software, collectively designated as 22, on top of the hardware base 20. The device's hardware base 20 includes a microprocessor, non-volatile memory (generally reffered to as read only memory or ROM) and volatile memory (generally referred to as random access memory or RAM). The software ' Java is a trademark of Sun Microsystems, Inc.
22 contained in the layers above the hardware includes startup code, device drivers, operating systems and application level code.
The lowest layer of software 26 is the operating system and its associated device drivers, including the memory manager and the graphics driver. This layer is ported to the specific hardware platform, and it requires detailed knowledge of the hardware and its usage. In small devices, a real time operating system is often selected for reasons of size and performance. In some smaller devices, an operating system is not required and can be replaced with some form of device interface code containing only the drivers.
The second software layer 28 is the virtual machine (VM), which is ported to the hardware platform and the selected operating system. Typically, the VM layer 28 is linked directly with the operating system layer 26 together into a single executable and stored in flash memory (which is non-volatile, erasable memory) or other type of ROM. This single executable can then be placed or copied into RAM for execution at runtime.
The VM is the program that provides the execution environment on a single machine. It maps data and logic to the executing machine architecture, isolating the development code from the architecture of the machine. The VM initializes its own data structures and reserves a predetermined amount of memory for the image. The VM manages a preallocated RAM segment for image memory (new and old spaces) as well as preallocated flash memory segments where the application components are stored.
At the highest level is the image 24 which consists of the class definitions, method byte codes and the objects that define the applications and supporting code. The VM 28 isolates this layer from the actual machine making this layer portable and reusable. An image can be packaged into and delivered/managed as one or more application components. This aspect is discussed in detail below.
The image 24 is not a monolith, but has its own layers. These layers provide organization and partitioning opportunities to allow system engineers to integrate functionality from multiple sources.
The bottom layer of the image 24 is called the base system 30. This layer contains the base classes used by the VM below and the subsystems and applications above. It provides the basic functionality, to all the dependent applications, such as the run time environment, the common data types and the other language implementation support classes.
Part of the base system 30 are the core subsystems that define the characteristics of the products.
These include the user interface, the network interface, the local persistence system, the application management frameworks and various platform-specific subsystems. These subsystems are typically built and linked directly with the core system.
On top of the base system 30 is usually the application layer. Applications 34 use the service provided by the base AC and core subsystems in the base system 30 to provide the functionality to be delivered to the end user. Optionally applications can use shared application components 32.
These can act as common code libraries or services used by more than one application component 34. Shared application components 36 that are required by an application component 34 to function are prerequisite image components and have to be loaded before the application component 34 can be loaded. There is technically no limit on the number of layers of shared application components 32, but most system will limit it to one layer to reduce the complexity of managing the application components on the server and in the device.
According to the preferred embodiment of the invention, the image may be packaged as multiple application components, with some application components acting as prerequisites (shared application components) for others. An application component ("AC") is a file of one or more classes used to construct the layers of the image in a operating device. The application layers for a target platform can be packaged as application components which are downloadable, reusable and unloadable.
The building of application (or image) components is discussed in a concurrently filed application titled "Packaging Memory Image Files" (IBM docket no. CA9-99-005), which is commonly assigned. For the purposes of the present invention, it is important to understand that an application component includes memory segment descriptors with sufficient information about the application component requirements to permit it to be downloaded on the fly from a database on a remote server to an embedded device and run on the device.
These requirements include:
1. The application component's own identity;
Field of the Invention This application is directed to a lightweight and reusable software component architecture ideally suited for building resource-constrained embedded products, such as products which will be connected to back-end server systems using a wireless or other relatively low-speed network.
However, the invention is not limited to use in resource - constrained environments.
Background of the Invention The field of embedded, wireless products, particularly in the communications arena, emphasize device size/portability and cost. Thus, devices such as cellular telephones, pagers and automotive navigational systems are designed to be built with the least number and lowest cost of hardware components. This means that the smallest memory footprint and slowest processor possible to meet the performance requirements of the device are often used.
An embedded, wireless communications device is usually a member of a family of similar devices, addressing different points on price performance curves. This technology is rapidly evolving into an industry offering multiple functions in a single device. A good example is the recent introduction of "Personal Communication Services" (PCS). Through the use of the increased bandwidth in digital transmission, PCS wireless handsets or cellular telephones provide additional services not found on traditional analog cellular telephones, such as security, call display, voice mail and calendaring. Other personal wireless communications devices currently offer email/messaging and Internet access. The technology is converging, and soon, all these services and more can be made available for a single hardware platform.
However, due to constraints on memory capacity common to embedded devices, a selection of applications providing different services and/or service levels will have to be made available for such devices. Also, not every customer will want (or want to pay for) the same service set as others - the services required by a journalist may not be the same as those required by a lawyer or plumber. This degree of personalization adds complexity to the provision of applications and services in the new technology of personal wireless communication devices.
The manufacturer would ideally like to eliminate hardware/software interdependencies in order to separate the software and hardware selection processes so that a single hardware offering can be used to offer a range of software services on a vertical pricing structure.
However, to do this, a number of hurdles must be overcome. These include application creation, application deployment and product maintenance.
First, because the technology and customer requirements are evolving so rapidly, application creation must be easy and fast. Second, installing and removing applications onto the target device must be done in the field, often over a connection to the server that is slow and expensive. Finally, software maintenance must be done without returning the product to the factory or service centre, ideally in the field, either by the user or as a background task.
In addition, the software supplier does not want to maintain separate databases containing downloadable applications for each model of device or version of software currently on the market.
Summary of the Invention It was the desire to address issues such as resource constraint and remote downloading of new applications that resulted in the present invention.
Although the invention is ideally suited for these types of environments, it will be obvious to the person skilled in the art that the use of the invention is not limited to such environments. It is an obj ect of the present invention to provide a framework with default implementations for developing and deploying applications over a wireless or a low speed network medium which permits the efficient loading, updating and operation particularly of resource constrained embedded devices.
It is also a object of the present invention to provide a means to differentiate customer requirements so that software can be stored economically in a single database or file system on a server, and distributed on demand.
According to these and other objects, the present invention provides a framework for upgrading software in a target computing device having non-volatile memory and volatile memory. The framework includes means for identifying non-volatile memory requirement, volatile memory requirement, and pre-requisite software requirements for downloading and running a desired application in the target computing device, and comparator means to determine whether the target currently has available the memory and pre-requisite software requirements prior to commencing a download of the desired application.
The invention also provides a method for downloading a desired software application from a server to a target computing device. One receiving a request for the desired software application, a set of the software component required to run the desired software application is obtained. This is subsetted to a list of the software components required to be downloaded to the target computing device. The memory requirements for the subset list is compared with the free memory available in the target computing device.
Where there is insufficient free memory, software can be unloaded from the target computing device.
The methods for performing the invention can be embodied in software encoded on computer media or m computer memory.
Brief Description of the Drawings Embodiments of the invention will now be described in detail in association with accompanying drawings, in which:
Figure 1 is schematic diagram showing the remote networking environment of a preferred embodiment of the present invention;
Figure 2 is a schematic diagram of the system layout of a target device according to the invention;
Figure 3 is a flow diagram of the steps in the server/device for deciding to download a particular application component and its prerequisites according to a preferred embodiment of the invention;
S Figure 4 is a flow diagram of application component loading and initialization, according to the invention; and Figure 5 is a flow diagram showing application component unloading, according to the preferred embodiment of the invention.
Detailed Description of the Preferred Embodiments Figure 1 schematically illustrates a networking environment in which multiple remote clients 2 are in sporadic communication, over a wireless transmission medium 4 (e.g., a radio bandwidth), with a local network 6. The network 6 connects a plurality of specialized servers 8, such as application servers, content servers, user data servers, billing systems, proxy servers and user administration, which provide these services directly or indirectly to the clients 2. The network 6 may also have a gateway 10 to an external network 12, such as the Internet.
The software architecture of the present invention is based on virtual machine ("VM") technologies which are implemented in interpreted programming language environments such as Smalltalk and JavaTM' . These technologies have been used in embedded systems experimentally for over a decade.
With increasing complexity and the changing requirements of connected embedded products, VM
technologies are now cost-effective and competitive.
As shown schematically in Figure 2, the system in a target device consists of several layers of software, collectively designated as 22, on top of the hardware base 20. The device's hardware base 20 includes a microprocessor, non-volatile memory (generally reffered to as read only memory or ROM) and volatile memory (generally referred to as random access memory or RAM). The software ' Java is a trademark of Sun Microsystems, Inc.
22 contained in the layers above the hardware includes startup code, device drivers, operating systems and application level code.
The lowest layer of software 26 is the operating system and its associated device drivers, including the memory manager and the graphics driver. This layer is ported to the specific hardware platform, and it requires detailed knowledge of the hardware and its usage. In small devices, a real time operating system is often selected for reasons of size and performance. In some smaller devices, an operating system is not required and can be replaced with some form of device interface code containing only the drivers.
The second software layer 28 is the virtual machine (VM), which is ported to the hardware platform and the selected operating system. Typically, the VM layer 28 is linked directly with the operating system layer 26 together into a single executable and stored in flash memory (which is non-volatile, erasable memory) or other type of ROM. This single executable can then be placed or copied into RAM for execution at runtime.
The VM is the program that provides the execution environment on a single machine. It maps data and logic to the executing machine architecture, isolating the development code from the architecture of the machine. The VM initializes its own data structures and reserves a predetermined amount of memory for the image. The VM manages a preallocated RAM segment for image memory (new and old spaces) as well as preallocated flash memory segments where the application components are stored.
At the highest level is the image 24 which consists of the class definitions, method byte codes and the objects that define the applications and supporting code. The VM 28 isolates this layer from the actual machine making this layer portable and reusable. An image can be packaged into and delivered/managed as one or more application components. This aspect is discussed in detail below.
The image 24 is not a monolith, but has its own layers. These layers provide organization and partitioning opportunities to allow system engineers to integrate functionality from multiple sources.
The bottom layer of the image 24 is called the base system 30. This layer contains the base classes used by the VM below and the subsystems and applications above. It provides the basic functionality, to all the dependent applications, such as the run time environment, the common data types and the other language implementation support classes.
Part of the base system 30 are the core subsystems that define the characteristics of the products.
These include the user interface, the network interface, the local persistence system, the application management frameworks and various platform-specific subsystems. These subsystems are typically built and linked directly with the core system.
On top of the base system 30 is usually the application layer. Applications 34 use the service provided by the base AC and core subsystems in the base system 30 to provide the functionality to be delivered to the end user. Optionally applications can use shared application components 32.
These can act as common code libraries or services used by more than one application component 34. Shared application components 36 that are required by an application component 34 to function are prerequisite image components and have to be loaded before the application component 34 can be loaded. There is technically no limit on the number of layers of shared application components 32, but most system will limit it to one layer to reduce the complexity of managing the application components on the server and in the device.
According to the preferred embodiment of the invention, the image may be packaged as multiple application components, with some application components acting as prerequisites (shared application components) for others. An application component ("AC") is a file of one or more classes used to construct the layers of the image in a operating device. The application layers for a target platform can be packaged as application components which are downloadable, reusable and unloadable.
The building of application (or image) components is discussed in a concurrently filed application titled "Packaging Memory Image Files" (IBM docket no. CA9-99-005), which is commonly assigned. For the purposes of the present invention, it is important to understand that an application component includes memory segment descriptors with sufficient information about the application component requirements to permit it to be downloaded on the fly from a database on a remote server to an embedded device and run on the device.
These requirements include:
1. The application component's own identity;
2. A list of prerequisite application components required for this application component to run; and 3. The size requirements, both for loading the application component in ROM
and for running it in RAM.
In the preferred embodiment, the application component's own identity is provided by a marker identifying the component as an image and by a pair of time stamps. One time stamp is a version time stamp used to indicate with which version the application component is compatible; the other is a unique time stamp indicating the unique build date for the particular application component.
Each application component requires a base application component and some random number of other application components, providing user interface, network and other basic support, that it requires to run. In the preferred embodiment, this information is provided by a list identifying the prerequisite application components by name and a list of pointers (addresses) to memory segments inside the prerequisite application components.
Application components must know how much ROM (flash memory) and RAM
(including runtime requirements) they need. Runtime requirements are identified at build time.
These size requirements are included in the application component.
This information is loaded in the header of the application component from which it can be extracted and stored by the server to respond to download requirements.
For example, a base AC can access a library on the server and present its version time stamp to demand that the loader transmit all application components that are compatible with it.
Following internal prechecking, the loader would present a list of application components meeting the compatibility requirement, and from this list, the user would select which applications to download.
Thus, the server manages the loading of application components on devices according to:
1. Availability: which application components the server can provide;
2. Compatibility: whether the application component can run on this target;
and 3. Accessability: whether the application component is permitted to be loaded onto this target.
Figure 3 illustrates the management of loading an application component and its prerequisites on a target device. The process illustrated in Figure 3 is from the vantage of the target device which queries the server (and its own system) for the information it requires to determine whether to perform the download on a demand ("pull") basis.
However, the process could also be implemented as a "push" from the server, with the server itself querying the target device and determining from its own records whether a download should be started.
The process begins when the target device receives a request for an application components (block 50). The request could originate with the user of the target device who requests new or upgraded service (for example, adding "calendaring" to a cellular telephone) or the request could come from the server awaiting a connection by the target device in order to upgrade/update the user's service.
CA9-99-004 g The target device first examines its own memory logs to determine whether the application component (corresponding to the requested service) is already loaded (block 52). If the application is already loaded, then of course, the process terminates.
If the AC is not already loaded on the device, the device's manager adds the application component to a list of application components to download (block 54) and obtains a list of the prerequisites for the application component from the application component server (block 56). In the preferred embodiment, the list of prerequisites provided by the server is sorted by dependency with the lowest layer last.
Also, it should be noted that each of the prerequisites may have its own list of prerequisites, and all of these would be included in the list of prerequisites for the originally-requested application component provided by the server.
If there are any prerequisites listed for the requested application component (block 58), the device's manager determines, for each prerequisite on the list:
whether it is already loaded on the device (block 60); and if it is already loaded, whether the loaded version of the prerequisite is compatible with the version of the requested application component (block 62). In the preferred embodiment, compatibility is determined by comparing the version time stamp of the loaded pre-requisite with the version time stamp of the requested AC. If the prerequisites time stamp is the same or a later version than the requested AC, then the prerequisite component is compatible with the requested AC.
If the prerequisite is either not loaded or not compatible, then it is added to the beginning of the device's download list.
Once the downlist list is populated with the requested application component and all prerequisite application components needed to be downloaded to run the requested one, the target device obtains This information is loaded the memory requirements for all of the application components on its download list from the server (block 66).
The target device determines whether it has enough memory to download all of the application components in the download list (block 68). If it does, it proceeds to download each application component (block 70), for example, using the process illustrated in Figure 4 and described below.
If the device does not have sufficient memory, it creates a "not enough memory" exception (block 72) and ends the process. The requestor of the download could then implement strategies to decide how to free up memory by unloading other application components (least used, most expensive, largest or whatever method). If it were possible to free enough memory, the download process (block 68) could proceed.
An application component loader provides a mechanism for incrementally filling in the contents of an application component with image data so that the download of the application component can be done with using the least amount of RAM possible.
In the preferred embodiment, the application component loader is implemented in a class called AC
Loader, which is part of the base system 30 in Figure 2.
The operation of the AC Loader is illustrated in Figure 4, and proceeds as follows.
A new loader is created (block 100) which allocates the required memory segments as described in the application component information from the available free contiguous memory block in ROM
(block 102). The loader then prepares that application component to receive the image data (block 104).
A method called incrementallyLoad is called repeatedly (blocks 106,110) with blocks of image data, which are appended to the ROM segment of the image (block 108).
If the load must be aborted for any reason, for example, because the connection to the server was interrupted (block 112), the cancelIncrementalLoad method is called (block 114) to ensure that all internal state is flushed (block 116).
If the load is successful, the finishIncrementalLoad method is called (block 118) to make the new image data available to the running virtual machine and the garbage collector as objects (block 120).
Until the application component data is completely loaded, the virtual machine will not recognize the obj ects contained in it. After the application component is loaded into ROM, the RAM segments are prepared and the mutable objects of the application component are copied into RAM, in contrast to static objects that cannot change their state (e.g. byte-code, strings, bitmaps, etc.), which remain in ROM.
Once loaded into a device, application components need a protocol for their management to preform activities such as startup, shutdown, unloading, warm start, restart, etc.. In the preferred embodiment, the application component manager residing in the target device has the overall responsibility for managing the application components. It is responsible for all aspects of the life cycle of application components, including loading, initializing, running (any contained active objects), deinitializing and unloading the application component.
The application programmer has the option to implement application component specific behavior for any of the life-cycle functions. These calls by the application component manager can optionally be monitored to complete in a certain time frame. If the call would result in an endless loop for example, the application component could be terminated and even be unloaded again depending on the application component manager's policy object (see below).
The first message after an application component has been successfully loaded is 'install' (block 122). The application programmer can implement whatever initialization is required when the application component is loaded into a running system for the first time. The default implementation is to do nothing.
After that the application component's controller receives 'startup (block 124). This message is also send after system start if the application component had already been loaded.
The default implementation is to do nothing.
S Then it receives the 'run' call (block 126). For active application components the application provider would put the start code. The default implementation (to do nothing) would make sense for shared application components that are used as common libraries only.
These life-cycle method names are subject to change, the current names are representations of life-cycle functions. For example 'startup' could be renamed to 'initialize', 'run' to 'start', 'shutDown' to 'stop', etc. There is also the possibility of adding (for example 'update') or removing life-cycle functions (combining 'startup' and 'run').
The application component manager has the following primary tasks;
1. It keeps a list of application components loaded on the target device;
2. It requests a list of available application components for loading from either remote server or local storage;
3. It calculates or negotiates with the server to arrive at a list of prerequisite application components for the image requested;
and for running it in RAM.
In the preferred embodiment, the application component's own identity is provided by a marker identifying the component as an image and by a pair of time stamps. One time stamp is a version time stamp used to indicate with which version the application component is compatible; the other is a unique time stamp indicating the unique build date for the particular application component.
Each application component requires a base application component and some random number of other application components, providing user interface, network and other basic support, that it requires to run. In the preferred embodiment, this information is provided by a list identifying the prerequisite application components by name and a list of pointers (addresses) to memory segments inside the prerequisite application components.
Application components must know how much ROM (flash memory) and RAM
(including runtime requirements) they need. Runtime requirements are identified at build time.
These size requirements are included in the application component.
This information is loaded in the header of the application component from which it can be extracted and stored by the server to respond to download requirements.
For example, a base AC can access a library on the server and present its version time stamp to demand that the loader transmit all application components that are compatible with it.
Following internal prechecking, the loader would present a list of application components meeting the compatibility requirement, and from this list, the user would select which applications to download.
Thus, the server manages the loading of application components on devices according to:
1. Availability: which application components the server can provide;
2. Compatibility: whether the application component can run on this target;
and 3. Accessability: whether the application component is permitted to be loaded onto this target.
Figure 3 illustrates the management of loading an application component and its prerequisites on a target device. The process illustrated in Figure 3 is from the vantage of the target device which queries the server (and its own system) for the information it requires to determine whether to perform the download on a demand ("pull") basis.
However, the process could also be implemented as a "push" from the server, with the server itself querying the target device and determining from its own records whether a download should be started.
The process begins when the target device receives a request for an application components (block 50). The request could originate with the user of the target device who requests new or upgraded service (for example, adding "calendaring" to a cellular telephone) or the request could come from the server awaiting a connection by the target device in order to upgrade/update the user's service.
CA9-99-004 g The target device first examines its own memory logs to determine whether the application component (corresponding to the requested service) is already loaded (block 52). If the application is already loaded, then of course, the process terminates.
If the AC is not already loaded on the device, the device's manager adds the application component to a list of application components to download (block 54) and obtains a list of the prerequisites for the application component from the application component server (block 56). In the preferred embodiment, the list of prerequisites provided by the server is sorted by dependency with the lowest layer last.
Also, it should be noted that each of the prerequisites may have its own list of prerequisites, and all of these would be included in the list of prerequisites for the originally-requested application component provided by the server.
If there are any prerequisites listed for the requested application component (block 58), the device's manager determines, for each prerequisite on the list:
whether it is already loaded on the device (block 60); and if it is already loaded, whether the loaded version of the prerequisite is compatible with the version of the requested application component (block 62). In the preferred embodiment, compatibility is determined by comparing the version time stamp of the loaded pre-requisite with the version time stamp of the requested AC. If the prerequisites time stamp is the same or a later version than the requested AC, then the prerequisite component is compatible with the requested AC.
If the prerequisite is either not loaded or not compatible, then it is added to the beginning of the device's download list.
Once the downlist list is populated with the requested application component and all prerequisite application components needed to be downloaded to run the requested one, the target device obtains This information is loaded the memory requirements for all of the application components on its download list from the server (block 66).
The target device determines whether it has enough memory to download all of the application components in the download list (block 68). If it does, it proceeds to download each application component (block 70), for example, using the process illustrated in Figure 4 and described below.
If the device does not have sufficient memory, it creates a "not enough memory" exception (block 72) and ends the process. The requestor of the download could then implement strategies to decide how to free up memory by unloading other application components (least used, most expensive, largest or whatever method). If it were possible to free enough memory, the download process (block 68) could proceed.
An application component loader provides a mechanism for incrementally filling in the contents of an application component with image data so that the download of the application component can be done with using the least amount of RAM possible.
In the preferred embodiment, the application component loader is implemented in a class called AC
Loader, which is part of the base system 30 in Figure 2.
The operation of the AC Loader is illustrated in Figure 4, and proceeds as follows.
A new loader is created (block 100) which allocates the required memory segments as described in the application component information from the available free contiguous memory block in ROM
(block 102). The loader then prepares that application component to receive the image data (block 104).
A method called incrementallyLoad is called repeatedly (blocks 106,110) with blocks of image data, which are appended to the ROM segment of the image (block 108).
If the load must be aborted for any reason, for example, because the connection to the server was interrupted (block 112), the cancelIncrementalLoad method is called (block 114) to ensure that all internal state is flushed (block 116).
If the load is successful, the finishIncrementalLoad method is called (block 118) to make the new image data available to the running virtual machine and the garbage collector as objects (block 120).
Until the application component data is completely loaded, the virtual machine will not recognize the obj ects contained in it. After the application component is loaded into ROM, the RAM segments are prepared and the mutable objects of the application component are copied into RAM, in contrast to static objects that cannot change their state (e.g. byte-code, strings, bitmaps, etc.), which remain in ROM.
Once loaded into a device, application components need a protocol for their management to preform activities such as startup, shutdown, unloading, warm start, restart, etc.. In the preferred embodiment, the application component manager residing in the target device has the overall responsibility for managing the application components. It is responsible for all aspects of the life cycle of application components, including loading, initializing, running (any contained active objects), deinitializing and unloading the application component.
The application programmer has the option to implement application component specific behavior for any of the life-cycle functions. These calls by the application component manager can optionally be monitored to complete in a certain time frame. If the call would result in an endless loop for example, the application component could be terminated and even be unloaded again depending on the application component manager's policy object (see below).
The first message after an application component has been successfully loaded is 'install' (block 122). The application programmer can implement whatever initialization is required when the application component is loaded into a running system for the first time. The default implementation is to do nothing.
After that the application component's controller receives 'startup (block 124). This message is also send after system start if the application component had already been loaded.
The default implementation is to do nothing.
S Then it receives the 'run' call (block 126). For active application components the application provider would put the start code. The default implementation (to do nothing) would make sense for shared application components that are used as common libraries only.
These life-cycle method names are subject to change, the current names are representations of life-cycle functions. For example 'startup' could be renamed to 'initialize', 'run' to 'start', 'shutDown' to 'stop', etc. There is also the possibility of adding (for example 'update') or removing life-cycle functions (combining 'startup' and 'run').
The application component manager has the following primary tasks;
1. It keeps a list of application components loaded on the target device;
2. It requests a list of available application components for loading from either remote server or local storage;
3. It calculates or negotiates with the server to arrive at a list of prerequisite application components for the image requested;
4. It loads application components;
5. It starts and stops application components by sending messages to the application component's controller; and 6. It unloads application components.
The application component manager may be customized to a specific device or platform through policy support in the form of a plugable object which is product specific and implements the product design decisions associated with loading and managing of application components. This object can act as a bridge between the applications already loaded and the available applications on the server.
Therefore, the policy object would determine;
1. Whether to allow loading and unloading of application components;
2. The source of application components for loading;
3. The list of the available application components for download;
4. Whether to automatically load prerequisite application components;
5. A course of action if not enough space is available to load a desired application component (for example, to determine which application components can be unloaded and what resources would be released when they are unloaded);
6. Whether to unload a shared application component if all its dependents have been unloaded;
The application component manager may be customized to a specific device or platform through policy support in the form of a plugable object which is product specific and implements the product design decisions associated with loading and managing of application components. This object can act as a bridge between the applications already loaded and the available applications on the server.
Therefore, the policy object would determine;
1. Whether to allow loading and unloading of application components;
2. The source of application components for loading;
3. The list of the available application components for download;
4. Whether to automatically load prerequisite application components;
5. A course of action if not enough space is available to load a desired application component (for example, to determine which application components can be unloaded and what resources would be released when they are unloaded);
6. Whether to unload a shared application component if all its dependents have been unloaded;
7. Whether to unload an application component when it has been terminated;
9. What to do if the application component causes an error (such as during unload, restart, etc.); and 10. The maximum number of threads an application component's application can create.
In the preferred embodiment, an AC Loader object provides a mechanism for incrementally filling in the contents of an application component with image data.
According to the preferred embodiment, a facility is provided to unload application components to reclaim the resources they are using. The operation of this facility is illustrated in Figure 5.
First, the application component manager sends the shutDown and uninstall methods to the controller of the application component which is about to be removed (block 130). This will give the applications) in that application component the opportunity to send data to its server, delete persistent data, close resources or do other clean up work.
After that, all connections to objects inside that application component from other application components are broken. For each class defined in that application component (block 132), all references to the class and any instances of the class are located (block 134) and replaced with null (block 136). Also, all objects which reside in the memory space of that application component but that are instances of classes residing outside that application component and are referenced from other application components (block 138) are moved into the memory space of the receiver class, the object's own class or to the base application component (block 140). This is performed iteratively until complete.
If an application component cannot be removed cleanly (block 142), the application component manager will initiate a system restart without this application component (block 148). This can happen if there is no space available to move the referenced objects or if there are invalid references in places not under the control of an element of the application component manager.
If the application component can be removed cleanly (block 142), the memory segments are physically released (block 144).
In either case, the application component manager will call the compact method (block 146) in order to eliminate "holes" in the RAM and the ROM segments, so that the largest possible memory segments can be allocated.
A preferred embodiment of the compact method is described in our concurrently filed application titled "Reclaiming Memory from Deleted Applications" (IBM docket no. CA9-99-003), which is commonly assigned.
The loading and unloading of application components of the present invention is not restricted to resource constrained devices, although due to the efficiencies achieved, it is an appropriate environment, as discussed. Thus, while embodiments of the invention have been described in detail, modifications, such as for use on other platforms, that would be obvious to the person skilled in the art are intended to be covered by the appended claims.
9. What to do if the application component causes an error (such as during unload, restart, etc.); and 10. The maximum number of threads an application component's application can create.
In the preferred embodiment, an AC Loader object provides a mechanism for incrementally filling in the contents of an application component with image data.
According to the preferred embodiment, a facility is provided to unload application components to reclaim the resources they are using. The operation of this facility is illustrated in Figure 5.
First, the application component manager sends the shutDown and uninstall methods to the controller of the application component which is about to be removed (block 130). This will give the applications) in that application component the opportunity to send data to its server, delete persistent data, close resources or do other clean up work.
After that, all connections to objects inside that application component from other application components are broken. For each class defined in that application component (block 132), all references to the class and any instances of the class are located (block 134) and replaced with null (block 136). Also, all objects which reside in the memory space of that application component but that are instances of classes residing outside that application component and are referenced from other application components (block 138) are moved into the memory space of the receiver class, the object's own class or to the base application component (block 140). This is performed iteratively until complete.
If an application component cannot be removed cleanly (block 142), the application component manager will initiate a system restart without this application component (block 148). This can happen if there is no space available to move the referenced objects or if there are invalid references in places not under the control of an element of the application component manager.
If the application component can be removed cleanly (block 142), the memory segments are physically released (block 144).
In either case, the application component manager will call the compact method (block 146) in order to eliminate "holes" in the RAM and the ROM segments, so that the largest possible memory segments can be allocated.
A preferred embodiment of the compact method is described in our concurrently filed application titled "Reclaiming Memory from Deleted Applications" (IBM docket no. CA9-99-003), which is commonly assigned.
The loading and unloading of application components of the present invention is not restricted to resource constrained devices, although due to the efficiencies achieved, it is an appropriate environment, as discussed. Thus, while embodiments of the invention have been described in detail, modifications, such as for use on other platforms, that would be obvious to the person skilled in the art are intended to be covered by the appended claims.
Claims (21)
1. A framework for upgrading software in a target computing device having non-volatile memory and volatile memory, comprising:
means for identifying memory requirements and pre-requisite software requirements for downloading and running a desired application in the target computing device;
and comparator means to determine whether the target computing device currently has available the memory and pre-requisite software requirements prior to commencing a download of the desired application.
means for identifying memory requirements and pre-requisite software requirements for downloading and running a desired application in the target computing device;
and comparator means to determine whether the target computing device currently has available the memory and pre-requisite software requirements prior to commencing a download of the desired application.
2. A framework, according to claim 1, wherein the means for identifying memory requirements comprises means for identifying memory requirements in non-volatile and volatile memory for downloading and running the desired application and its pre-requisite software on the target computing device.
3. A framework, according to claims 1 or 2, further comprising means for selecting application code to unload from the target computing device to free memory for downloading and running the desired application and its pre-requisite software.
4. A framework, according to claim 1 to 2 wherein the comparator means is further adapted to determine whether the desired application and its pre-requisite software are available for download to the target computing device.
5. A framework, according to claim 1 or 2 wherein the comparator means is further adapted to determine whether the desired application and its pre-requisite software are compatible with software currently loaded on the target computing device.
6. A method for downloading a desired software application from a server to a target computing device where, on receiving a request for the desired software application, the method comprises:
obtaining a set of software components required to run the desired software application;
constructing a subset list of the software components required to be downloaded to the target computing device;
identifying memory requirements for the subset list; and comparing the memory requirement for the subset with free memory in the target computing device.
obtaining a set of software components required to run the desired software application;
constructing a subset list of the software components required to be downloaded to the target computing device;
identifying memory requirements for the subset list; and comparing the memory requirement for the subset with free memory in the target computing device.
7. A method, according to claim 6, wherein the step of obtaining a set of software components comprises querying records in the server to identify pre-requisite software for running the desired software application.
8. A method, according to claim 7, wherein the step of constructing a subset of the software components comprises examining memory logs in the target computing device to locate the desired software application.
9. A method, according to claim 8, wherein the step of constructing a subset of the software components further comprises examining memory logs in the target computing device to locate the pre-requisite software.
10. A method, according to claims 8 or 9, wherein the step of constructing a subset of the software components comprises constructing a download list of any software not currently found in the memory logs in the target computing device, and wherein the step of identifying memory requirements comprises querying the records in the server to identify memory requirements for the software on the download list.
11. A method, according to claim 6 wherein, if sufficient free memory is located in the target computing device, the method further comprises, for each software component in the subset:
i) allocating memory segments in the non-volatile memory;
ii) downloading a segment of the software component;
iii) appending the downloaded segment to a portion of the software component already stored in non-volatile memory; and iv) repeating steps ii) and iii) until the software component has been downloaded to non-volatile memory.
i) allocating memory segments in the non-volatile memory;
ii) downloading a segment of the software component;
iii) appending the downloaded segment to a portion of the software component already stored in non-volatile memory; and iv) repeating steps ii) and iii) until the software component has been downloaded to non-volatile memory.
12. A method, according to claim 11 wherein, in the event of interruption in download of the software component, the method further comprises:
v) canceling further iterations of step iv); and vi) flushing downloaded segments of the software component from the non-volatile memory of the target computing device.
v) canceling further iterations of step iv); and vi) flushing downloaded segments of the software component from the non-volatile memory of the target computing device.
13. A method for downloading software from a remote server to an embedded computing device, comprising:
a) determining non-volatile memory requirements to store the software on the device;
b) allocating required memory segments in the non-volatile memory;
c) downloading a segment of the software;
d) appending the downloaded segment to a portion of the software already stored in non-volatile memory; and e) repeating steps c) and d) until the software has been downloaded to non-volatile memory.
a) determining non-volatile memory requirements to store the software on the device;
b) allocating required memory segments in the non-volatile memory;
c) downloading a segment of the software;
d) appending the downloaded segment to a portion of the software already stored in non-volatile memory; and e) repeating steps c) and d) until the software has been downloaded to non-volatile memory.
14. A method, according to claim 13, wherein, in the event of interruption in download of the software component, the method further comprises:
v) canceling further iterations of step iv); and vi) flushing downloaded segments of the software component from the non-volatile memory of the target computing device.
v) canceling further iterations of step iv); and vi) flushing downloaded segments of the software component from the non-volatile memory of the target computing device.
15. A method to unload a software application from memory segments in a computing device, comprising:
locating all references to classes defined in the application;
replacing all located references with a null value; and locating all remaining objects referenced externally of the application and moving the located objects to memory space occupied by a different application.
locating all references to classes defined in the application;
replacing all located references with a null value; and locating all remaining objects referenced externally of the application and moving the located objects to memory space occupied by a different application.
16. A method, according to claim 15, wherein if the application can be removed from memory, the method further comprises releasing the memory segments.
17. A method, according to claim 15, wherein if the application cannot be removed from memory, the method further comprises initiating a system restart without the application.
18. A computer readable memory for storing the instructions for use in the execution in a computer of any one of the methods of claims 6 through 17.
19. A computer program product comprising a computer usable medium having computer readable program code means embodied therein for causing a computer to download a desired software application from a server to a target computing device where, on receiving a request for the desired software application, the computer readable program code means in said computer program product comprising:
computer readable program code means for causing the computer to obtain a set of software components required to run the desired software application;
computer readable program code means for causing the computer to construct a subset list of the software components required to be downloaded to the target computing device;
computer readable program code means for causing the computer to identify memory requirements for the subset list; and computer readable program code means for causing the computer to compare the memory requirements for the subset with free memory in the target computing device.
computer readable program code means for causing the computer to obtain a set of software components required to run the desired software application;
computer readable program code means for causing the computer to construct a subset list of the software components required to be downloaded to the target computing device;
computer readable program code means for causing the computer to identify memory requirements for the subset list; and computer readable program code means for causing the computer to compare the memory requirements for the subset with free memory in the target computing device.
20. A computer program product comprising a computer usable medium having computer readable program code means embodied therein for causing a computer to download software from a remote server to an embedded computing device, the computer readable program code means in said computer program product comprising:
computer readable program code means for causing the computer to determine non-volatile memory requirements to store the software on the device;
computer readable program code means for causing the computer to allocate required memory segments in the non-volatile memory;
computer readable program code means for causing the computer to download a segment of the software;
computer readable program code means for causing the computer to append the downloaded segment to a portion of the software already stored in non-volatile memory;
and computer readable program code means for causing the computer to repeat the steps of downloading and appending until the software has been downloaded to non-volatile memory.
computer readable program code means for causing the computer to determine non-volatile memory requirements to store the software on the device;
computer readable program code means for causing the computer to allocate required memory segments in the non-volatile memory;
computer readable program code means for causing the computer to download a segment of the software;
computer readable program code means for causing the computer to append the downloaded segment to a portion of the software already stored in non-volatile memory;
and computer readable program code means for causing the computer to repeat the steps of downloading and appending until the software has been downloaded to non-volatile memory.
21. A computer program product comprising a computer usable medium having computer readable program code means embodied therein for causing a computer to unload a software application from memory segments in a computing device, the computer readable program code means in said computer program product comprising:
computer readable program code means for causing the computer to locate all references to classes defined in the application;
computer readable program code means for causing the computer to replace all located references with a null value; and computer readable program code means for causing the computer to locate all remaining objects referenced externally of the application and moving the located objects to memory space occupied by a different application.
computer readable program code means for causing the computer to locate all references to classes defined in the application;
computer readable program code means for causing the computer to replace all located references with a null value; and computer readable program code means for causing the computer to locate all remaining objects referenced externally of the application and moving the located objects to memory space occupied by a different application.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002267549A CA2267549A1 (en) | 1999-03-30 | 1999-03-30 | Loading and unloading of application components |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002267549A CA2267549A1 (en) | 1999-03-30 | 1999-03-30 | Loading and unloading of application components |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2267549A1 true CA2267549A1 (en) | 2000-09-30 |
Family
ID=29588659
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002267549A Abandoned CA2267549A1 (en) | 1999-03-30 | 1999-03-30 | Loading and unloading of application components |
Country Status (1)
| Country | Link |
|---|---|
| CA (1) | CA2267549A1 (en) |
Cited By (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2002079981A1 (en) * | 2001-03-30 | 2002-10-10 | Nokia Corporation | Downloading application software to a mobile terminal |
| EP1417826A1 (en) * | 2001-08-13 | 2004-05-12 | Qualcomm, Incorporated | System for updating software in a wireless device |
| EP1423811A1 (en) * | 2001-08-15 | 2004-06-02 | Qualcomm, Incorporated | Transaction processing |
| EP1442382A2 (en) * | 2001-10-12 | 2004-08-04 | Matsushita Electric Industrial Co., Ltd. | Efficient service management in home gateways |
| US6993328B1 (en) | 2000-05-08 | 2006-01-31 | Nokia Corporation | Method for over the air mobile station management |
| WO2006013007A3 (en) * | 2004-08-06 | 2006-08-03 | Nokia Corp | Improved mobile communications terminal and method |
| EP2323311A1 (en) * | 2009-11-17 | 2011-05-18 | Simartis Telecom srl. | Web interface for SIM card based applications |
| CN102103469A (en) * | 2006-05-18 | 2011-06-22 | 戴尔产品有限公司 | Method for loading extra content into an information processing system |
| US8135745B2 (en) | 2008-03-04 | 2012-03-13 | Core Wireless Licensing S.A.R.L. | Storage management |
| WO2013088036A1 (en) * | 2011-12-16 | 2013-06-20 | France Telecom | Method of managing an application referenced by a device |
| US8620275B2 (en) | 2002-08-30 | 2013-12-31 | Qualcomm Incorporated | Server processing in providing messages for a wireless device connecting to a server |
| US8630634B2 (en) | 2002-08-30 | 2014-01-14 | Qualcomm Incorporated | Processing of interactive screens for a wireless device |
| US8660613B2 (en) | 2002-01-31 | 2014-02-25 | Qualcomm Incorporated | System and method for providing messages on a wireless device connecting to an application server |
| US9143622B2 (en) | 2006-02-17 | 2015-09-22 | Qualcomm Incorporated | Prepay accounts for applications, services and content for communication devices |
| US9185538B2 (en) | 2005-05-31 | 2015-11-10 | Qualcomm Incorporated | Wireless subscriber application and content distribution and differentiated pricing |
| US9185234B2 (en) | 2006-02-22 | 2015-11-10 | Qualcomm Incorporated | Automated account mapping in a wireless subscriber billing system |
| US9232077B2 (en) | 2003-03-12 | 2016-01-05 | Qualcomm Incorporated | Automatic subscription system for applications and services provided to wireless devices |
| US9350875B2 (en) | 2005-05-31 | 2016-05-24 | Qualcomm Incorporated | Wireless subscriber billing and distribution |
| US10009743B2 (en) | 2001-08-13 | 2018-06-26 | Qualcomm Incorporated | System and method for providing subscribed applications on wireless devices over a wireless network |
| US10043170B2 (en) | 2004-01-21 | 2018-08-07 | Qualcomm Incorporated | Application-based value billing in a wireless subscriber network |
-
1999
- 1999-03-30 CA CA002267549A patent/CA2267549A1/en not_active Abandoned
Cited By (30)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7809365B2 (en) | 2000-05-08 | 2010-10-05 | Nokia Corporation | Method for over the air mobile station management |
| US6993328B1 (en) | 2000-05-08 | 2006-01-31 | Nokia Corporation | Method for over the air mobile station management |
| WO2002079981A1 (en) * | 2001-03-30 | 2002-10-10 | Nokia Corporation | Downloading application software to a mobile terminal |
| US10009743B2 (en) | 2001-08-13 | 2018-06-26 | Qualcomm Incorporated | System and method for providing subscribed applications on wireless devices over a wireless network |
| EP1417826A1 (en) * | 2001-08-13 | 2004-05-12 | Qualcomm, Incorporated | System for updating software in a wireless device |
| EP1417826A4 (en) * | 2001-08-13 | 2007-08-15 | Qualcomm Inc | System for updating software in a wireless device |
| US7454199B2 (en) * | 2001-08-13 | 2008-11-18 | Qualcomm Incorporated | System and method for temporary application component deletion and reload on a wireless device |
| US9203923B2 (en) | 2001-08-15 | 2015-12-01 | Qualcomm Incorporated | Data synchronization interface |
| EP1423811A4 (en) * | 2001-08-15 | 2005-08-24 | Qualcomm Inc | Transaction processing |
| EP1423811A1 (en) * | 2001-08-15 | 2004-06-02 | Qualcomm, Incorporated | Transaction processing |
| EP1442382A4 (en) * | 2001-10-12 | 2006-05-17 | Matsushita Electric Ind Co Ltd | Efficient service management in home gateways |
| EP1442382A2 (en) * | 2001-10-12 | 2004-08-04 | Matsushita Electric Industrial Co., Ltd. | Efficient service management in home gateways |
| US8660613B2 (en) | 2002-01-31 | 2014-02-25 | Qualcomm Incorporated | System and method for providing messages on a wireless device connecting to an application server |
| US8620275B2 (en) | 2002-08-30 | 2013-12-31 | Qualcomm Incorporated | Server processing in providing messages for a wireless device connecting to a server |
| US8630634B2 (en) | 2002-08-30 | 2014-01-14 | Qualcomm Incorporated | Processing of interactive screens for a wireless device |
| US9232077B2 (en) | 2003-03-12 | 2016-01-05 | Qualcomm Incorporated | Automatic subscription system for applications and services provided to wireless devices |
| US10043170B2 (en) | 2004-01-21 | 2018-08-07 | Qualcomm Incorporated | Application-based value billing in a wireless subscriber network |
| WO2006013007A3 (en) * | 2004-08-06 | 2006-08-03 | Nokia Corp | Improved mobile communications terminal and method |
| US9876843B2 (en) | 2004-08-06 | 2018-01-23 | Nokia Technologies Oy | Mobile communications terminal and method |
| US8832595B2 (en) | 2004-08-06 | 2014-09-09 | Nokia Corporation | Mobile communications terminal and method |
| US9350875B2 (en) | 2005-05-31 | 2016-05-24 | Qualcomm Incorporated | Wireless subscriber billing and distribution |
| US9185538B2 (en) | 2005-05-31 | 2015-11-10 | Qualcomm Incorporated | Wireless subscriber application and content distribution and differentiated pricing |
| US9143622B2 (en) | 2006-02-17 | 2015-09-22 | Qualcomm Incorporated | Prepay accounts for applications, services and content for communication devices |
| US9185234B2 (en) | 2006-02-22 | 2015-11-10 | Qualcomm Incorporated | Automated account mapping in a wireless subscriber billing system |
| CN102103469A (en) * | 2006-05-18 | 2011-06-22 | 戴尔产品有限公司 | Method for loading extra content into an information processing system |
| US8583689B2 (en) | 2008-03-04 | 2013-11-12 | Core Wirless Licensing S.A.R.L. | Storage management of profiles in mobile devices |
| US8135745B2 (en) | 2008-03-04 | 2012-03-13 | Core Wireless Licensing S.A.R.L. | Storage management |
| EP2323311A1 (en) * | 2009-11-17 | 2011-05-18 | Simartis Telecom srl. | Web interface for SIM card based applications |
| FR2984552A1 (en) * | 2011-12-16 | 2013-06-21 | France Telecom | METHOD AND DEVICE FOR MANAGING AN APPLICATION REFERENCED BY A DEVICE |
| WO2013088036A1 (en) * | 2011-12-16 | 2013-06-20 | France Telecom | Method of managing an application referenced by a device |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2267549A1 (en) | Loading and unloading of application components | |
| US5537596A (en) | Method and apparatus for overriding resource maps in a computer system | |
| US20040093597A1 (en) | Firmware update system for facilitating firmware update in mobile handset related applications | |
| US8082414B2 (en) | Method and system for centralized memory management in wireless terminal devices | |
| US7752616B2 (en) | Update system capable of updating software | |
| US7539985B2 (en) | Systems and methods for dynamic component versioning | |
| EP1872230B1 (en) | Centralized memory management in wireless terminal devices | |
| US20040098427A1 (en) | Device memory management during electronic file updating | |
| RU2339076C2 (en) | Execution of non-verified programs in radio communication device | |
| US20050227683A1 (en) | Apparatus and method for over the air software repair | |
| EP1437657A2 (en) | System and method for management of software applications | |
| KR100871778B1 (en) | Dynamic addressing da using a centralized da manager | |
| WO2005096145A2 (en) | Method and apparatus for dynamic extension of device management tree data model on a mobile device | |
| CN103353845A (en) | Method and device for uploading and pushing script | |
| CN110543369A (en) | Construction method and device of storage space structure of android system and construction structure of storage space structure of android system | |
| WO2002075531A1 (en) | Method for loading and executing an application in an embedded environment | |
| AU2005200252A1 (en) | Versioning support in object-oriented programming languages and tools | |
| CN106569880A (en) | Method and system for dynamically sharing resources between Android applications | |
| US20070028228A1 (en) | Software upgrades with user advisement | |
| US8010576B2 (en) | Inventory and configuration management | |
| US6336215B1 (en) | Apparatus and method for on-line code only replacement of a running program using checkpoints | |
| US20070079279A1 (en) | Embedded device with software registry | |
| CN107667343B (en) | System and method for loading on-demand resources | |
| CN114860203A (en) | Project creation method, project creation device, server and storage medium | |
| KR101083090B1 (en) | Mobile terminal with mobile platform comprising structure of functional modularization, method for driving the mobile platform and managing idle application |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| FZDE | Discontinued | ||
| FZDE | Discontinued |
Effective date: 20050330 |